October 10, 2008

Ciaran McCreesh

Paludis 0.30.3 Released


Paludis 0.30.3 has been released:

  • Tests for 0.30.2 would fail on some systems. This is now fixed.
   Tagged: paludis, release   

by Ciaran McCreesh at October 10, 2008, 18:28 UTC

October 09, 2008

Ciaran McCreesh

Paludis 0.30.2 Released


Paludis 0.30.2 has been released:

  • Work around ebuilds that treat cwd as secure.
   Tagged: paludis, release   

by Ciaran McCreesh at October 09, 2008, 22:24 UTC

October 06, 2008

Ciaran McCreesh

Dealing with Unwritten Packages


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   

by Ciaran McCreesh at October 06, 2008, 21:57 UTC

Fernando J. Pereda

Generated versions of PMS


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

      

by Fernando J. Pereda at October 06, 2008, 10:13 UTC

October 04, 2008

October 01, 2008

Ciaran McCreesh

EAPI 2: doman language support


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   

by Ciaran McCreesh at October 01, 2008, 10:10 UTC

September 30, 2008

Ciaran McCreesh

EAPI 2: default_ phase functions and the default function


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   

by Ciaran McCreesh at September 30, 2008, 10:15 UTC

EAPI 2: src_configure and src_compile


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   

by Ciaran McCreesh at September 30, 2008, 10:10 UTC

September 29, 2008

Ciaran McCreesh

EAPI 2: src_prepare


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   

by Ciaran McCreesh at September 29, 2008, 10:02 UTC

EAPI 2: !! Blockers


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   

by Ciaran McCreesh at September 29, 2008, 10:01 UTC

September 28, 2008

Anders Ossowicki

The worst thing…

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.

by Anders at September 28, 2008, 21:42 UTC

Ciaran McCreesh

EAPI 2: Use Dependencies


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   

by Ciaran McCreesh at September 28, 2008, 18:46 UTC

EAPI 2: SRC_URI Arrows


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   

by Ciaran McCreesh at September 28, 2008, 15:18 UTC

What’s in EAPI 2?


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   

by Ciaran McCreesh at September 28, 2008, 15:08 UTC

September 25, 2008

Ciaran McCreesh

Paludis 0.30.1 Released


Paludis 0.30.1 has been released:

  • EAPI 2 support.
   Tagged: paludis, paludis releases   

by Ciaran McCreesh at September 25, 2008, 21:55 UTC

September 19, 2008

Bryan Østergaard

Software Freedom Day + Planet Larry

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 :)

September 19, 2008, 18:51 UTC

September 15, 2008

Fernando J. Pereda

iPhoto movies in FrontRow


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

by Fernando J. Pereda at September 15, 2008, 15:33 UTC

September 08, 2008

Fernando J. Pereda

GMandel meets Julia sets


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

by Fernando J. Pereda at September 08, 2008, 01:08 UTC

September 03, 2008

Ciaran McCreesh

Paludis 0.30.0 Released


Paludis 0.30.0 has been released:

  • Paludis no longer includes wrappers for GNU awk, make, patch, and sed. Users of systems where the default versions are not the GNU versions must use PATH manipulation or aliases in /etc/paludis/bashrc to ensure that the GNU versions are used. (This is not necessary on typical Linux systems; check <command> --version if in doubt.)
  • Support for from- and in- repository deps.
  • Wildcards are now allowed for paludis –query, –uninstall, –install.
  • Unavailable format repositories are now documented and built by default.

by Ciaran McCreesh at September 03, 2008, 18:27 UTC

Bryan Østergaard

Meet Exherbo at Open Source Days!

That's right! Exherbo will be at the Open Source Days conference october 3-4 and ticket sale opened a few days ago.

Open Source Days expects 2000+ visitors and have lots of talks ranging from open source project management to more technical networking talks as well as talks large scale open source deployment. I'll be talking about the Exherbo project of course - how it all began, the current ideas defining Exherbo and some of the technical features support those ideas. Besides my talk Exherbo will also have a booth where you can meet several of our developers.

