Planet Exherbo

Alexander Færøy: Erlang foredrag

Sun, 16 Nov 2008 17:33:32 +0000

Onsdag d. 26/11 kl. 19 - til SSLUGs onsdagsmøde på CBS, vil Jesper Louis Andersen snakke om sproget Erlang.

I den virkelige verden foregår der mange ting samtidigt. Mennesker samt maskiner arbejder parallelt ved siden af hinanden — det er tydeligt at interaktionen mellem forskellige computersystemer bliver større og større.

Erlang er ikke det første sprog som forsøger at modellere maskinen som mange små systemer, der samarbejder om at løse en opgave — men det er et system med en del success’er bag sig. I dette foredrag vil jeg ikke forsøge at gå i detaljer med sproget, men i stedet forklare den model, som danner dets fundament. Jeg skal endvidere komme med et bud på hvor Erlang kan benyttes i gængse softwaresystemer allerede i dag.

Om foredragsholderen

Jesper Louis Andersen er Bachelor i Datalogi og er i skrivende stund igang med at tage sin kandidatgrad. Han interesserer sig for programmeringssprog af alle slags, samt hvad teknologien bag også kan anvendes til uden for sprog-feltet. For tiden køres der med Ubuntu Linux, men han har tidligere kørt Redhat, Debian, FreeBSD, NetBSD og OpenBSD.

Tid og sted

Mødet foregår på: CBS - Copenhagen Business School, Howitzvej 60, 2000 Frederiksberg og døren vil være åben fra kl. 18.00. Foredraget starter kl. 19.00.

Se eventuelt SSLUGs wiki.

Ciaran McCreesh: Why must all XML APIs suck?

Tue, 04 Nov 2008 17:24:42 +0000

Given the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
    <herd>blah</herd>
    <herd>foo</herd>
    <maintainer>
        <email>foo@bar</email>
        <name>Foo Bar</name>
    </maintainer>
    <maintainer>
        <email>bar@baz</email>
    </maintainer>
    <use>
        <flag name="foo">Adds support for foo. Needs <pkg>cat/fooplugin</pkg> to be useful.</flag>
        <flag name="bar">Adds support for bar.</flag>
    </use>
    <longdescription><![CDATA[
        A giant space monkey has eaten my shorts.
        ]]></longdescription>
    <longdescription lang="fr"><![CDATA[
        Un singe géant de l'espace a mangé mes shorts.
        ]]></longdescription>
</pkgmetadata>

I want the following:

A set of strings called herds, containing blah and foo.
A set of pair(string, string) called maintainers, containing ("foo@bar", "Foo Bar") and ("bar@baz", "").
A map from string to string called use, containing ("foo" => "Adds support for foo. Needs cat/fooplugin to be useful.") and ("bar" => "Adds support for bar").
A string called longdescription containing "A giant space monkey has eaten my shorts.".

What’s the least painful way of doing it? Why can’t there be a solution concise enough to fit into a comment? Why must XML blow so many goats?

Tagged: xml

Stephen Bennett: For those wondering…

Tue, 04 Nov 2008 14:37:42 +0000

…why I’ve been slacking even more than usual lately, this might explain something. Go and play around. Cookies for anyone who finds a bug.

Ciaran McCreesh: MYOPTIONS: It’s like IUSE with Candy

Tue, 04 Nov 2008 14:24:15 +0000

The exheres-0 package format, used primarily by Exherbo, calls what Gentoo calls ‘USE flags’ ‘options’. What PMS EAPIs call IUSE, exheres-0 calls MYOPTIONS.

Up until recently, this has just been a differently named variable, minus support for IUSE defaults because we hateses them. But now that Paludis has the choices API we’re not stuck using that format. The first extension is fairly simple:

MYOPTIONS="foo bar baz linguas: en en_GB fr"

This is much nicer than having to write out linguas:en linguas:en_GB etc., and is especially important for exheres-0 because SUBOPTIONS (USE_EXPAND) values must be explicitly listed.

The next step is flag descriptions. use.local.desc is rather crude, and XML is horrible, so we thought about re-using annotations:

MYOPTIONS="
    X [[ description = [ Build a graphical user interface ] ]]
    python [[ description = [ Build Python language bindings ] ]]
    nls
    linguas: en en_GB fr"

Any undescribed flag falls back to the global description — general consensus is to keep those, because they make it easier for a user to set up a fresh options.conf.

Whilst we’re at it, we might as well solve the conflicting options problem. In the good old days, use flags were used only when something was optional — that is, if support for foo also needed support for bar, USE="-foo bar" would just compile without bar. Unfortunately, a few people didn’t really like that, and even more unfortunately developers started doing horrible die calls in pkg_setup rather than coming up with a proper solution.

With half of the pkg_setup die calls eliminated by use dependencies, it seems a shame not to fix the other not-quite-half-because-of-a-few-obscure-things. There’s already pkg_pretend for exheres-0, which is a big improvement, but moving handling of the common cases into the package manager is cleaner.

So, we start with the simplest case: flags requiring other flags.

MYOPTIONS="
        X
        python
        gtk [[ requires = [ X python ] ]]
        qt [[ requires = X ]]
        motif [[ requires = X ]]
        "

We might like SUBOPTIONS and negatives too:

MYOPTIONS="
        minimal
        python [[ requires = [ -minimal ] ]]
        linguas:
            en
            en_GB [[ requires = [ linguas: en ] ]]
        "

There might be a case for “if blah is not enabled then …” requirements:

MYOPTIONS="
        X
        -ncurses [[ requires = [ X ] ]]
        "

although we have a nicer solution this particular case. Note that it’s ok to list the same flag multiple times, so the above can be written as:

MYOPTIONS="
        X
        ncurses
        -ncurses [[ requires = [ X ] ]]
        "

For convenience, we’d like to be able to apply the same requires annotation to multiple items:

