For ages now, I’ve just wanted to be automatically logged in and greeted by an X session when I boot, especially since my xdm died after some upgrade about a year ago or so ago. For how much time I spend with this machine, I’m amazed how long it takes me before deciding that logging in in the console and typing startx might be not such a good idea.

(It probably has everything to do with “conditionality”. I tell myself, for example, that before ditching xdm (which is one of the few X login managers which doesn’t support auto login), I first need to get it to work again to make a screenshot of my “cute” configuration. Can’t kill my darlings; never could.)

So fuck all that. I’m too lazy to resurrect my darling, no matter how cute, so I took a look at this and added to following to /etc/conf.d/local.start:

# Start X as user if tty7 is free
if ! fuser /dev/tty7 >& /dev/null; then
    su - bigsmoke -l -c 'exec startx -- vt7 >& ~/.xsession-errors' &
fi

Done. Maybe I’ll also decide to make all my console sessions auto-login, if I can be arsed, that is.

First of all, I had to replace x11-drivers/synaptics (http://web.telia.com/~u89404340/touchpad/) with the newer x11-drivers/xf86-input-synaptics, which is automatically installed if you set INPUT_DEVICES="${INPUT_DEVICES} synaptics" or if you add “x11-base/xorg-server input_devices_synaptics” to /etc/portage/package.use.

Starting with X.org 7.3, you’re supposed to use HAL for all the X input configuration. All the "InputDevice" sections have to be removed from xorg.conf (and of course the references in "ServerLayout"). If you don’t want this, you can add the following options:

Section "ServerFlags"
  Option "AllowEmptyInput" "off"
  Option "AutoEnableDevices" "off"
EndSection

I chose HAL. I wanted to replicate the following settings using HAL.

Section "InputDevice"
    Identifier "Keyboard1"
    Driver     "kbd"
    Option "AutoRepeat" "500 30"
    Option "XkbRules"  "xorg"
    Option "XkbModel"  "thinkpadintl"
    Option "XkbLayout" "us"
    Option "XkbOptions"        "ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e"
EndSection
 
Section "InputDevice"
    Identifier "Synaptics Touchpad"
    Driver     "synaptics"
    Option "SendCoreEvents" "true"
    Option "Device" "/etc/psaux"
    Option "Protocol"    "auto-dev"    # Auto detect
#    Option "TouchpadOff" "1" #Uncomment if you just want to disable the touchpad and use only the trackpoint
#    Option "HorizScrollDelta" "0" #Why is this in here by default. By Gods, it kill horizontal scrolling!
    Option "RightEdge" "5500" #This is a little bigger than the default narrowing the scroll region
    Option "BottomEdge" "4500" #This is a little bigger than the default narrowing the scroll region
    Option "RTCornerButton" "0" #disable Right Top corner "button" 
    Option "RBCornerButton" "0" #disable Right Top corner "button" 
    Option "SHMConfig" "on" #this allows configuration of the touchpad using qsynaptics, synclient, or what have you
EndSection

The keyboard part was easy. I copied /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/99-keymap.fdi and made a few adjustments:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>
 
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">xorg</merge>
 
      <!-- If we're using Linux, we use evdev by default (falling back to
           keyboard otherwise). -->
      <merge key="input.xkb.model" type="string">thinkpadintl</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>
 
      <merge key="input.xkb.layout" type="string">us</merge>
      <merge key="input.xkb.variant" type="string" />
      <merge key="input.xkb.autoRepeat" type="string">500 30</merge>
      <merge key="input.xkb.options" type="string">ctrl:nocaps,altwin:menu,compose:ralt,eurosign:e</merge>
    </match>
  </device>
</deviceinfo>

The Touchpad configuration was a little more involving, because I added a few options which, before, I didn’t know the thing supported. 99-x11-synaptics.fdi:

<?xml version="1.0" encoding="ISO-8859-1"?>
 
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
 
    <merge key="input.x11_driver" type="string">synaptics</merge>
    <!-- Arbitrary options can be passed to the driver using
         the input.x11_options property since xorg-server-1.5. -->
 
    <!-- Switch on shared memory, enables the driver to be configured at runtime -->
    <!-- This allows configuration of the touchpad using qsynaptics, synclient, or what have you -->
    <merge key="input.x11_options.SHMConfig" type="string">on</merge>
 
    <!-- Enable vertical scrolling by dragging your finger along the right edge -->
    <merge key="input.x11_options.VertEdgeScroll" type="string">1</merge>
 
    <!-- Enable horizontal scrolling by dragging your finger along the left edge -->
    <merge key="input.x11_options.HorizEdgeScroll" type="string">1</merge>
 
    <!-- This is a little bigger than the default narrowing the scroll region -->
    <merge key="input.x11_options.RightEdge" type="string">5500</merge>
 
    <!-- This is a little bigger than the default narrowing the scroll region -->
    <merge key="input.x11_options.BottomEdge" type="string">4500</merge>
 
    <!-- disable Right Top corner "button" -->
    <merge key="input.x11_options.RTCornerButton" type="string">0</merge>
 
    <!-- disable Right Bottom corner "button" -->
    <merge key="input.x11_options.RBCornerButton" type="string">0</merge>
 
    <!-- Enable vertical scrolling when dragging with two fingers anywhere on the touchpad -->
    <merge key="input.x11_options.VertTwoFingerScroll" type="string">1</merge>
 
    <!-- Enable horizontal scrolling when dragging with two fingers anywhere on the touchpad -->
    <merge key="input.x11_options.HorizTwoFingerScroll" type="string">1</merge>
 
    <!-- Enable tapping to emulate mouse buttons -->
    <merge key="input.x11_options.TapButton1" type="string">1</merge>
    <merge key="input.x11_options.TapButton2" type="string">2</merge>
    <merge key="input.x11_options.TapButton3" type="string">3</merge>
 
    <!-- Maximum movement of the finger for detecting a tap -->
    <merge key="input.x11_options.MaxTapMove" type="string">221</merge>
 
    <!-- For other possible options, check CONFIGURATION DETAILS in synaptics man page -->
</match>
</device>
</deviceinfo>

I’m still not completely satisfied with the Touchpad configuration (actually less so than before I started messing with HAL), so I wrote a little tool to be able to mess around with my configuration a little bit easier.

Introducing synclient-sync

With SHMConfig on, you can use the synclient program to make changes to the touchpad configuration without having to restart X. I decided that it would be handy if I could utilize this to test out changes I made to the HAL config file without having to reload it, so I wrote a little script which detects the differences between the current (live) configuration and the configuration in the HAL .fdi file. The running configuration is then updated to reflect the changes in this file. (Newer versions of the script can be found on GitHub)

#!/bin/bash
 
HAL_FILE=/etc/hal/fdi/policy/99-x11-synaptics.fdi
 
VERBOSITY_LEVEL=2
 
usage()
{
    cat <<EOF
Usage: $0 options
 
OPTIONS:
--verbosity [level] Control the level of output processed by the script.
Level 0: No output at all
Level 1: Only output changed options
Level 2: Only output options set in the configuration file
Level 3: Output all options
--verbose Shortcut for verbosity level 3
--help Show this help
EOF
 
    exit 1
}
 
options_from_hal_file()
{
    HAL_SED_FILTER='s%^\s*<merge\s*key="input\.x11_options\.\(.*\?\)"\s*type="string">\(.*\)</merge>%\1=\2%'
    cat $HAL_FILE \
        | grep '<merge key="input.x11_options.' \
        | grep -v 'SHMConfig' \
        | sed -e $HAL_SED_FILTER
}
 
from()
{
     synclient -l \
        | grep '=' \
        | sed -e 's/\s//g' \
        | while read option; do
key=`echo $option|cut -f 1 -d '='`
            old_val=`echo $option|cut -f 2 -d '='`
            new_val=`options_from_hal_file|grep $key|cut -f 2 -d '='`
 
            if [ -z $new_val ]; then
                [ $VERBOSITY_LEVEL == 3 ] && echo -e "\e[1;30m$key = $old_val\e[0m"
            elif [ $old_val != $new_val ]; then
                [ $VERBOSITY_LEVEL -ge 1 ] && echo -e "\e[1m$key = \e[1;31m$old_val \e[1;4;32m$new_val\e[0m"
                synclient "$key=$new_val"
            else # The HAL file and the life configuration are in sync
                [ $VERBOSITY_LEVEL -ge 2 ] && echo -e "\e[1m$key = \e[4m$new_val\e[0m"
            fi
done
}
 
do_from=0
while [ $# -gt 0 ]; do
case "$1" in
        --from-hal)
            do_from=1
            ;;
        --verbose)
            VERBOSITY_LEVEL=3
            ;;
        --verbosity)
            VERBOSITY_LEVEL=$2
            shift
            ;;
        --help)
            usage
            ;;
    esac
shift
done
 
if [ $do_from == 1 ]; then
from
else
usage
fi
 
# vim: set shiftwidth=4 tabstop=4 expandtab: 

References

• en.gentoo-wiki.com/wiki/Synaptics_Touchpad/Xorg_7.3