I hope to meet lots of people at OSD and get to discuss different aspects of Exherbo - it's an exciting project with lots of interesting features and above all room for innovative new features and improvements.

September 03, 2008, 13:12 UTC

August 27, 2008

Ingmar Vanhassel

KDE on Exherbo


In between all the things a developer can possibly do in Exherbo, we’ve finally found the time to package KDE for Exherbo! A bit on the late side, but better late than never. Meanwhile, while you are testing KDE 4.1.0 on Exherbo, we’ll be working on KDE 4.1.1, our first real KDE bump. :-)

For those of you who are curious, you can find the git repository at here. To clone it install dev-scm/git and run

git clone git://git.exherbo.org/kde.git kde

Those of you who use(d) Gentoo will notice that we’ve changed quite a few things, most notably: parts.
As you’ll see if you followed the gitweb link, we’re not offering split KDE packages. Instead we hope to be able to use parts when that has been fleshed out properly. In practice this means that one exheres maps to one KDE tarball, as provided by upstream. Parts will still allow you to select what KDE programs you do or do not want to install.

In general we want to stay as close to upstream as possible, and this is just another result of that. After all the time we spent on packaging KDE on Gentoo, we’re not convinced that splitting up everything, in a source distro, is the way to go. We’d better take that effort upstream instead. If we ever do split packages in Exherbo we will definitely not split it out in one package per sub-directory but instead we’ll only add packages that we know people will like to use, or disable.

I must say I was really surprised by the quality of this release, and no doubt KDE 4.1.1 will be even better, so enjoy!

(Logo by Ida Jensen, with changes by Anders ‘arkanoid’ Ossowicki, thanks!)

by ingmarv at August 27, 2008, 18:55 UTC

August 25, 2008

Ingmar Vanhassel

New Exherbo stages


It’s about time I start blogging about Exherbo

We’ve been making a fair bit of progress recently. Even though, at this stage, we focus on improving exheres-0, the packaging format, we already have lots packaged. More on that later.
Up to now we’ve been neglecting to build newer stages, which, given how fast exheres-0 changes, makes it slightly annoying to install Exherbo on real hardware, or to quickly create a chroot to try new things out.
Hence why over the past days Bo Ørsted Andresen (zlin) has been working on scripting stage building.