MYOPTIONS="
        X
        python
        (
            gtk [[ requires = python ]]
            qt
            motif
        ) [[ requires = X ]]
        "

Here, gtk requires both X and python (although excessive mixing of things is discouraged for style reasons).

Sometimes, you have to select one of a number of flags:

MYOPTIONS="
        (
            gtk
            qt
            motif
        ) [[ number-selected = exactly-one ]]
        "

Also allowed are at-least-one and at-most-one.

Sometimes requirements are conditional, too:

MYOPTIONS="
        X
        python
        X? (
            (
                gtk [[ requires = python ]]
                qt
                motif
            ) [[
                number-selected = exactly-one
                requires = X
            ]]
        )
        "

Although, for style reasons, this would end up looking more like:

MYOPTIONS="
        X [[ description = [ Include a GUI ] ]]
        python [[ description = [ Build Python language bindings ] ]]
        gtk
        qt
        motif

        gtk [[ requires = python ]]
        ( gtk qt motif ) [[ requires = X ]]
        X? ( ( gtk qt motif ) [[ number-selected = exactly-one ]] )
        "

As for how these are verified… They’re checked at --pretend --install time, right before pkg_pretend is run. Even if a requirement fails, though, pkg_pretend is still run, allowing us to show as many notices as necessary at the same time.

The failure is indicated to the user by the pkg_bad_options function. This probably won’t be overridden by very many packages, and those that do will almost certainly call default. The default output looks like this:

These packages will be installed:

* test-cat/test-pkg::ciaranm :1 [N 1] <target>
    X gtk -motif -python qt build_options: recommended_tests split strip
    "Dummy test package"

Total: 1 package (1 new)

 * The following option requirements are unmet for test-cat/test-pkg-1:
 *     Enabling option 'gtk' requires option 'python' to be enabled
 *     Exactly one of options ( gtk, qt, motif ) must be met

* Cannot continue with install due to the errors indicated above

And just think, all that without resorting to convoluted and incomprehensible set theory.

Tagged: eapi, exherbo, exheres-0, paludis

Ciaran McCreesh: UIs for Parallelism

Mon, 27 Oct 2008 14:56:43 +0000

Getting the UI right for parallel execution is tricky.

Make, for example, doesn’t even try. It just displays output from all the children all mixed together, and relies upon commands prefixing their output with a filename or similar identifier. This generally works for what make needs to do, but it’s a bit too crude for some things.

For the secret “not supposed to use it” parallelism in Paludis, we’re currently using something slightly more sophisticated: each line of output from each child job is prefixed by the job’s name. So you’ll see things like:

