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…

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…

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…

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.

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