Mucking around with D-Bus and XChat

XChat 2.6.0 adds a D-Bus plugin created by Zdra. This D-Bus plugin allows you to control XChat from another script. Not knowing anything about D-Bus I’ve been playing around with it, learning more along the way.

D-Bus supports two buses. One is a systemwide message bus. The other is the per-user-login-session bus. The XChat plugin uses the session bus. When dbus-launch is installed and supported by your distro every program started within an X session will communicate over the same bus. If you would log in again dbus-launch will start another message bus.

Session specific message buses are logical to have; otherwise logging in twice wouldn’t be supported or give strange results. A program could use D-Bus to only have one process per session. Starting the program another time would actually send a message to the existing program to open a new window (Mozilla, Gnome-terminal and Evince are examples of this idea; although none seem to use D-Bus). One drawback of a session bus is connecting to that bus from cron. As crond is not started by your X session, scripts run by cron cannot use D-Bus to connect to XChat. I thought of two possible ways to fix that:

  1. Let the D-Bus plugin use systemwide message bus
    This is the easiest way to fix it. However, it is a big security risk. The D-Bus plugin allows you to send ‘/exec some_command’ to XChat, not something I want other users to do. I could limit the users using D-Bus policies, but I’ll probably accidently wipe the D-Bus configuration once in a while anyway.
  2. Hacking a way to the session bus used by XChat
    A session message bus is determined by two environment variables, DBUS_SESSION_BUS_ADDRESS and DBUS_SESSION_BUS_PID. Letting an cron script use XChats session bus is as easy as setting the correct environment variables.

The environment variables of every process is stored under Linux in /proc/$PID/environ. This file contains the environment variables separated using an ASCII 0. To determine the PID of XChat I use the command: pgrep -u $USER -o xchat. Implemented as a Python script:

#!/usr/bin/python

import sys
import os

DBUS_ENV1 = "DBUS_SESSION_BUS_PID"
DBUS_ENV2 = "DBUS_SESSION_BUS_ADDRESS"

if DBUS_ENV1 not in os.environ or DBUS_ENV2 not in os.environ:
    # Steal required environment variables from XChat process
    import popen2
    p = popen2.Popen4(['pgrep', '-u', os.getlogin(), '-o', 'xchat'])
    if p.wait() != 0:
        print "Could not retrieve DBUS info, exiting"
        sys.exit(1)

    pid = p.fromchild.readline().strip()

    xchatenv = dict([i.split("=", 1) for i in open("/proc/%s/environ" % pid).read().split("00") if "=" in i])
    if DBUS_ENV1 in xchatenv and DBUS_ENV2 in xchatenv:
        os.environ[DBUS_ENV1] = xchatenv[DBUS_ENV1]
        os.environ[DBUS_ENV2] = xchatenv[DBUS_ENV2]


import dbus

bus = dbus.SessionBus()
object = bus.get_object("org.xchat.service", "/org/xchat/RemoteObject")
xchat = dbus.Interface(object, "org.xchat.interface")

version = xchat.GetInfo("version")
print version

The D-Bus plugin is lacking some commands, so above script is not interesting. Eventually I want to check if Mrkbot is still in #bugs (stupid bot is away most of the time). If the script cannot find Mrkbot the script should send an email to restart it. Still not interesting (and it could be made in various other ways), but I have a lot of fun creating it.

Baobab, a great little app

Fortunately the developer of Baobab asked to be on bugzilla.gnome.org. Baobab is a app I always wanted to write/have, but never bothered to actually make. It shows you the used space in each directory. This is like ‘du’, but so much better. Integrates with Nautilus (you can open Baobab for a folder from Nautilus and Nautilus from Baobab).

The screenshot shows my home directory. Apparently I have 529MB of bug-buddy mails, in size that is 19.4% of all my mail. You can probably figure out that my Download folder is located under Desktop ;)

Packages are available for Debian, Ubuntu, Gentoo, Mandriva (Cooker) and of course as a .tar.gz.

New monitor

A while ago my 19″ CRT died. I have been working on my spare 17″ CRT ever since. Until today:

Screenshot of #bzbot

Bugzilla-test in gnome cvs