sync unavailable> wget -T 30 -t 1 -O /var/tmp/paludis-tarsync-cvh9gX/exherbo_repositories.tar.bz2 http://git.exherbo.org/exherbo_repositories.tar.bz2
sync unavailable-unofficial> wget -T 30 -t 1 -O /var/tmp/paludis-tarsync-kvEzRZ/exherbo_unofficial_repositories.tar.bz2
sync unavailable-unofficial> --14:24:06--  http://git.exherbo.org/exherbo_unofficial_repositories.tar.bz2
sync unavailable-unofficial>            => `/var/tmp/paludis-tarsync-kvEzRZ/exherbo_unofficial_repositories.tar.bz2'
sync unavailable> --14:24:06--  http://git.exherbo.org/exherbo_repositories.tar.bz2

Something like this is necessary because the commands involved don’t do their own prefixing. But whilst it’s an improvement, the output’s rather cluttered and it’s hard to work out what’s going on. I’ve been experimenting with something more like this (slowdown induced artificially to make the point):

Starting sync

Repository                    Status                Pending Active  Done
-> alsa                       starting              16      1       0
-> ciaranm                    starting              15      2       0
-> ferdy                      starting              14      3       0
-> compnerd                   starting              13      4       0
-> arbor                      starting              12      5       0
-> compnerd                   success               12      4       1
-> gnome                      starting              11      5       1
-> alsa                       failed                11      4       2
    ... fatal: The remote end hung up unexpectedly
-> hardware                   starting              10      5       2
-> ferdy                      success               10      4       3
-> media                      starting              9       5       3
-> gnome                      success               9       4       4
-> mozilla                    starting              8       5       4
-> hardware                   success               8       4       5
-> pioto-exheres              starting              7       5       5
-> media                      success               7       4       6
-> python                     starting              6       5       6
-> pioto-exheres              success               6       4       7
-> rbrown                     starting              5       5       7
-> mozilla                    success               5       4       8
-> texlive                    starting              4       5       8
-> ciaranm                    active                4       5       8
-> python                     success               4       4       9
-> unavailable                starting              3       5       9
-> texlive                    success               3       4       10
-> unavailable-unofficial     starting              2       5       10
-> rbrown                     success               2       4       11
-> unwritten                  starting              1       5       11
-> arbor                      active                1       5       11
-> unwritten                  success               1       4       12
-> x11                        starting              0       5       12
-> ciaranm                    active                0       5       12
    ... Initialized empty Git repository in /var/db/paludis/repositories/ciaranm/.git/
-> unavailable                active                0       5       12
    ... Literal data: 0 bytes
    ... Matched data: 0 bytes
    ... File list size: 749
    ... File list generation time: 0.001 seconds
    ... File list transfer time: 0.000 seconds
    ... Total bytes sent: 771
    ... Total bytes received: 26
    ...
    ... sent 771 bytes  received 26 bytes  1594.00 bytes/sec
    ... total size is 57557  speedup is 72.22
-> unavailable-unofficial     active                0       5       12
    ... Literal data: 0 bytes
    ... Matched data: 0 bytes
    ... File list size: 110
    ... File list generation time: 0.001 seconds
    ... File list transfer time: 0.000 seconds
    ... Total bytes sent: 132
    ... Total bytes received: 26
    ...
    ... sent 132 bytes  received 26 bytes  316.00 bytes/sec
    ... total size is 4013  speedup is 25.40
-> arbor                      active                0       5       12
-> unavailable                success               0       4       13
-> unavailable-unofficial     success               0       3       14
-> x11                        active                0       3       14
-> ciaranm                    active                0       3       14
-> ciaranm                    success               0       2       15
-> x11                        success               0       1       16
-> arbor                      success               0       0       17

 * Cleaning write cache for ebuild format repositories...
 * Done cleaning write cache for ebuild format repositories

 * No unread news items found

Sync results

* alsa:                       sync of '/var/db/paludis/repositories/alsa' from 'git://git.exherbo.org/demonstrate/failure/alsa.git' failed (paludis::SyncFailedError)
    Log file:                 /var/log/sync-alsa.1225118654.log
* arbor:                      success
* ciaranm:                    success
* compnerd:                   success
* ferdy:                      success
* gnome:                      success
* hardware:                   success
* media:                      success
* mozilla:                    success
* pioto-exheres:              success
* python:                     success
* rbrown:                     success
* texlive:                    success
* unavailable:                success
* unavailable-unofficial:     success
* unwritten:                  success
* x11:                        success

In particular:

Output is automatically logged to a file, rather than dumping everything to the screen. That file can be automatically removed if the job succeeds.
A summary of what’s going on is displayed every time a job starts or finishes.
Every ten seconds (for some value of ten), if a job hasn’t finished, we automatically display the last ten (for some other value of ten) lines of its output (but not any output we’ve already displayed) to the screen, along with a note that it’s still active. We also tail the log if a job fails.

This seems to be a comfortable balance between not showing anything except job statuses (which for jobs that can take an hour to run might well leave you wondering whether it’s hung) and just dumping everything to the screen. Now it’s just a case of finding appropriate values of ten…

Tagged: paludis

Fernando J. Pereda: Reading II

Sun, 26 Oct 2008 21:13:17 +0000

Currently Reading

Anathem, Neal Stephenson. Quite nice, though the first pages are a bit weird.
Compiler Construction: Principles and Practice, Kenneth C. Louden.
Artificial Intelligence: A Modern Approach, Russel & Norvig. Really nice book, I’m really enjoying it.
Fuzzy Logic Systems for Engineering: A tutorial, Jerry M. Mendel.

— ferdy

Tagged: article, book, paper, reading

Fernando J. Pereda: Recent cool discoveries: unlockit and rlwrap

Sun, 26 Oct 2008 21:00:14 +0000

I’m easily annoyed by hardware and software. Recently, I’ve been annoyed by my iPhone 3G insisting on wasting my money by downloading useless shit over my cellular data network without even asking. Since I have WiFi almost everywhere and I don’t want to get a data plan, I wanted to disable the feature completely. Unfortunately, the iPhone wouldn’t let you do that easily. Fortunately, http://unlockit.co.nz/ exists. That disables the cellular network by setting an invalid APN and can be easily reverted when you really need it. Good stuff.

I’ve also been doing some lisp lately and was a happy clisp user until I had to do some CPU and memory intensive computations. sbcl works much better than clisp on OSX and has a profiler; however it lacks readline support (and I refuse to use emacs to interface with it). Without looking for it, I found this extremely cool application called rlwrap that turns any annoying non-readline shit into a nice readline-enabled application. Yay!

— ferdy

Tagged: apple, iphone, lisp, rant, software

Ciaran McCreesh: Paludis is about Choices

Fri, 24 Oct 2008 09:23:05 +0000

Paludis 0.32 will include a new mechanism called ‘choices’. Examples of choices on Gentoo include use flags, the various USE_EXPAND settings (linguas, video_cards and so on) and a shiny new setting called build_options. For use flags and the USE_EXPAND settings, there’s no change from a user perspective, and you can carry on using use.conf as normal — choices are merely a more general mechanism for handling package settings.

On Exherbo, things do change a bit, and if you’re one of those naughty people who ignored the “Exherbo has no users” warning you’d better have been paying attention.

So what’s this build_options thing? You’ll see it cropping up for most packages:

* net-print/cups::gentoo [U 1.3.8-r1 -> 1.3.8-r2] <target>
    Reasons: app-text/ghostscript-gpl-8.62:0::installed, net-print/foomatic-filters-3.0.20080507:0::installed, 2 more
    X acl -avahi -dbus -gnutls -java jpeg -kerberos -ldap pam perl -php png ppds python -samba
    -slp ssl -static -tiff -xinetd -zeroconf LINGUAS: -de en -es -et -fr -he -id -it -ja -pl -sv
    -zh_TW build_options: -optional_tests split strip

Packages using 0-based EAPIs will usually have three build options:

optional_tests. This handles what --checks used to do. If this choice is set, src_test will be run.
split. This used to be --debug-build split.
strip. This used to be --debug-build internal.

Packages using kdebuild-1 or exheres-0 will have recommended_tests instead of optional_tests, which defaults to being enabled rather than disabled.

Despite what you might expect from older Paludis versions, these are not use flags. You can set them in use.conf, though — this means you can select whether to run tests or whether to keep debug information on a per-package basis, which was tricky to do with the old commandline options.

Tagged: choices, exherbo, gentoo, paludis

Ciaran McCreesh: xorg-x11 hackery for a Logitech RX1000 Mouse

Thu, 23 Oct 2008 09:00:27 +0000

The Logitech RX1000 mouse has a scroll wheel that can tilt left or right. This generates HWHEEL events by default, which are pretty much useless. I find it more useful to have the tilt generate WHEEL events (scroll up and down), so I can press and hold left or right rather than repeatedly spinning the mouse wheel.

The wheel can also be pressed to get a middle click, but if I don’t concentrate I end up scrolling as well as middle clicking. There’s another button with a magnifying glass icon on it just below the scroll wheel which is more useful, which usually shows up as button 8. By making this button 2 we can use that for X11 paste, open-in-new-tab in Firefox and so on.

So I don’t forget how to get this working:

Section "InputDevice"
    Identifier  "Mouse1"
    Driver      "evdev"
    Option      "Name" "Logitech USB Optical Mouse"
    Option      "HWHEELRelativeAxisButtons" "4 5"
EndSection

Unfortunately, evdev doesn’t seem to have a ButtonMapping equivalent, so we have to fall back to xmodmap to do the button remapping. Doubly unfortunately, this makes pressing the middle mouse button useless.

pointer = 1 6 3 4 5 2 7 8 9 10

Thanks Nicolas.

Tagged: hardware, linux, logitech, mouse, rx1000, xorg-x11

Fernando J. Pereda: EeePC 901: Fighting the suckiness

Sun, 19 Oct 2008 13:04:08 +0000

Ok, so the machine is very nice but the software is very annoying. These are some ‘first tweaks’:

Edit /etc/X11/xorg.conf and set a bigger Virtual so that you can use a big resolution if you are going to use the Eee with an external monitor. You will still need to use xrandr by hand because their GUI has the resolutions hardcoded.

Copy IceWM’s config and set KeySysWindowList and KeySysWinListMenu to something. Don’t leave it empty or the power button will open the annoying window list.

Some people seem to like that shitty tabbed interface called ‘Easy Mode’ that is AsusLauncher. But the thing is that I really hate it, removing it is stupidly tricky, dirty and hacky. AsusLauncher is not a proper display manager, it is an aplication that just runs on top of icewm and asks you for a password. To remove it, this is what I did:

Copy /usr/bin/startsimple.sh to ~/.xsession and remove all the useless stuff. I left mine like this:

#!/bin/sh

BRN=`cat /etc/acpi/brn` >dev/null 2>&1
if [ -z "$BRN" ]; then
        BRN="10"
fi
echo $BRN > /proc/acpi/asus/brn

sudo /usr/bin/sessreg -a -l :0.0 -u /var/run/utmp user
if [ -d /home/user/Desktop ]; then
    if [ -d /home/user/.Desktop.bak ]; then
        rm -rf /home/user/.Desktop.bak
    fi
    if [ -d /home/user/.Desktop ]; then
        mv /home/user/.Desktop /home/user/.Desktop.bak
    fi
    mv /home/user/Desktop /home/user/.Desktop
fi
xhost + si:localuser:root # Allow local user root only to access the diplay

xset dpms 0 0 0
sleep 2

[ -n "$XIM_PROGRAM" ] && $XIM_PROGRAM &
[ -e /var/lock/xandros-rclock/webcam.lock ] && sudo rm /var/lock/xandros-rclock/webcam.lock
[ -e /var/lock/xandros-rclock/webcam.owner ] && sudo rm /var/lock/xandros-rclock/webcam.owner
sudo rm -f /tmp/nologin
rm -f /tmp/.fastlaunch

exec icewm-session

There is something racy going on with that script, the sleep 2 line seems to be important. Then some stuff has to go into .icewm/startup to start network and battery applets and AsusLauncher (yes, AFTER icewm started….). This is hacky but seems to do a good job:

#!/bin/sh

touch /home/user/.doingLogin
/opt/xandros/bin/AsusLauncher &
while [ -f /home/user/.doingLogin ] ; do sleep 0.2 ; done
killall AsusLauncher

powermonitor &
minimixer &
networkmonitor2 ra0 &
networkmonitor2 -i eth0 &
networkmonitor2 -i ppp0 &
/usr/bin/dispwatch &
/usr/bin/keyboardstatus &
/opt/xandros/bin/start_netserv &
/usr/local/bin/asusosd &

If the order of applets in the notification area is important it is possible to tweak where they appear by adding some sleep commands. I don’t particularly care though.

The acpi script that reacts to the power button will check whether AsusLauncher or KDE are running and if neither is, it just sends USR2 to init. This is a bit too much, editing this file was easy, my /etc/acpi/powerbtn.sh looks like this:

#!/bin/sh
# /etc/acpi/powerbtn.sh
# Initiates a shutdown when the power putton has been
# pressed.

if [ ! -f /home/user/.doingLogin ] ; then
        DISPLAY=:0 su -c /opt/xandros/bin/shutdown_dialog user &
fi

At this point, you’ve lost direct access to some of the applications that were there in the EasyMode interface, the paths for those applications are in /opt/xandros/share/AsusLauncher/simpleui.rc. Grab the ones you want and add them to IceWM’s menu.

I think I’ve done some more tweaks but those are the big ones. I’m hating this Xandros thing more and more, and I guess I’ll install Debian sooner rather than later.

— ferdy

Tagged: asus, eee pc, eeepc, hacks, netbook

Ciaran McCreesh: Path and installable-to dependencies

Thu, 16 Oct 2008 14:55:44 +0000

A while ago, Paludis got from-repository dependencies. 0.32 will extend this further with path and installable-to dependencies.

Path dependencies are fairly simple: cat/pkg::/ will match cat/pkg installed at root /. A full path can be used too, so cat/pkg::/var/mychroot will work (as well as anything involving non-/ roots works, anyway…).

Installable-to dependencies take a bit more explaining. There are two kinds of installable-to dependency: repository and path. An installable-to-repository dependency looks like cat/pkg::repo? and is matched by any cat/pkg that could be installed to the repository named repo. An installable-to-path dependency looks like cat/pkg::/? and is matched by any cat/pkg that could be installed to any repository with root /.

Installable-to dependencies will not match masked packages. To specify “packages that would be installable, ignoring masks”, use a double question mark, like cat/pkg::/??. At present the double question mark ignores all masks, even those that cannot be overridden (unsupported EAPI, unavailable or unwritten). This may change to only include overridable masks; I’m not sure which is better behaviour yet.

Tagged: paludis

Fernando J. Pereda: EeePC 901: First impressions

Wed, 15 Oct 2008 12:59:21 +0000

Last friday, I got myself a shiny EeePC 901. The machine is extremely nice and the bundled software JustWorks if you have very simple needs and are happy with the very few packages that are available. Battery life is very good too with wifi constantly on.

However, there are a number of oddities in the Xandros installation, some are just annoying and others really piss me off. Without any specific order:

It comes with mono, python, java, make, cpp, gdb but without gcc? And no, it is not available in their repos eiher.
You can’t enable/disable bluetooth without disabling the wireless card. It is possible to do it on the command line so it is just a software stupidity.
The installed vim version lacks support for mouse and there’s no gvim or a full vim package in their repos. Also, no indent is either installed or installable.
The GUI does not support WPA2 though it is possible to use it through wpa-supplicant
A Windows XP theme for icewm? Come on…
Stupidly big fonts and cursors, because there’s so much screen space to spare.
Their apt repositories are b0rked and some updates don’t work.
The only PDF reader available is acroread.
StarOffice instead of OpenOffice? Yeah, quoting spb: “for full enterprise readiness“.
No kernel source, so building additional modules (iptables, additional filesystems, …) is impossible.
External, USB drives get mounted as ‘D:’, ‘E:’, ‘F:’….
Your user has to be ‘user’ and many things hardcode /home/user. Yes, it is easy to change, it is just annoying
Samba and parport are enabled by default and there is no way to stop or disable them from the gui.
The terminal is hidden, an uxterm is available through Ctrl+Alt+T

That list is not complete but it is enough to ilustrate the point that the Xandros installation really sucks.

First things to do to get a not stupid environment:

Edit /usr/sbin/services.sh and /etc/fastservices and remove stuff like samba, portmap and lindvd.
Install xandros-wpa-supplicant needed for networks such as eduroam.
Copy /etc/X11/icewm to ~/.icewm to enable multiple workspaces and remove the SOS and tips buttons.
Install a proper theme (ThinBlack is a very good one) and a proper cursor theme such as DMZ-Vanilla.
Run sudo dpkg-reconfigure locales AND edit /etc/kde3/kdeglobals to get the system in english instead of dealing with wonky translations. Run something like aptitude or synaptic to remove locale-specific packages.
Run kcontrol to set smaller fonts

In theory, it is possible to use the debian apt repositories using pinning, however, I’m wondering if that’s better than just installing Debian on the EeePC.

All in all, a very nice machine and hardware and a very stupid software. Fortunately, the latter can be replaced.

— ferdy

Tagged: asus, eee pc, eeepc, hardware, netbook, rant, wtf

Ciaran McCreesh: Paludis 0.30.3 Released

Fri, 10 Oct 2008 18:28:57 +0000

Paludis 0.30.3 has been released:

Tests for 0.30.2 would fail on some systems. This is now fixed.

Tagged: paludis, release

Ciaran McCreesh: Paludis 0.30.2 Released

Thu, 09 Oct 2008 22:24:12 +0000

Paludis 0.30.2 has been released:

Work around ebuilds that treat cwd as secure.

Tagged: paludis, release

Ciaran McCreesh: Dealing with Unwritten Packages

Mon, 06 Oct 2008 21:57:14 +0000

A while ago Exherbo came up with a solution for the “large number of repositories” problem. It turns out this solution works rather well, and I’m now convinced that anyone rushing off and assuming that Git on its own will magically solve anything other than CVS sucking is going in the wrong direction.

Paludis also has ways of tracking packages installed by hand. Whilst useful on Gentoo, this really comes into play on Exherbo, where we don’t want to end up with a massive unmaintainable tree full of packages used by only two people.

The logical next step is tracking packages that don’t exist yet.

An unimaginative person might think that the way to solve this would be to have a bug for each requested package. But that gets messy — it’s not integrated with the package manager, and requires considerable extra effort from the user. A while ago Bernd suggested something more interesting: tracking unwritten packages in a repository in a similar way to how we do unavailable packages.

The implications:

Most obviously, we can keep track of things we want that haven’t been written yet in a way that doesn’t involve leaving the package manager to look things up.
We can also use it to track version bumps that we know will take a while. Doing paludis --query '>=hugescarypackage-4', say, would show that it’s being worked upon.
We can also depend upon things that don’t exist, rather than leaving incomplete dependency strings around. This is fine in at least two cases — if a dependency is conditional upon an option that should probably be implemented but isn’t yet, we can add the option and make it unusable. And we can handle obscure suggested dependencies (e.g. git has lots of optional dependencies upon weird perl modules, so we can say “if you want support for git-send-email with SSL, you need to write such and such a package”).
Bored developers could simply paludis --query '*/*::unwritten' and get ideas for what to do.

Adding support to Paludis for this only took a couple of hours. So now Exherbo developers can use this:

format = unwritten
location = /var/db/paludis/repositories/unwritten
sync = git://git.exherbo.org/unwritten.git
importance = -100

And see this:

$ paludis -q genesis
* sys-apps/genesis
    unwritten:               (1.0)X* {:0}
    Description:             The daddy of all init systems
    Homepage:                http://www.exherbo.org/
    Comment:                 We need an init system.
    Masked by unwritten:     Package has not been written yet

As with unavailable, installing behaves sensibly:

$ paludis -pi genesis
Building target list...
Building dependency list...
Query error:
  * In program paludis -pi genesis:
  * When performing install action from command line:
  * When executing install task:
  * When building dependency list:
  * When adding PackageDepSpec 'sys-apps/genesis':
  * All versions of 'sys-apps/genesis' are masked. Candidates are:
    * sys-apps/genesis-1.0:0::unwritten: Masked by unwritten (Package has not been written yet)

Those interested in the repository format can browse the tree. The observant might notice that the file format is quite similar to the one used by unavailable repositories, and wonder whether I was feeling lazy and swiped a load of code rather than implementing a new repository from scratch.

In the spirit of silly buzzwords, one could argue that this increases distributivity and democratisation of the repository, since there’s nothing to stop motivated users from creating their own wishlist repositories. It wouldn’t be hard to make a simple web interface that lets users request and vote on packages and version bumps, automatically generating a repository that anyone can use. But fortunately Exherbo is a dictatorship and has no users, so we don’t have to put up with that kind of nonsense.

Tagged: exherbo, gentoo, paludis, unavailable, unpackaged

Fernando J. Pereda: Generated versions of PMS

Mon, 06 Oct 2008 10:13:48 +0000

Yesterday I linked some PDF versions of PMS in its ‘home page’. This makes PMS more accessible to those that can’t or won’t install a proper TeX system since reading the LaTeX sources is a PITA.

I’ll generate and link versions approved by the Gentoo Council by checking out their signed tags and those versions that the PMS editors deem important. I’ll also link to current HEAD, but this won’t be automated so it might lag a bit if I’m extremely busy.

Also, for those that can’t be bothered reading technical documentation aimed at people implementing a package manager and want to know what’s new in EAPI2, Ciaran McCreesh has published a series of blag posts explaining the new features and whence they came. Make sure to take a look at What’s in EAPI 2?

— ferdy

Tagged: eapi, eapi 2, ebuild, figurehead, gentoo, paludis, pms

Alexander Færøy: Hello from Open Source Days

Sat, 04 Oct 2008 08:10:05 +0000

First picture from Open Source Days:

Ciaran McCreesh: EAPI 2: doman language support

Wed, 01 Oct 2008 10:10:23 +0000

This is the final post in a series on EAPI 2.

The doman helper is one of those pesky little beasts that makes specifying EAPI behaviour formally such a nuisance (although it is nowhere near as horrible as dohtml). EAPI 2 makes it even peskier.

I’ll try that again.

The doman helper makes writing ebuilds substantially easier by automagically doing the right thing when installing manual pages, freeing the developer from having to care about manual sections. EAPI 2 makes doman even more useful by making it aware of language codes as well as sections.

The painful details are available in PMS, but basically this will now ‘do the right thing’:

doman foo.1 foo.en.1 foo.en_GB.1

Previously only the first of the items would go to the right place.

This one’s a Gentoo innovation; see bug 222439 for its history. It was shamelessly stolen for exheres-0, but was too late for kdebuild-1.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: EAPI 2: default_ phase functions and the default function

Tue, 30 Sep 2008 10:15:19 +0000

This post is part of a series on EAPI 2.

With EAPIs 0 and 1, if you want to add something to, say, src_unpack, you have to manually write out the default implementation and then add your code. This is easy to screw up — developers are highly prone to getting the quoting wrong and forgetting which functions do and do not want a || die on the end.

EAPI 2 makes the default implementation of phase functions available as functions themselves. These functions are named default_src_unpack, default_src_configure and so on.

Typing out default_src_compile in full is pointless, though (especially since it’s illegal to call phase functions or default phase functions from other phase functions). So we also introduce the special default function, which calls whichever default_ phase function is appropriate for the phase we’re in. Thus:

src_compile() {
    default
    if useq extras ; then
        emake extras || die "splat"
    fi
}

Both features first appeared in exheres-0.

An alternative proposal (I think it came from the Pkgcore camp) was to make all EAPI default implementations available through functions named like eapi0_src_compile, eapi1_src_compile and eapi2_src_compile. This proposal was rejected because various Paludis people moaned about it not making sense or having any legitimate use cases (the ‘obvious’ use cases don’t work if you think them through), and no-one stood up to defend it.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: EAPI 2: src_configure and src_compile

Tue, 30 Sep 2008 10:10:54 +0000

This is post five in a series describing EAPI 2.

EAPI 2 splits src_compile into src_configure and src_compile. Like src_prepare, it’s mostly a convenience thing to reduce copying default implementations, although in this case it also makes it easier to hook in code in between configure and make being run.

The default src_configure implementation behaves like this:

src_configure() {
    if [[ -x ${ECONF_SOURCE:-.}/configure ]]; then
        econf
    fi
}

This is the first half of EAPI 1’s src_compile, not the non-ECONF_SOURCE-aware EAPI 0 version.

The default src_compile implementation is reduced accordingly:

src_compile() {
    if [[ -f Makefile ]] || [[ -f GNUmakefile ]] || [[ -f makefile ]]; then
        emake || die "emake failed"
    fi
}

The split configure / compile setup was first used in exheres-0, which uses more elaborate default implementations. Like src_prepare, it was considered but rejected for kdebuild-1 because of eclass difficulties.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: EAPI 2: src_prepare

Mon, 29 Sep 2008 10:02:47 +0000

This is post four in a series describing EAPI 2.

EAPI 2 has a new phase function called src_prepare. It is called after src_unpack, and can be used to apply patches, do sed voodoo and so on. The default implementation does nothing.

This function is purely for convenience. It gets rather tedious copying out the default implementation of src_unpack just to add a patch in somewhere.

src_prepare was first introduced in exheres-0 (which has a more elaborate default implementation). It was considered but rejected for kdebuild-1 because making best use of it requires eclass awareness, and the packages using kdebuild-1 had to share eclasses with the main Gentoo tree.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: EAPI 2: !! Blockers

Mon, 29 Sep 2008 10:01:55 +0000

This is part three of a series of posts describing EAPI 2.

Blockers are a nuisance for end users. It’s rarely obvious how to fix them or what they mean, and getting it wrong can leave systems unusable.

There have been various proposals on how to fix this. For exheres-0, we’re going to go with something like this:

DEPENDENCIES="
    !app-misc/superfrozbinator [[
        description = [ Can only have one frozbinator installed at once ]
        resolution = uninstall-blocked-after
        url = [ http://explain.example.org/?only-one-frozbinator ]
    ]]
    !dev-libs/icky [[
        description = [ Having icky installed breaks the build process ]
        resolution = [ manual ]
        url = [ http://explain.example.org/?myfroz-hates-icky ]
    ]]"

The user can then be presented with a list of things that would need to be uninstalled to resolve blockers, along with clear descriptions of why they need to do so. Once the user has explicitly accepted the uninstalls, the package manager could then safely perform the installs.

Unfortunately, annotations aren’t something that can be implemented for Portage any time soon. Instead, Portage has gone with a fairly horrible and dangerous semi-automatic block resolution system that sometimes removes blocked packages automatically (often screwing up the user’s system in the process). Whilst doing so, Portage changed the meaning of EAPI 0 / 1 blockers from “this must not be installed when we do the build” to “this must be uninstalled after we do the build”.

EAPI 2 introduces a new kind of blocker using double exclamation marks, like !!app-misc/other. This goes back to the old meaning of “this must not be installed when we do the build”, keeping !app-misc/other for “this must be uninstalled after we do the build”.

This does not, unfortunately, make the user any safer, but it does allow packages that really can’t have something installed at build time to say so.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Anders Ossowicki: The worst thing…

Sun, 28 Sep 2008 21:42:04 +0000

The worst thing about Open Source Days [danish] isn’t choosing which talks to attend (I never have time for talks anyway). The worst thing is doing weird LaTeX hacks to get their logo placed correctly in the agenda…
Turns out there’s this cool environment for wrapping figures in text named ‘wrapfig’ (gee, who thinks up all these names) that you can use for positioning an image a little more intelligently than the default, left-aligned placement. Alas, said environment (or something else - I am by no means a LaTeX guru), doesn’t play nicely with tables and as the majority of the page is made up by the actual agenda in a table, that means the logo ends up whereever it fits; in this case smack in the middle of the page. A lost cause? Of course not! <leonidas>This is LaTeX!</leonidas>. Take a look at this beauty:


\AddToShipoutPicture{
 \put(0,0){
  \parbox[b][420mm]{530mm}{
   \vfill
   \centering
   \includegraphics[width=60mm]{logo2008_small}
   \vfill
  }
 }
}

[courtesy of the same guy who wrote the aforementioned blagpost, Jesper Nyerup]

Of course, you might have to fiddle with the actual placement of the parbox but as far as I could tell from my experiments, this will place the image whereever you want it, no matter what is above or below it layerwise. At the point where Jesper pasted that, I had been driven to the nastier corners, fiddling with boundingboxes and another parbox-hack, none of which worked remotely as well as this solution.
An ugly hack, nonetheless, don’t use it if you can avoid it.

Also, this requires you to include the eso-pic package in your preamble.

Also, if you happen to attend Open Source Days on saturday, by all means come by the Exherbo user stand where we will be happy to act like the elistist bastards people assume we are and tell you exactly why you shouldn’t use Exherbo just yet.

Ciaran McCreesh: EAPI 2: Use Dependencies

Sun, 28 Sep 2008 18:46:38 +0000

This is the second post in a series of posts describing EAPI 2.

Use dependencies have been needed for a very long time. They eliminate most of the built_with_use errors you see during pkg_setup, replacing them with an error that is seen at pretend-install time.

The first two real world trials of use dependencies were with Exherbo’s exheres-0 and Gentoo’s kdebuild-1. It became apparent that an awful lot of packages would end up with dependencies like:

blah? ( app-misc/foo[blah] ) !blah? ( app-misc/foo )
monkey? ( app-misc/foo[monkey] ) !monkey? ( app-misc/foo[-monkey] )
fnord? ( app-misc/foo ) !fnord? ( app-misc/foo[-fnord] )

Syntactically, that’s rather inconvenient. For exheres-0 and kdebuild-1, we added the following syntax:

[opt]: The flag must be enabled.
[opt=]: The flag must be enabled if the flag is enabled for the package with the dependency, or disabled otherwise.
[opt!=]: The flag must be disabled if the flag is enabled for the package with the dependency, or enabled otherwise.
[opt?]: The flag must be enabled if the flag is enabled for the package with the dependency.
[opt!?]: The flag must be enabled if the use flag is disabled for the package with the dependency.
[-opt]: The flag must be disabled.
[-opt?]: The flag must be disabled if the flag is enabled for the package with the dependency.
[-opt!?]: The flag must be disabled if the flag is disabled for the package with the dependency.

Dependencies could be combined by specifying multiple blocks, as in foo/bar[baz][monkey?].

For EAPI 2, Zac decided to go with an arbitrarily different syntax:

[opt]: The flag must be enabled.
[opt=]: The flag must be enabled if the flag is enabled for the package with the dependency, or disabled otherwise.
[!opt=]: The flag must be disabled if the flag is enabled for the package with the dependency, or enabled otherwise.
[opt?]: The flag must be enabled if the flag is enabled for the package with the dependency.
[!opt?]: The flag must be disabled if the use flag is disabled for the package with the dependency.
[-opt]: The flag must be disabled.

And to combine use dependencies, one uses a comma, as in foo/bar[baz,monkey?].

In both cases, the slot dependency must go before the dependency, so foo/bar:1[baz], not foo/bar[baz]:1. The use dependency goes after any version restrictions, so >=foo/bar-2.1:2[baz].

In both cases, it is illegal to reference a use flag that does not exist (including USE_EXPAND flags that are not explicitly listed in IUSE). So foo/bar[opt] when any version of foo/bar does not have opt in IUSE is illegal and has undefined behaviour, as is foo/baz[opt?] if either the owning package or foo/baz has no opt. For cases where only some versions of a package have a flag, use dependencies can be combined with version or slot restrictions.

From an implementation perspective: the package manager should not try to automatically solve unmet use dependencies. The package manager doesn’t know the impact of changing a use flag (changing some flags makes a system unbootable), so it can’t simply override the user’s choice. (Paludis will suggest an automatic reinstall if and only if the user has already modified their use.conf, so you don’t need to manually reinstall a dependency if you’re ok with altering the flags with which it is built.)

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: EAPI 2: SRC_URI Arrows

Sun, 28 Sep 2008 15:18:18 +0000

This is the first item in a series of posts describing EAPI 2.

Some upstreams use annoyingly named tarballs. Most commonly, they don’t include either the package name or the version in the filename. Because DISTDIR is a flat directory, this causes problems — the tree must not use two different tarballs with the same name. Previously, the solution to horrible upstream naming was to manually mirror the tarball with a new filename; this was considered excessively icky.

There have been two sane solutions proposed for this over time. The one we didn’t use was to define a DISTDIR_SUBDIR variable, and do all downloads into there. This would have made the A variable quite a bit messier, and complicated sharing certain tarballs between packages.

The arrows solution was something I came up with for early Paludis experimental EAPIs, and was adopted for kdebuild-1 and from there into 2; it’s also always been present in exheres-0. It works like this:

SRC_URI="http://example.com/stupid-named/1.23/stupid.tar.bz2 -> stupid-1.23.tar.bz2"

or using variables:

SRC_URI="http://example.com/stupid-named/${PV}/${PN}.tar.bz2 -> ${P}.tar.bz2"

This tells the package manager to look at the URL on the left of the arrow, but save to the filename on the right.

Mirroring effects are slightly subtle. Consider:

SRC_URI="mirror://foo/${PN}/${PV}.tar.bz2 -> ${P}.tar.bz2"

The package manager will look both on mirror://foo/ and mirror://gentoo/ for the download. When looking on foo, the raw filename must be used, but when looking on gentoo, the rewritten filename is used.

Anyone using arrows on mirror://gentoo/ URIs gets stabbed.

Arrows make another proposed but rejected EAPI feature irrelevant: there was a proposal floating around (I think it originated with drobbins, but I can’t find an original source) to make unpack ignore ;sf=tbz2 and ;sf=tgz suffixes on filenames, for interoperability with gitweb. Arrows are a more general solution.

Implementation-wise, anyone still using a lexer-based parser will need a single token of lookahead for this. Apparently this causes minor inconveniences in some broken programming languages that only support what C++ calls input iterators; I consider this a good thing, because it might make people either use a better iterator model or stop using lexers.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: What’s in EAPI 2?

Sun, 28 Sep 2008 15:08:17 +0000

EAPI 2 has been approved by the Gentoo Council and so can now be used in ebuilds. The first package manager with support was Paludis 0.30.1; Portage support came along with 2.2_rc11.

EAPI 2 consists purely of extensions to EAPI 1. The new features are:

Formal definitions can be found in PMS; an overview of each feature will follow in subsequent posts.

Tagged: eapi, eapi 2, ebuild, gentoo, paludis

Ciaran McCreesh: Paludis 0.30.1 Released

Thu, 25 Sep 2008 21:55:14 +0000

Paludis 0.30.1 has been released:

EAPI 2 support.

Tagged: paludis, paludis releases

Bryan Østergaard: Software Freedom Day + Planet Larry

Fri, 19 Sep 2008 18:51:05 +0000

Tomorrow is Software Freedom Day - a yearly event where people all over the world get together to celebrate free software, enjoy talks related to free software and just as importantly get to meet lots of people.

If you happen to be in Copenhagen tomorrow you can meet myself and several other people from SSLUG at Copenhagen Business school. SSLUG's SFD program includes talks on Free Software, Linux, Open Office and GIMP. Everybody else can look up their local Software Freedom Day events - there's more than 500 teams registered all over the world so there's probably going to be an event nearby.

And regarding Planet Larry.. Steve Dibb just announced that he's setting up a feed for retired Gentoo developers which is very good news in my opinion. Lots of retired developers blog and they often have interesting comments on things related to Gentoo or tips that other people can benefit from. And this way people can know whether the blog posts they're reading comes from a normal user or a retired developer. I would probably have prefered marking retired developers another way instead of having multiple feeds but I can see why some people wants to know who's who and I'd much rather have a seperate feed than nothing at all. Oops, I was a bit too quick - Exdevs are now going in the main feed instead and will be marked using colour or some other way instead of a seperate feed.

And since I've been having this discussion with Steve on and off for quite some time: Thank you Steve :)

Fernando J. Pereda: iPhoto movies in FrontRow

Mon, 15 Sep 2008 15:33:19 +0000

Ok, so we all know that Apple makes software, and that its software is sometimes full of fail:

Even if their software usually integrates nicely, it really irritates me that some details are completely left out. For instance, iPhoto will import and manage movies from a digital camera. Then, when you are going to show the photos to the family with, for instance, FrontRow, the movies won’t come up. They’ll be ignored in the ‘Photos’ tab, and nothing will show up on the ‘Movies’ tab either.

Oh well, bash comes to the rescue:

iphoto2imovie()
{
	local DEST="${HOME}/Movies/iPhoto Movies/" d
	rm -rf "${DEST}"
	mkdir "${DEST}"
	find "${HOME}/Pictures/iPhoto Library/Originals/" \
		-iname '*.avi' -or -iname '*.mov' | while read f ; do
		d="${f%/*}"
		d="${DEST}/${d##*/}"
		mkdir "${d}" 2>/dev/null
		ln "${f}" "${d}"
	done
}

I just hate to have to do this by hand.

— ferdy

Fernando J. Pereda: GMandel meets Julia sets

Mon, 08 Sep 2008 01:08:54 +0000

I was bored and decided to hack support for viewing Julia sets into GMandel. The code could be nicer, but that will come tomorrow. I should really stop slacking and make a proper hierarchy of widgets (GFractMandel and GFractJulia should inherit a common GFractWidget) to make the code more manageable but this will do for now.

These are some examples of Julia sets generated with GMandel:

I strongly recommend The Computational Beauty of Nature to those interested or curious about this kind of stuff. It is a nice book that can even be read without too much mathematical or computer science background. One of the nice things about fractals and chaos is that you can see most the stuff yourself through pretty pictures.

— ferdy