mwh.geek.nz

There’s a new Freshen release out (should be accessible in the store in about two hours). This is a bugfix-only release, cleaning up some niggles around settings updating.

`Freshen -m Freshen` will do the job once it’s in the store, or `Compile http://mwh.geek.nz/files/gobo/recipes/Freshen–3.0.10–recipe.tar.bz2` if you can’t wait. It is a recommended update and won’t break any existing behaviours.

This weekend I’ve been upgrading my system to KDE 4.1.3 (from 3.5.10). This post is to document a few niggles and workarounds I’ve found in doing so.

• Automoc is missing from one or two of the Dependencies files, so compile it first.
• Either disable all the KDE 3.5.x programs first or be prepared to SymlinkProgram -f the 4.x versions during the upgrade. KDE-Base-Workspace was the one I ran into problems with here, specifically, but a couple of others might too (probably -PIM-Libs). If you don’t, you get some pretty obscure compilation errors that are difficult to track down.
• The default kdmrc doesn’t run, and will cause you to get a message box saying “No greeter widget plugin loaded. Check the configuration.” To fix that, update /Programs/KDE-Base-Workspace/Current/Shared/config/kdm/kdmrc to uncomment the “PluginsLogin” and “PluginsShutdown” lines, and give them the value “/Programs/KDE-Base-Workspace/Current/lib/kde4/kgreet_classic.so”, and things will all work nicely. The recipe should be fixed to do that automatically sometime – it seems the problem arises because of the build process’s automatic configuration, which looks at your existing kdmrc file, so it won’t come up all the time, which makes it a bit hard to deal with.
• KDE-PIM doesn’t compile at all for me. I gather others haven’t faced that, so I’ll look into what causes it. The error is something about QSplitter.
• IRC has been removed from Kopete upstream, which is a pain.
• Strigi’s default plugin search path doesn’t include /S/L/L, so you have to create a symlink in /P/S/C/lib/strigi->/S/L/L/strigi/strigiindex_sopranobackend.so to use it with Nepomuk.
• You also have to create a link .kde4->.kde

Altogether though, the upgrade went much smoother than I expected. Everything works fairly cleanly with just a few niggles so far. Some things are different (bad!) in KDE4 itself: Konsole doesn’t save my tabs any more, for example. I will get used to that and probably script around it.

I have committed a new implementation of the UseFlags script and module, that is cleaner and more featureful than the existing version. It is interface-compatible with the current released version (2.9.5) and behaves the same way on valid input from the old version.

The rewrite served two purposes. One was cleaning up the code, which had grown a bit beyond what it was designed to do – generic flags particularly weren’t even a twinkle in the eye at the time the original design was put into place, nor mutually-exclusive flags. That led to some fairly hacky workarounds to deal with them, including a very ugly proxy object to allow extra data to be passed out of methods along with the sets of flags. Those are gone, and in place there is a UseFlagEngine class that maintains the state in a self-contained fashion.

The other purpose was allowing some new functionality that had been requested and that wasn’t easily or tidily doable on the old implementation. In particular, it will now support “profiles”, including whole sets of flag specifications in one go; “magic flags” that do more complicated things when enabled (such as +gnome also causing +gtk2, +gconf, +gnome-vfs); and disabling the “automatic flags” from installed programs, as well as the generic and mutually-exclusive flag behaviour.

A short summary of how this new version behaves from a user perspective: each file is parsed and the commands executed line-by-line. There are now user-specific files, and all files are parsed the same way. Indented blocks of commands will be executed when certain given conditions are met, and not otherwise. Other files of useflag commands may be included with a one-line command, allowing separate “profiles” of flags to be set up easily.

A major internal change is that every configuration file is now treated the same way – any one may perform any of the actions of any other. That isn’t by design so much as it being simpler to build only the one parser, but it does have some handy properties too. By convention, generic flags will still be defined in GenericFlags.conf, but they may be overridden (more on that later) at another point. It also includes user-specific flags in its standard execution. The full list of files executed if they are found is, in this order: /Programs/Scripts/Current/Data/DistUseFlags.conf, /System/Settings/GenericFlags.conf, ~/.config/Scripts/GenericFlags.conf, /System/Settings/UseFlags.conf, ~/.config/Scripts/UseFlags.conf.

Automatic flags may be disabled wholesale. -INSTALLED at any point will reverse the results of the automatic flag function. Most likely you would include this at the top of your UseFlags.conf, and it would be as if they never happened.

Similarly, generic flags and mutually-exclusive flags may be disabled with -GENERIC_FLAGS and -MUTUALLY_EXCLUSIVES. These will prevent the respective behaviours occurring at the end of flag parsing.

I’ve referred to “commands” a couple of times above. Each line in a flag configuration file is a command that has immediate effect. A block of commands may be indented one space, and will be executed when certain conditions are met – these are used by the if command, for example.

Currently defined are:

• +foo and -foo – these set or unset the flag foo. If given a list of programs after them (as in +foo KDE-Base KDE-Libs), the flag will only be set or unset for programs in that list. This is the standard flag specification from before.
• foo: bar baz ... – this defines a generic flag foo with the contents bar baz …. This is the standard generic flag specification from before.
• if foo – execute the following indented block if foo is set. This allows conditional behaviour in included files.
• if foo is available – execute the following indented block if foo is available for the current program.
• generic_prepend generic foo bar ... – prepend foo bar … to the generic flag generic. This means a GNOME profile could shift gtk2 to the head of the gui flag, for example.
• generic_remove generic foo bar ... – remove foo bar … from the generic flag generic. This could disable a particular implementation from appearing at all.
• generic_pop generic [other_generic] – remove the first component of generic and prepend it to other_generic if given (otherwise just drop it).
• on foo and on -foo – execute the following indented block at a later point if foo is set or unset. This allows defining the “magic +gnome” that was requested before.
• loop generic x – execute the following indented block for each component of generic, replacing “$x” in it with the respective component each iteration. This allows disabling all the component flags of a generic, to guarantee the usual generic behaviour.
• break [n] – stop executing the current loop, or up to n outer loops if given.
• include profile – find profile.useflags and execute it at this point. The search path is ~/.config/Scripts/UseFlags, /System/Settings/Scripts/UseFlags, /Programs/Scripts/Current/Data/UseFlags, and only the first file found will be included. This is to allow you to “shadow” a shipped version locally.
• -* – empty the set of flags. This is the same as the old -* behaviour.

One further change (or non-change) to note – the USE environment variable, if set, is parsed in the old fashion and not as above. It is split on whitespace, and then +foo and -foo specifications, with optional @program modifiers, are handled in the same way they always were. on blocks and the special -INSTALLED behaviour (and the others) will still happen, however.

I will provide some examples of this in action in a later post. For now, you can try this in the trunk Scripts (not 2.9.5). `Compile Scripts SVN` will get that if you aren’t tracking trunk (they are pretty stable, so it probably won’t break anything).

Every so often somebody says something (such as this forum post), or does something unwise in the recipe store (binary Firefox 3 beta recipe) suggesting they don’t know just how simple it is to create your own store to put packages you build or unstable recipes you write into. For GoboLinux, the format is extremely simple, and the tools make it pretty easy as well.

Both recipe and package stores are very similiar; in both cases, it’s a web-accessible directory of .recipe.tar.bz2 or –i686.tar.bz2 files, containing at least a file named “MANIFEST” listing out those filenames. You can generate that file with `ls > MANIFEST`. There’s a second file, MANIFEST.bz2, that’s a compressed version of the same.

That’s all that’s actually necessary to set up a repository – the URL of that directory can be added to getRecipeStores or one of the lists in GetAvailable.conf, and your recipes or packages will automatically be included by all of the tools, including Freshen.

You can generate the package tarballs with the `CreatePackage` command, and they will be signed with your GPG key if you have one. That key won’t be in the default keyring, so the packages will fail verification when installed. You can either ensure they’re unsigned, or have users of your repository import your key into the system keyring: `gpg –no-default-keyring –keyring=/Programs/Scripts/Current/Data/gpg/goboring.gpg –recv-keys 8B3A4A5B` will pull in mine, for example. Then people will be able to determine that the packages haven’t been modified and that they come from you, so they can decide whether to trust you to build them or not.

Now, to be honest, I strongly advise against anybody using some external package repository you haven’t created yourself. It’s just a bad idea to install opaque blobs of software you can’t know anything about. If they’re signed, you know they’re from the same person each time, and if the signing key’s in the strong set you have a reasonable assurance of who that person really is, but it’s still pretty unwise to do willy-nilly.

Experimental recipe repositories are a good idea, though – just think it through before you decide to use the unstable recipes. I set one up at http://mwh.geek.nz/files/gobo/recipes/experimental/ to contain recipes I’ve built that are or need unreleased versions of software, and anybody else in that situation would be advised to do the same. GoboLinux makes it very simple to add software to the packaging system, unlike most distributions, and creating your own repository is easy as well for when you need it.

The first ever bugfix-only release of the distribution is out now. The ISO is available from http://gobo.calica.com/gobolinux-iso/GoboLinux-014.01-i686.iso or http://kundor.org/gobo/iso/GoboLinux-014.01-i686.iso (MD5 c4c4827d8bbaf724e0e28f8ead47e7da), and will be from the other standard mirrors as they update.

This release fixes all known bugs from 014 and should be the most stable release yet. Thanks to Carlo for all the work he put in, and everybody else who reported bugs, fixed bugs, backported fixes to bugs, or just provided moral support.

This release will be distributed on 4,000 CDs at the International Forum on Free Software (FISL) in Porto Alegre, Brazil; if you’re not going to be there, download and give it a whirl.

To follow up on adding support for GNU Bazaar in Compile, I’ve also added it to MakeRecipe in the same manner as the others.

I’ve also set up a few branches mirroring the Subversion tree – at the moment, only for Scripts, Compile, and Freshen, but others may follow if anybody else is using them. I’ve found them useful to split pieces of work across locations and to have decent branching to work with when adding features. The three branches up so far are at:

• http://mwh.geek.nz/files/gobo/branches/Scripts/trunk
• http://mwh.geek.nz/files/gobo/branches/Compile/trunk
• http://mwh.geek.nz/files/gobo/branches/Freshen/trunk

They’re kept up-to-date with bzr-svn (which was a bit of a pain to get going on Dreamhost; I had to compile half a toolchain in the process), and updated every half hour. Probably nobody else will be using them, but they’re there if somebody wants.

I think that’s the last of the work integrating bzr with the tools, so it should be all there for the next release of the tools, so I’ll move the branch recipes over from the experimental recipes repository into the mainline when that happens.