The process is really rather simple, and goes roughly like this:

  • Create target directories:


    mkdir ~/stage
    cd ~/stage
    mkdir -p ~/stage/{etc,var/db/paludis/repositories/installed,var/db/unpackaged,var/cache/paludis/metadata,var/cache/paludis/distfiles,var/tmp/paludis/build,var/repositories}
    chown paludisbuild:paludisbuild ~/stage/var/tmp/paludis/build
    chmod g+rwx ~/stage/var/tmp/paludis/build

  • Configure paludis in ~/stage/etc/paludis, as you normally would when setting up a new system.


    mkdir ~/stage/etc/paludis/
    vi ~/stage/etc/paludis/bashrc

  • Check out Arbor from git and bind mount it in the right place.


    git clone git://git.exherbo.org/arbor.git

  • Use on the host system:


    echo “/location/to/stage” >> /etc/paludis-stage/specpath.conf

  • Install the basesystem and make sure sys-apps/skeleton-filesystem-layout gets installed first


    paludis –install –environment :stage baselayout
    paludis –install –environment :stage system
    paludis –install –environment :stage dhcpcd vim gdb strace colordiff screen

  • Chroot to the stage you just built, and rebuild everything in the chroot:


    paludis –install –dl-reinstall always everything

  • Work out what is broken and go fix it.
  • This is a temporary solution pending a new resolver which will make using Paludis’ binary packages (pbins) feasible (and thus superior). Until that resolver is released we’ll attempt to keep these stages for x86 and amd64 updated.

    You can find his updated stages here:

  • Exherbo amd64 (154M)
  • Exherbo x86 (142M)
  • And bzipped tarballs, for those of you who don’t have lzma around yet:

  • Exherbo amd64 (233M)
  • Exherbo x86 (221M)
  • Safety first kids, and check the sha1sums before using them. ;-)

    by ingmarv at August 25, 2008, 22:04 UTC

    August 24, 2008

    Fernando J. Pereda

    Security Trivia IV


    This one is easy and sweet. Your goal is to make this program crash and explain why that happened, good luck:

    #include <stdio.h>
    #include <stdlib.h>
    
    int main(int argc, char *argv[])
    {
    	if (argc != 4) {
    		fprintf(stderr, "DIAF\n");
    		return EXIT_FAILURE;
    	}
    
    	char c[3];
    	unsigned i;
    	for (i = 0; i < sizeof(c); i++)
    		c[i] = atoi(argv[i + 1]);
    
    	if (c[0] + c[1] + c[2] == 0) {
    		fprintf(stderr, "No no\n");
    		return EXIT_FAILURE;
    	}
    
    	c[1] += c[0] + c[2];
    	printf("%d\n", c[0]/c[1]);
    
    	return EXIT_SUCCESS;
    }

    Before spoling your own fun looking at the comments, try to do it yourself. Really, it is easy, and will make you understand C better.

    — ferdy

    by Fernando J. Pereda at August 24, 2008, 12:02 UTC

    August 20, 2008

    Ciaran McCreesh

    Now look what I’ve done


    For those of you wondering what this is all about…

    < ciaranm> dev-zero, dav_it: name the three most important improvements gentoo has delivered to users in the past year
    < dev-zero> ciaranm: in the past year: talking in "features" of the distro itself you might add irix-support, freebsd-support or the like
    

    Now, I’m not saying those aren’t interesting to some people, but to users in general? The best that anyone’s managed is something that’s used by maybe one user in a thousand? Even I find that rather hard to believe… Surely someone can come up with a better answer than that…

    by Ciaran McCreesh at August 20, 2008, 15:12 UTC

    August 19, 2008

    Bryan Østergaard

    Credit where credit is due

    All open source developers get for their hard work most of the time is credit - other people knowing they did some hard work and sometimes even other people acknowledging and thanking them for it.

    Anybody who's been doing open source development for a few years knows this which is why I'm extremely surprised to see Diego "flameeyes" Pettenò trying to hide other developers work.

    In one of his many blog posts Diego talks about ABI dependencies and how that's important for cross compiling among other things. As it turns out I agree this is important and more to the point, David Leverton (a Paludis and Exherbo developer) pointed out quite a bit of prior work being done on this exact problem in Exherbo.

    David did so in the following comment:

    You might want to talk to spb about that, he did some design work for Exherbo a while back (he's been too lazy to implement it so far, though). See http://git.exherbo.org/?p=exherbo.git;a=tree;f=scratch/multilib and http://dev.exherbo.org/~spb/labels.txt

    This comment is nothing but helpful and friendly even if Diego might not want to talk to spb as they have some history - the comment still points directly at prior work being done in this exact area that Gentoo could easily benefit from and hiding it (by not allowing the comment) is dishonest at best.

    I hope Diego is going to be a lot more cooperative in the future and actually follow the open source spirit instead of trying to mimic behaviour that's primarily seen from closed source companies.

    August 19, 2008, 08:44 UTC

    August 17, 2008

    Bryan Østergaard

    Goals for Exherbo

    Just a quick note that I wrote up a long list of things Exherbo still needs on http://lists.exherbo.org/pipermail/exherbo-dev/2008-August/000254.html.

    Reading that list and any follow-up discussion is probably a good way to follow Exherbo development for the foreseeable future and might give some insights into what goes on behind the doors for those of you with no real experience in distribution development.

    August 17, 2008, 23:08 UTC

    August 15, 2008

    Bryan Østergaard

    FOSS Aalborg videos released!

    Some of you might remember me doing a presentation on Exherbo and primarily our planned initsystem a few months ago at the FOSS Aalborg conference in Denmark.

    Most of the videos are now available including the one of my presentation. The presentation isn't highly technical but I talk a lot about why I don't think other initsystems solve the problems very well as well as what I expect from an initsystem. The video should be fairly interesting to all the people who wasn't at the FOSS Aalborg conference.

    Hope you like the presentation(s) and thanks to the FOSS Aalborg organisers for getting the videos online and for having a great conference.

    August 15, 2008, 20:06 UTC

    August 12, 2008

    Ciaran McCreesh

    Making Paludis Compile with C++0x


    I managed to get gcc 4.4 svn to compile, so I decided to see just how badly the experimental C++0x support would break Paludis. Turns out, not too badly. Firstly, things caught by increased strictness or general rearrangement of headers:

    • We had a few extra semicolons lying around. These now generate warnings, so we might as well shut them up. [fix]
    • We weren’t including <stdint.h> to get uintptr_t. Things were working by fluke because other headers were including it. [fix]
    • We were using ::rename rather than std::rename. [fix]

    Then, the real issues:

    • n2246 adds a std::next. Paludis has a paludis::next. ADL means this sometimes causes confusion. To keep compatibility with non-0x compilers, we use using to get std::next into paludis:: where necessary. [fix]
    • std::list<>::push_back is now overloaded on rvalue references, so we can no longer easily get a PMF. If we were only interested in 0x, we’d use a lambda, but for backwards compatibility we write a wrapper function instead. (Or we could use the static_cast hack, but that’s horribly unreadable.) [fix]

    All in all, not too bad. I suspect things will get a bit messier if a concept-enabled standard library makes it into the final proposal, but that can be dealt with later…

    by Ciaran McCreesh at August 12, 2008, 13:20 UTC

    August 11, 2008

    Ciaran McCreesh

    From-Repository Dependencies


    Paludis trunk has a new feature that has a few interesting abuses: from-repository dependencies.

    Normal repository dependencies, which are written cat/pkg::repo, find packages that are now in repository repo. These can be used to install or query versions from a particular repository, mask or keyword based upon repository and so on. But what you can’t do is, say, paludis --uninstall cat/pkg::gentoo, since when a package is installed it is a member of the installed repository and is no longer in the repository from which it was installed.

    From-repository dependencies solve this. A from-repository dependency looks like cat/pkg::repo->, which means cat/pkg that was originally from repo. So now you can do crazy things like paludis --uninstall '*/*::sunrise->' (the quoting is important with any sane shell).

    In- and from- repository dependencies can be combined, so cat/pkg::from->in is legal. cat/pkg::->in is also accepted, meaning the same as cat/pkg::in.

    The definition of ‘from’ is worth discussing. A package is from ‘repo’ if any of:

    • It was installed from the source repository ‘repo’.
    • It was installed from the binary repo ‘repo’.
    • It was installed from a binary that was generated from the source repository ‘repo’.
    • It is in an unavailable repository and represents a package that would be from ‘repo’ if that repo were configured.

    That last one is dleverton’s idea, and can be used to do some rather neat tricks:

    $ paludis -q 'gcc::dirtyepic->'
    * sys-devel/gcc::dirtyepic->
        layman:                  (4.3.2_pre9999 (in ::dirtyepic))X {:4.3-svn} (4.4.0_pre9999 (in ::dirtyepic))X* {:4.4-svn}
        Description:             The GNU Compiler Collection.
        Owning repository:       dirtyepic
        Repository homepage:     http://overlays.gentoo.org/dev/dirtyepic
        Repository description:  Various work-in-progress stuff including GCC-svn and wxGTK.
        Masked by unavailable:   In a repository which is unavailable
    

    One thing you still can’t do with this syntax is something like paludis --install '*/*::kde4-experimental->' to reinstall everything that was originally installed from the kde4-experimental repository. The wildcard expansion works as expected, but then the from-repository restriction limits the install candidates to already-installed packages. Perhaps something like --drop-repository-restrictions-after-wildcard-expansion or --late-rewrite-targets '%q%v%s' is in order… Or perhaps we could add cat/pkg::(repo)->, where (things) are only used for wildcard expansion purposes…

    by Ciaran McCreesh at August 11, 2008, 10:13 UTC

    August 04, 2008

    Ciaran McCreesh

    Paludis 0.28.2 Released


    Paludis 0.28.2 has been released:

    • Paludis now supports syncing from Mercurial repositories.
    • Certain user setups would sometimes lead to set*id bits being dropped. We now work around this.

    by Ciaran McCreesh at August 04, 2008, 19:15 UTC

    August 03, 2008

    Alexander Færøy

    Inkpot theme for Mutt


    I am using Mutt as my e-mail client and I have done that ever since I started using Unix. I have for many months been annoyed by my very ugly theme that I created when I was around 13, but I have never actually spend a few minutes on making something shiny that didn’t piss me off.

    Inspired from Ciaran McCreesh’s Vim theme called Inkpot, I decided to create an inkpot’ish theme for Mutt and here is the result that you can put in your .muttrc:

    color   attachment  color30 color80
    color   header      color10 color80 "^(From|Subject|cc|date|To|X-Spam-Level|User-Agent|X-Mailer):"
    color   signature   color39 color80
    color   tree        color26 color80
    color   message     color26 color80
    color   status      color85 color81
    color   normal      color78 color80
    color   error       color79 color64
    color   indicator   color80 color73
    color   markers     color26 color80
    color   index       color64 color80 ~D
    color   index       color64 color80 ~F
    color   index       color30 color80 ~T
    color   tilde       color80 color80
    
    color   body        color10 color80 "(http|https|ftp|news|telnet|finger|irc)://[^ \">\t\r\n]*"
    color   body        color10 color80 "mailto:[-a-z_0-9.]+@[-a-z_0-9.]+"
    color   body        color26 color80 "[;:=][-][)/(|]"
    
    color   quoted      color52 color80
    color   quoted1     color22 color80
    color   quoted2     color71 color80

    Note: This probably only works in urxvt since that’s what I am using :)

    There is, of course, a screenshot:

    Mutt

    Mutt

    by Alexander Færøy at August 03, 2008, 21:36 UTC

    August 02, 2008

    Ciaran McCreesh

    xorg-x11 keycodes for a Logitech 350 Keyboard


    To save myself from having to mess around with xev again in the future: here’re the keycodes for a Logitech 350 USB keyboard with xorg-x11 on Linux:

    keycode 129 = XF86AudioMedia
    keycode 236 = XF86Mail
    keycode 178 = XF86WWW
    keycode 161 = XF86Calculator
    keycode 162 = XF86AudioPlay
    keycode 174 = XF86AudioLowerVolume
    keycode 176 = XF86AudioRaiseVolume
    keycode 160 = XF86AudioMute
    

    These go in ~/.Xmodmap. And in ~/.fluxbox/keys, we can use:

    XF86Mail                 :ExecCommand claws-mail
    XF86WWW                  :ExecCommand firefox
    XF86Calculator           :ExecCommand xterm
    XF86AudioPlay            :ExecCommand mpc toggle
    XF86AudioLowerVolume     :ExecCommand amixer set PCM 2-
    XF86AudioRaiseVolume     :ExecCommand amixer set PCM 2+
    XF86AudioMute            :ExecCommand amixer set Master toggle
    

    by Ciaran McCreesh at August 02, 2008, 17:38 UTC

    July 30, 2008

    Ciaran McCreesh

    My Exherbo Supplemental Repository


    I’ve tidied up my Exherbo supplemental repository (which is what Gentoo people confusingly call an ‘overlay’) and published it for the foolish.

    Current goodness is:

    Expect these to be neglected and / or broken irregularly.

    by Ciaran McCreesh at July 30, 2008, 20:06 UTC

    July 24, 2008

    Ciaran McCreesh

    Paludis 0.28.1 Released


    Paludis 0.28.1 has been released:

    • Work around compiler issues that eventually lead to unpack dying when it shouldn’t on certain EAPIs on certain systems (ticket:622).

    by Ciaran McCreesh at July 24, 2008, 13:26 UTC

    July 22, 2008

    Ciaran McCreesh

    GNU ‘make’ Target Specific Variables are Dumb


    Let’s say we have a Makefile using some target-specific variables:

    $ cat Makefile
    foo = global
    b : foo = for-b
    
    all : d
            @cat d
    
    a :
            @echo a:$(foo) > a
    
    b : a
            @{ cat a ; echo b:$(foo) ; } > b
    
    c : a
            @{ cat a ; echo c:$(foo) ; } > c
    
    d : b c
            @cat b c > d
    

    Then we can get different results depending upon how we make the ‘all’ target:

    $ rm a b c d ; make
    a:for-b
    b:for-b
    a:for-b
    c:global
    $ rm a b c d ; make a b c d all
    a:global
    b:for-b
    a:global
    c:global
    

    This is considered a feature:

    There is one more special feature of target-specific variables: when you define a target-specific variable that variable value is also in effect for all prerequisites of this target, and all their prerequisites, etc. (unless those prerequisites override that variable with their own target-specific variable value).

    In practice, it’s a pain in the ass. Using Quagmire, you’re supposed to be able to do this:

    noinst_SHARED_LIBRARIES = libone.so libtwo.so libthree.so
    
    libone.so_SOURCES = one.c
    libone.so : LDFLAGS = -Wl,-soname,libone.so
    libone.so_LIBS = libthree.so
    
    libtwo.so_SOURCES = two.c
    libtwo.so : LDFLAGS = -Wl,-soname,libtwo.so
    libtwo.so_LIBS = libthree.so
    
    libthree.so_SOURCES = three.c
    

    Which leads to some rather bizarre behaviour:

    $ make clean all &>/dev/null ; scanelf -S libthree.so
     TYPE   SONAME FILE
    ET_DYN libone.so libthree.so 
    
    $ make clean libone.so &>/dev/null ; scanelf -S libthree.so
     TYPE   SONAME FILE
    ET_DYN libone.so libthree.so 
    
    $ make clean libtwo.so &>/dev/null ; scanelf -S libthree.so
     TYPE   SONAME FILE
    ET_DYN libtwo.so libthree.so 
    
    $ make clean libthree.so &>/dev/null ; scanelf -S libthree.so
     TYPE   SONAME FILE
    ET_DYN  libthree.so
    

    I can think of a few not very nice ways of getting around this. Hopefully someone will come up with something better…

    by Ciaran McCreesh at July 22, 2008, 19:41 UTC

    July 16, 2008

    Ciaran McCreesh

    Hot Fresh Shiny Config Files


    I’ve moved my configuration files repository from Subversion to Git, since I’m sick of trying to decide whether my laptop or desktop should hold the ‘master’ copy. For the lulz, I shall also push to GitHub at irregular intervals, so you shall no longer need to pester me to upload newer versions of my bashrc / vimrc / whatever to webspace somewhere. Instead, you can just:

    git clone git://github.com/ciaranm/dotfiles-ciaranm.git

    Or browse them online.

    We’ll see whether this lasts…

    by Ciaran McCreesh at July 16, 2008, 19:31 UTC

    Git and Subversion information in the Bash Prompt


    Here’s my variation on the “Git and Subversion status in the bash prompt” thing:

    ps_scm_f() {
        local s=
        if [[ -d ".svn" ]] ; then
            local r=$(svn info | sed -n -e '/^Revision: \([0-9]*\).*$/s//\1/p' )
            s="(r$r$(svn status | grep -q -v '^?' && echo -n "*" ))"
        else
            local d=$(git rev-parse --git-dir 2>/dev/null ) b= r= a=
            if [[ -n "${d}" ]] ; then
                if [[ -d "${d}/../.dotest" ]] ; then
                    if [[ -f "${d}/../.dotest/rebase" ]] ; then
                        r="rebase"
                    elif [[ -f "${d}/../.dotest/applying" ]] ; then
                        r="am"
                    else
                        r="???"
                    fi
                    b=$(git symbolic-ref HEAD 2>/dev/null )
                elif [[ -f "${d}/.dotest-merge/interactive" ]] ; then
                    r="rebase-i"
                    b=$(<${d}/.dotest-merge/head-name)
                elif [[ -d "${d}/../.dotest-merge" ]] ; then
                    r="rebase-m"
                    b=$(<${d}/.dotest-merge/head-name)
                elif [[ -f "${d}/MERGE_HEAD" ]] ; then
                    r="merge"
                    b=$(git symbolic-ref HEAD 2>/dev/null )
                elif [[ -f "${d}/BISECT_LOG" ]] ; then
                    r="bisect"
                    b=$(git symbolic-ref HEAD 2>/dev/null )"???"
                else
                    r=""
                    b=$(git symbolic-ref HEAD 2>/dev/null )
                fi
    
                if git status | grep -q '^# Changed but not updated:' ; then
                    a="${a}*"
                fi
    
                if git status | grep -q '^# Changes to be committed:' ; then
                    a="${a}+"
                fi
    
                if git status | grep -q '^# Untracked files:' ; then
                    a="${a}?"
                fi
    
                b=${b#refs/heads/}
                b=${b// }
                [[ -n "${r}${b}${a}" ]] && s="(${r:+${r}:}${b}${a:+ ${a}})"
            fi
        fi
        s="${s}${ACTIVE_COMPILER}"
        s="${s:+${s} }"
        echo -n "$s"
    }
    

    This is added to PS1 as normal.

    For Subversion, it gives us the revision, and a * if anything’s been modified.

    For Git, we get quite a bit more. If we’re in the middle of a merge, interactive rebase or am, we get told so. If we’re in the middle of a bisect, we get question marks, since I’ve not had to bisect anything since I wrote that code and I haven’t implemented anything fancy for it. We also get the branch, and a combination of * for changed but not updated files, + for changed and committed files and ? for untracked files.

    It’s generally sufficiently fast to not be annoying, although the initial cd into a large project can take a few seconds. It’s probably possible to drop to a single ‘git status’ call if performance matters, although the kernel does a pretty good job of speeding up subsequent runs.

    by Ciaran McCreesh at July 16, 2008, 10:10 UTC

    July 14, 2008

    Ciaran McCreesh

    Edimax EW-7728In 802.11n (RaLink rt2860) with Linux 2.6.26


    Being sick of wireless disconnecting every time it rained, I got my hands upon a cheap Edimax EW-7728In PCI 802.11n card. This uses a RaLink rt2860 (PDF) chip, which has vendor-supplied open source drivers available. Getting it to work with Linux 2.6.26 is slightly non-trivial, however.

    First, we need the drivers. At the time of writing, that means 2008_0522_RT2860_Linux_STA_v1.6.1.0.tar.bz2.

    Next, we need to fix a couple of things. First, the Makefile is dumb, and tries to install into /tftpboot:

    From 82dc3a8737e4f97311f4f4fccd79ea55a319f1ea Mon Sep 17 00:00:00 2001
    From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
    Date: Mon, 14 Jul 2008 16:47:00 +0100
    Subject: [PATCH] Get your filthy paws off my /tftpboot
    
    ---
     Makefile |    2 --
     1 files changed, 0 insertions(+), 2 deletions(-)
    
    diff --git a/Makefile b/Makefile
    index 72bc933..aed3b00 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -80,11 +80,9 @@ LINUX:
     ifneq (,$(findstring 2.4,$(LINUX_SRC)))
            cp -f os/linux/Makefile.4 $(RT28xx_DIR)/os/linux/Makefile
            make -C $(RT28xx_DIR)/os/linux/
    -       cp -f $(RT28xx_DIR)/os/linux/rt$(CHIPSET)sta.o /tftpboot
     else
            cp -f os/linux/Makefile.6 $(RT28xx_DIR)/os/linux/Makefile
            make  -C  $(LINUX_SRC) SUBDIRS=$(RT28xx_DIR)/os/linux modules
    -       cp -f $(RT28xx_DIR)/os/linux/rt$(CHIPSET)sta.ko /tftpboot
     endif
    
     clean:
    --
    1.5.6.2
    

    Next, dev->nd_net should now be dev_net(dev):

    From 0878b37a40e2a7f466a74938920ff3751917eec3 Mon Sep 17 00:00:00 2001
    From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
    Date: Mon, 14 Jul 2008 16:48:50 +0100
    Subject: [PATCH] dev->nd_net is now dev_net(dev)
    
    ---
     os/linux/rt_main_dev.c |    2 +-
     1 files changed, 1 insertions(+), 1 deletions(-)
    
    diff --git a/os/linux/rt_main_dev.c b/os/linux/rt_main_dev.c
    index 24604da..6a3471d 100644
    --- a/os/linux/rt_main_dev.c
    +++ b/os/linux/rt_main_dev.c
    @@ -669,7 +669,7 @@ static NDIS_STATUS rt_ieee80211_if_setup(struct net_device *dev, PRTMP_ADAPTER p
    
     #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,0)
     #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,24)
    -        device = dev_get_by_name(dev->nd_net, slot_name);
    +        device = dev_get_by_name(dev_net(dev), slot_name);
     #else
                    device = dev_get_by_name(slot_name);
     #endif
    --
    1.5.6.2
    

    Finally, the driver is unusably noisy. Unless you want fifty-odd lines of kernel debug informatione every five seconds:

    From 19c7a6895333624566775541fbc836e0c9208225 Mon Sep 17 00:00:00 2001
    From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
    Date: Mon, 14 Jul 2008 16:47:43 +0100
    Subject: [PATCH] You shut your dirty whore mouth
    
    ---
     include/rt_linux.h |    4 ----
     1 files changed, 0 insertions(+), 4 deletions(-)
    
    diff --git a/include/rt_linux.h b/include/rt_linux.h
    index dfe4ab5..079d256 100644
    --- a/include/rt_linux.h
    +++ b/include/rt_linux.h
    @@ -325,10 +325,6 @@ extern ULONG    RTDebugLevel;
    
     #define DBGPRINT_RAW(Level, Fmt)    \
     {                                   \
    -    if (Level <= RTDebugLevel)      \
    -    {                               \
    -        printk Fmt;               \
    -    }                               \
     }
    
     #define DBGPRINT(Level, Fmt)    DBGPRINT_RAW(Level, Fmt)
    --
    1.5.6.2
    

    There’s no Makefile install target, so you’ll need to sudo cp os/linux/*.ko /lib/modules/`uname -r`/kernel/ then sudo depmod -a before you can sudo modprobe rt2860sta. You’ll also need to sudo mkdir -p /etc/Wireless/RT2860STA/ then cp RT2860STA.dat /etc/Wireless/RT2860STA/, even though we’re not using that file for any configuration.

    Gentoo’s init scripts, if you’re using them, try to be overly clever, and won’t be able to bring up the interface. So use something like this as your /etc/init.d/net.ra0:

    #!/sbin/runscript
    
    depend() {
        need localmount
        after bootmisc hostname net.lo net.lo0
        use isapnp isdn pcmcia usb wlan
    }
    
    start() {
        bash -x -c 'ifconfig ra0 up'
        bash -x -c 'iwconfig ra0 essid giant-space-monkey key "aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66" freq 2.417G'
        bash -x -c 'dhcpcd ra0'
    }
    
    stop() {
        :
    }
    
    restart() {
        :
    }
    

    And that appears to be sufficient.

    by Ciaran McCreesh at July 14, 2008, 16:11 UTC