I want to write down what I had to do to be able to execute Windows executables as if they are Linux native. This can be done thanks to Linux’ support for misc. binaries.

First, you have to enable CONFIG_BINFMT_MISC in your kernel configuration. If it was configured as a module, run /sbin/modprobe binfmt_misc.

Then you have to register the appropriate binary formats:

echo ':windows:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register

That’s it. Of course, the .exe files need to have their executable bit set:

chmod u+x program.exe

Done.

The thing is, some time ago, collision protection was disabled by default, which I thought made sense because when I tried enabling it, I’d get errors like these all the time. I disabled it for now (by putting “-collision-protect -protect-owned” in the FEATURES variable in make.conf), to be able to install Qt, but because it is enabled by default, I’d rather not keep it disabled.

(Text was copied from the post I made on the Gentoo forum about it.)

I noticed this because recently, portage started saying this:

!!! Directory does not exist: '/usr/lib/ccache/bin'
!!! Disabled FEATURES='ccache'

Trying to update the world profile causes a few too many problems, so I start with updating everything in the system profile:

# emerge --update --deep --newuse system

sys-apps/man-pages

The first blockage of the day is “sys-apps/man-pages-3” that is blocking “sys-apps/man-pages-posix-2003a“. The latter is pulled in by “sys-apps/man-pages-posix“, which in turn is required by “sys-apps/man-pages-3.20“.

Somehow, unmerging “sys-apps/man-pages” resolved this blockage:

# emerge --unmerge sys-apps/man-pages

I just had to ignore a few warnings about the package being part of my system profile and I could reissue the system update command. The unmerged package is neatly remerged.

# emerge --update --deep --newuse system

This command started merging 99 packages. The only interruption left in this process was caused by the savedconfig use flag which made the busybox ebuild fail.

Until a few moments ago, I actually thought I made a bit of a fuck-up. I was meaning to make regular snapshots of /etc/portage files for a while now, because I was always just an echo something >> /etc/portage/package.keywords with one >-symbol too few away from destroying my configuration. Despite this fear, I thought I had already started deleting entries from /etc/portage/package.keywords and /etc/portage/package.unmask without backing up first.

Luckily, it turns out that I did make a dated copy of /etc/portage/package.keywords before starting on my modifications. I didn’t do so for /etc/portage/package.unmask, but I recovered a recent enough version from a recent full system rsync backup. So, everything is good. Still, I’m glad that I now use Git to track all changes in /etc/. All this goes to show that my methods are sometimes a bit more organized than my mind, which, I suppose, is a good thing.

The point of this post—yes, there is a point—the point is that once you start mixing stable and unstable stuff, your system becomes, ehm, unstable. I have this huge amount of crap already in /etc/portage to cater to my wish to run stuff that I know to be quite stable but that isn’t yet marked as such in the Gentoo porttree. Now, after many months, I want to remove everything from package.keywords and package.unmask that is no longer necessary.

I was going to write about all the complicated upgrades, downgrades and conflicts suggested by Portage (mostly related to me removing KDE 4 stuff from package.keywords and package.unmask), because I was confused about what changes I had made. With the relevant backups readily available for comparison, I am no longer in a hurry to untangle my thoughts and I’ve moved the preliminary notes to a new draft for when I’ll actually update KDE 4.

Actual justification for this post

I’m trying to get into a blogging style were I post a lot more rubbish like this that can’t possibly be of any use to anybody except myself. I have plenty of reasons/excuses for this (about which I’ll likely post in the future), but I shouldn’t actually need any. That Ryan wanker who thinks I publish this blog for him should really shut the fuck up. Sure enough, he isn’t talking about this blog but I still think he’s a big-time asshole. Fuck you, Ryan!

I found a blog post of a chap who has done the same. It includes a few notes I might not have thought about on my own and also a few very cool Debian tricks.

One of the steps that I might have overlooked myself is that it’s essential to make the .git directory group/world inaccessible with chmod go-rwx. If I would have forgotten this, a smart attacker might use my Git repo to access forbidden file contents.

The author also describes a cool Post-Invoke for Debian’s dpkg that will automatically stage and commit configuration changes made by apt/dpkg (although, later, he mentions that Debian has gotten a package could etckeeper that does this automatically.

Now I would like to learn how I can let Gentoo’s etc-update do as much. In its /etc/dispatch-conf.conf I can only find the option to use (of all things) RCS to track replaced configuration files in a special directory (/etc/config-archive/ by default). Hopefully, there is some drop-in replacement for etc-update which does this and which can rid me of etc-update’s awkward interface at once.