For Bugzilla we need to update from two different cvs roots. One is upstream Bugzilla, the other cvs.gnome.org. Bugzilla-test wasn’t in gnome cvs because of the need to update from main Bugzilla. Thankfully Elijah created a script which updates from upstream Bugzilla, while still allowing our customizations to be in cvs.gnome.org. I understand it is a bit of a hack, but I am really happy with it. This also means bugzilla-test is now in cvs.

The current bugzilla.gnome.org is in cvs.gnome.org under bugzilla-new. Bugzilla-test can be found under bugzilla-newer. It likely needs some small handholding to setup locally; fixing that isn’t very high on my priority list. What I want to do next is to add back the patch statuses combo boxes in show_bug.cgi. As Bugzilla 2.20 (and even 2.18) has a lot of changes over 2.16, determining the best way to do this requires some thought. My main goal is to keep it useful while limiting the changes to 2.20.

Bugzilla additions

Products added to bugzilla.gnome.org:

  • Serpentine: An application for writing CD-Audio discs. It aims for simplicity, usability and compability
  • OnTV: A GNOME Applet for monitoring current and upcoming
    TV programmes.
  • Tepache: Tepache is a code sketcher for python that uses pygtk and glade.
    It could look like other glade codegens, but it is totally different.
  • Update manager: An application which makes it easy to manage, configure and
    install software updates.

All use Python.

Relieved

My parents and sister where in England for a 2 week holiday. Before traveling back they decided to visit London for a day, that day being today. They are all ok. Public telephones in London have a normal phone number. I really appreciated that as they only had one nearly empty mobile with them.

Watching bugs in 2.20

In standard Bugzilla the bugmail header X-Bugzilla-Reason: CC could mean that you are on the C list or you are watching someone on the CC list. Bugmails from bugzilla.gnome.org have a patch to differentiate between those. X-Bugzilla-Reason: WatchCC is used when watching someone on the CC list and X-B-R: CC is only used when you are on the CC list.

In 2.20 the email code has been changed drastically. Fortunately above could be reimplemented. A new feature is the X-Bugzilla-Watching header. It is a comma separated list of email addresses you are watching for this bugreport.

It doesn’t work entirely like I’d want to. It can lists email addresses that have not caused the email to be sent. E.g. you are watching some person who has voted for a bug. In your email preferences you’ve disabled receiving bugmails when voting. Although the X-Bugzilla-Reason wouldn’t specify WatchVoter, the X-Bugzilla-Watching will specify the voter. This only happens when you receive the mail due to some other reason (example: you are the assignee). I’m not planning to fix this.

Everyone must deal with my spam problem

There are various ways to handle your spam problem. There are various spam detection problems, DNS blackhole lists, etc.

The worst way I can think of is letting others deal with your spam problem. When you send these persons an email, automatically a confirmation email comes back. That email explains you need to reply before they will see the message.

The thought behind these systems is that every reply will be read by a human being. A human being that cares enough to reply.

My main problem is that they make the spam problem worse. As they reply to every message, their ‘solution’ also replies to every spam message with a forged From address. I don’t believe I ever saw a spam message with the spammers email address in the From. When a spammer forges your From address, not only do you have to deal with the bounces, but also the mail bombs from the automated systems (such as these) responding to the spam. Some systems (majordomo) I can understand, but these confirmation systems are just stupid.

Automatically replying is bad, what makes it worse is that these systems do not even solve their problems for them. Perhaps they never want to receive their Bugzilla password. Bugmail mustn’t be important as well. I know some of these systems solve this by having a ‘pending’ folder. This allows the person to see the valid email between all the spam. Making the entire purpose of the confirmation system worthless.

For bugmail the bugmaster mailing list actually receives these confirmation messages. To the senders: go look in your pending folder.

Started working on Bugzilla upgrade

Bugzilla.gnome.org currently runs a modified 2.16. It mostly does what we want, except for some of the niceties a newer Bugzilla will provide (search as RSS, better written code, …). The test version of the new Bugzilla can be seen at http://bugzilla-test.gnome.org/. Upcoming changes can be seen at http://live.gnome.org/BugzillaUpgrade, new suggestions are welcome. Current status of the upgrade will be tracked via http://live.gnome.org/BugzillaUpgrade/UpgradeStatus.