Because of some modifications at my Real Life Orkplace, I decided to reduce other duties to get a better chance to deal with my new duties. So i requested help for my four packages in the Distribution

RFH: jove

My first package. A small, but powerful Emacs-relative, with all those uneeded things stripped which makes emacs fat. Maybe these days especially useful for small memory devices, as it gives you emacs-likeness for the price of nvi or ae. I have no idea how well it works in a real utf-8-environment.

RFH: milter-greylist

A greylist-milter which makes running a mailserver somehow possible for me. it keeps away about 2/3 of spam, which leaves me with only 400spams/day. I already have two contacts who want to help with that.

RFH: nn

No news is good news, but nn is better. This is a USENET reader, for those people who grow up with Webforums and Blogs: This could be still the most effective way to celebrate flamefests, gather information or communicate with people sharing same interests. And nn has in my opinion the best UI for it, and makes it easy and fast to find interesting articles and skip others. Well, Upstream Development has ceased to exist around 1994. I think if no one takes over, this package will become finally useless when IPv6 gets widely used (right after the release of 'Duke Nukem Forever') and it also doesn't deal well with non iso-8859-1-charsets. So best for this package would be to rewrite it from scratch (my dream: message/mime-handling/threading from mutt, scoring from slrn, and UI from nn) because the User Interface is much better than those of all still alive Newsreaders i tried.

RFA: synergy

This is my most popular package, which makes it possible to share one mouse and keyboard over many computers and displays. (It is available for UNIX/Linux, Windows and MacOS) This is a very very useful software, and i use it permanently. Sadly the Upstream Development mostly ceased to exist, and so i put this to RFA (instead of RFH) because many Debian-Users use it according to popcon. This software should be taken over by someone who is able to help Upstream. There is a RC-Bug, which caused the package be pulled from testing.

Interesting is that while filing those RFH/RFA all the same day, i only got responses for the packages which scores lowest in popcon, (24 for milter-greylist, 1196 for synergy).

I spent part of my Sunday on samba yesterday. After all, that ankle tendinite I have for nearly two weeks now has some benefits for Debian: I don't waste hours running on week-ends. Samba 3.0.28a was announced by upstream and I worked to package it. Not really difficult and the package is already ready. It again minimizes the numer of Debian patches: we're slowly converge back towards upstream. Meanwhile, Steve uploaded a new release of 3.0.28, introducing the use of ucf to manage smb.conf changes. He slightly messed up in the update and, therefore got 3 RC bugs in a row for the same problem (#470138, #470139, #470140...and even #470142 to complete the picture). Good score, Steve. One beer for me next Debconf...:-)...The breakage was fixed a few hours later. So, conclusion: we apparently have active users who are committed to reports errors. Good...:-) As soon as 3.0.28-4 makes its way to unstable *and* the automated Ubuntu merge-o-matic, I'll probably upload 3.0.28a, not really waiting for 3.0.28-4 to enter testing (we already have 3.0.28 in testing). Another work in the pipe is the preparation of samba 3.2.0. Upstream released RC2 last week and I did early work to package it (for experimental as of now). However, that release incorporates most parts of our "FHS" patch, for better compliance to the FHS, as well as several other patches we pushed to them. And, as these weren't applied as is, some checks have to be done. Moreover, some other changes seem to be needed to get the package to compile. And, finally, we need to merge back recent changes from the trunk branch (such as the ucf support). All this is a way too high barrier for me and I'll need Steve to take that load, which he promised to do (and so *will* do, I know him enough....). When all this will be settled down, it will be time to jump in the BTS and fight with some old bugs of the package.

I have been maintaining several minor sites hosted at Dreamhost for about a year. And since over one month ago, my personal website is with them as well. And I must say, I am very pleased with them. No, not (well, not only) because they run Debian on their servers, nor because they are probably the cheapest game in town (I paid something like US$200 for a basically unlimited package , for three years), but because of their degree of responsability and personal service.
Responsability? Aren't they well-known for their network outages? Why, yes, of course - Today's example is paramount: Somebody edited the wrong firewall entry, and all of Dreamhost became unavailable. In general terms, Dreamhost has a great blog-like structured page where they inform customers of every network or server problem they have - No, you don't have to dig in to understand why your site is down: They bring it up to you. Upfront. And in a familiar, very non-formal style.
Whenever I have submitted an issue to their request tracker, I get prompt reply. Does it always solve the situation? no, by far. I'm often told to, basically, go screw myself if I really need such feature... But they are straightforward with that, they are good, nice BOFHs (if such thing ever existed), and they don't present you with corporate-minded studies backing up their solution. Yes, I know that in their servers, it's plainly their way or the highway. But hey, that's what I paid for, right?
That is what wins my heart. Yes, Dreamhost is no good for many, many tasks - including, for example, anything that requires a real RDBMS (forgodssake, they offer MySQL but not PostgreSQL, damnit! WTF!?), nor any legendary five-nines reliability. But they are great for the vast majority of the Internet sites' needs. They even exceed what a simple person like me would ever dream of.
So, my hat off to you guys. Again.
(No, and I'm not getting paid or discounted on services because of this blog post. Although maybe I should! ;-) )

For people who have interest in the development of gender equity in FLOSS development, here's a short news item. Yesterday, the Samba Team announced the "pre2" version of samba 3.2.0, scheduled to be released during the SambaXP conference next month in G ttingen (to German friends around: of course, I'll be there: Apr 14-18). That release was announced by Karolin Seeger, whoc is now replacing Jerry Carter as Samba's release manager. As far as I know, Karolin is indeed the first female memer of the Samba Team (which includes about 20-30 people). Guess what: that release seems to be a pretty good one. I'm already working on the Debian package. The release is indeed the first one to include many patches we bringed from Debian, for instance those aimed at following the FHS. Steve Langasek is the one to be rewarded for this as he bringed very valuable input in the discussion I had with Jerry Carter to convince him to include these patches..:-)

• I'm now a Debian Maintainer. Yay :)


• New releases of libgda3 and libgnomedb3 were uploaded. On both of them, I've added the Dm-Upload-Allowed, VCS-* and Homepage fields, updated the standards version and fixed FTBFSes on BDFH's dirty chroot, along with some other minor bugfixes.

Angie, Leif and I met with one the two surgeons who will be doing the work. I s'pose it's good and bad that the co-director of the UCSF Spine Centre, Dr. Mummaneni is personally taking on the case. Good that I'll have the best possible care; Bad that I'm apparently interesting enough to warrant it.

Meeting with him was matter of fact. He talked about how he'll approach the surgery (from the back, since the placement of my aortic arch and innominant vein would make coming through the front problematic). It looks like I'll have rods and screws from T1-T6, with a cage replacing the vertebra at least at T3 and possibly at T4. People don't usually do that much movement in their thoracic back so, ongoing, his opinion was that I largely won't notice it.

In hospital-time will depend on whether or not the surgery can be done in one shot. Because of the trickiness of the area, it may not be possible to get it entirely from the back, and he'll do two surgeries rather than one if that can avoid me winding up in a wheelchair. Ideally, there's one surgery, and a week later I'm home and able to take care of myself. The way they take the tumor out in a couple pieces is known as "en bloc spondylectomy", but may not be possible with the way the spinal nerve is being pinched. He described the surgery itself, and the simple version is "remove one or two vertebra, replace them with cages, stabilize the surrounding area". Yay to the Black and Decker surgical division.

He'll be assisted by Dr. Chau for spinal cord monitoring and the rest of the surgery.

The last thing they did as I left the hospital last Saturday was a full body CT scan with contrast, and the radiologists have declared that that they see no additional tumors in the body. I'll visit with an oncologist to do some final tests, but consistently the answer is coming back that this isn't cancer, it's more likely an isolated mutation. Dr. Mummaneni doesn't feel that this is a side effect of sitting at a computer since I was 3 years old, any of the car accidents, or being hit across the back with a flute case in grade 9.

I did ask if I'll set off metal detectors at airports after this, and apparently the titanium used doesn't do that.

So, erm. What are the risks? Honestly, pretty consistently less than doing nothing. Having this thing would eventually result in paralysis anyway, and aside from the usually OMG-they're-cutting-me-open-anything-could-happen type of things that don't keep me from biking to work on a regular basis, all the other options are "And life improves from here". Informed consent means that I have statistics in my head that I'd rather not dwell on and a laundry list of things to panic about when I wake up in the middle of the night but those really are just nerves acting up and stress wanting to come out. Nothing wrong with any of that.

Surgery is booked for March 3rd. We'd hoped to go to Vancouver for Leif's birthday around then, but I've been asked not to fly. Rapid pressure changes apparently will aggravate what's there now.

I feel good about this. I'm back to pretty much 100% after the hospital time last week, and noticed that after the embolism that I'm moving a bit freer than I was before. That's enough to start the optimism going already. We've also twiddled my medicine for every 8 hours rather than 6, which will help me sleep better, and reduced it, which will help me feel better.

Having time-frames and knowing that I'm in good hands is a lovely place to be after all that.

I'm trying to work out how to monitor a remote script - in this case a mass build script. The script itself is trivial - a simple for loop in perl. It calls a script from emdebian-tools that calls a variety of other scripts and programs.
What's the best way for me to monitor that script from another machine on the network?
Yes, 'ps wax' is usable but not particularly friendly - the script has to work its way through a list of packages that need building. I want to know which package is being built at the time and the 'ps' output does show this information but only if you recognise parts of the build process for particular packages.
I thought about getting the script to output the current package name to some file in /var/ but that seems a bit of a hack (it's a userspace command and should not need to use sudo or require particular permission setups). Sending email is overkill. A file in /tmp/ is possible, true, but that means adapting the script itself. I'd like a solution that could work with (almost) any package, including binaries, without altering the source code. I've also thought of running the script within screen but then when the machine is in the middle of a compilation, it isn't easy to work out which package is actually being built just from the gcc output, plus there is the continual problem that screen doesn't support scrollback.
I have a feeling this is a potential reinventing the wheel problem so I'm looking for ideas.

Update:
The closest process output I can use is ps wfh which at least collates all the processes started by the top level script into one tree. I've worked out why the info I wanted was not being shown - the call from perl was exec() not system(). Doh! Ne'er mind. ps wfh will be enough for what I need - but I will need to adapt the wrapper after all. Thanks to all those who posted comments.

I wrote a quick and dirty workaround for the recent CVE-2008-0009 and CVE-2008-0010 local privilege escalation kernel vulnerabilities. Loading this kernel module will disable the vmsplice(2) and vm86old(2) system calls, which are used by the published exploits but by very few regular programs. The code is ugly and does not support amd64 bit systems, any help is welcome.

I've changed the domain name of my blog, etc. from scealnetworks.com to sceal.ie for various reasons: its shorter, I'm doing almost no networking work these days, and I've (personally) no intention of becoming an multi-national corporation in the near future. Still got the old domain, though, and heres the question: does anyone know if its possbile to redirect Jabber XMPP IM from one domain to another (e.g. in a 301-style redirect?) And also, here's a new Technorati Profile. Tags blogging, xmpp, redirect

I am currently working on implementing a cryptographic file system using FUSE. It is different from EncFS and similar in that it just mirrors a normal directory tree, but encrypts the contents of the files as they are read or decrypted as they are written. My use case is backups. I have some machines where I and only I have access, machines which may contain proprietary information, personal emails and so on. Of course, I want backups of those, so when the hard drives stop working, I don't lose any data. The machine(s) I am backing up to, however are not always machines where I trust all the people with physical access to not make a copy of my data. In addition, I don't want broken hard drives returned under warranty to contain unencrypted data. This use case is the reason for why I'm encrypting on read rather than on write. I have chosen to use CTR (counter) mode together with AES which should give acceptable security. One of the requirements CTR needs to work well is a nonce, typically 64 bits (for 128 bit AES) which must not ever be used twice. If you use it twice, you leak information about your plaintext, which is, for obvious reasons, bad. My current design headache is how to choose a good nonce. Ideally, I believe it should be persistent for each version of the file and unique per file. Using the inode number takes up 64 bits (on AMD64 at any take, or when using -D_FILE_OFFSET_BITS=64 on 32 bit platforms). So while this gives me the latter, it doesn't give me the former at all. I am wondering if I should use the inode number modulo 2^32 (effectively choosing the lower 32 bits of the inode number) and then something which is fairly sure to never be the same, such as mtime (or at least the lower 32 bits of it, when time_t becomes 64 bit). The reason for not just choosing a completely random value is I don't want a command like diff file1 file1 to claim there are differences in the file. My hope was I'd get a great idea on how to solve the problem as part of writing it down. Alas, that hasn't happened, so if you happen to come across a great solution (or a reason to avoid a particular choice), feel free to email me

I went to Hatsu-moude. Hatsu-moude means New Year's visit to a shrine. I went to a shrine nearby my home. Pretty much crowded. This was (and still is) basically a Shinto ritual, but most people don't care and simply want some fun. I'm not really a Shintoist too, but I love that festive atmosphere.

Tag this post with del.icio.us!

Late last week, I visited fellow DD Tim Cutts at the Sanger Institute just south of Cambridge. I dropped off a couple more machines that the BOFHs there have kindly offered to host for Debian, and Tim offered me a quick look around their facility. Sanger plays host to a massive set of computers used for genetic sequencing and related tasks. They have a very impressive setup with thousands of machines in multiple machine rooms, connected via huge amounts of (very neatly laid!) power and networking. Oh, and multiple petabytes of disk storage, with terabytes more data generated every day. The coolest thing? Tim told me that the majority of their machines are running Debian, mostly stock installations with no special tweaks needed. Yay!

The Samba Team is about to release version 3.2.0 of samba. To prepare this, we built a 3.2.0~pre1-1 package which I just uploaded to experimental. As usual with Samba, users should read the WHATSNEW.txt file to check what changet in samba. One of the major changes is samba being now licensed under GLPv3. In parallel to this, we are now in the process of trying to get the main Debian patches adopted by upstream, which would reduce the size of the diff.gz file as well as save us a lot of work when upstream releases new versions. The main work happens with the "fhs.patch" patch which is aimed at a better respect of the FHS. We began discussions with upstream in a cooperative way and, even if Jerry Carter seems reluctant for some parts, I believe we can have them adopt some of our proposals (Steve Langasek helps a lot in such arguments: having him in a package maintenance team is a blessing....).

I request assistance with maintaining the dctrl-tools package. There are several tasks that could use more manpower (in no particular order):

• Writing test cases
  One could mine the BTS for past bug reports and create regression tests for them.
  One could use standard black-box and white-box testing techniques to generate general tests.
• Writing documentation
  The whole suite of tools could use a unified tutorial manual on how to best use it. The current documentation is reference material in the man pages.
• Internationalise the man pages
  Use po4a?
• Swatting the BTS wishlist entries
  I’ve kept the BTS clean of actual bugs pretty well, but there are a number of wishlist reports still outstanding.
• Take over maintaining the debian/ directory
  If you commit to maintaining it (and I trust your judgment), you’ll get last say in that part of the package (including deciding what helper to use).
• Whatever you wish
  Discuss on the dctrl-tools-devel mailing list first though.

Eventually I’d like to pass the package on to competent successors, but I have too much emotional attachment to the package to do that without a transitional period where I still retain a veto on what goes in the package. I also have some ideas for future tools that I’d like to be
able to concentrate on, and having co-maintainers might allow that. The package is now under Git in collab-maint. See the new README.Debian for information and a push-access code of conduct.

The Samba Team is about to release version 3.2.0 of samba. To prepare this, we built a 3.2.0~pre1-1 package which I just uploaded to experimental. As usual with Samba, users should read the WHATSNEW.txt file to check what changet in samba. One of the major changes is samba being now licensed under GLPv3. In parallel to this, we are now in the process of trying to get the main Debian patches adopted by upstream, which would reduce the size of the diff.gz file as well as save us a lot of work when upstream releases new versions. The main work happens with the "fhs.patch" patch which is aimed at a better respect of the FHS. We began discussions with upstream in a cooperative way and, even if Jerry Carter seems reluctant for some parts, I believe we can have them adopt some of our proposals (Steve Langasek helps a lot in such arguments: having him in a package maintenance team is a blessing....).

One of the common criticisms of the war in Iraq is that it was just an excuse to plunder that nations' oil. Of course that wasn't the reason however on Blog Action Day I urge environmentalists to think about why that might have actually been a better reason than the ones the politicians gave. The world supply of oil will probably run out in my lifetime. While alternative sources of energy are being researched, they have yet to be viable on a large enough scale to keep the world economy running at its present rate of progress. For the time being we must depend on oil and it is of vital importance that this precious resource is managed carefully. The problem is that it is not. Whereas civilized countries use energy for good purposes most of the oil is produced in countries which can only be described as evil. Take Saddams Iraq for instance; apologists claim it was one of the most advanced Arab nations, but that isn't setting a very high bar is it? Oil wealth was not used to better the lives of citizens but to prop up a savage and despotic regime. It is the poor and desperate deprived of the ability to take part in free markets who despoil the environment in a struggle to survive. Look at the other major oil producers and there too you will see a veritable rogues gallery. Some of these villains may be motivated by fundamentalism, some by socialism but the effect is the same. The common man in their countries does not get to enjoy the fruits of progress They are forced to muddle along with old, energy-inefficient, pollution-causing tech and their large numbers and vast geographical range undermine any modest environmental gains made by a few middle-class Westerners. How could anyone who cares about the fate of our mother Earth stand by and watch her bounty being squandered by dictators? See rapidly dwindling resources wasted on jihad and revolution? The next time there is talk of war, be environmentally responsible and ask your representatives to make securing oil and spreading capitalism priorities. You owe it to your planet.

I recently discovered some perl behaviour that I cannot explain. My goal in this code was to get the matched string in $1. I see how only having a scalar for multiple possible matches (the result of g) could be a problem, but I expected to alyway get something. The effect instead is that $1 may or may not be defined, depending on apparently unrelated changes like setting the i option or changing the regexp in a way which does not alter the matched text. My test case follows.

#!/usr/bin/perl
use warnings;
use strict;
#use re 'debugcolor';
my $text = <<END;
XXWY
XXWZ
END
# $1 is defined only if I remove either of ?, g or i
my $count = $text =~ s#(XXW?Y)##gi;
print "REMOVED: <<$1>>\nCOUNT: $count\n";

Although slow, development on svn-buildpackage still continues. Sorry for the delays, but both myself and Eduard Bloch have been unable to assign more time to svn-buildpackage development in the last few months.

From the changelog of the trunk package (unreleased 0.6.22):

  [ Eddy Petri or ]
* IMPORTANT: changed default behaviour of saving the configuration in
.svn/deb-layout by default to avoid stale data to override the
configuration options that were updated in the repository.
(Closes: #414581)
As a consequence, a new option --svn-savecfg was added to allow a
mechanism for easily overriding options locally

BTW, did you know that svn-buildpackage is maintained in collab-maint and welcomes contributions and committers/reviewers (especially those)?

In case you want to help, this is the place to start from:

svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

or

svn co svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/trunk

If you don't have commit access to collab-maint yet (just make a request on the alioth tracker and that will be fixed ;-) ).

When packaging games, one of the operations I often have to do to the source code is modifying it so that it uses absolute file and directory names instead of relative ones. When coders develop for Windows, or when they develop their games to be able to play them from their home directory, they just would go that way and won’t care about it, but when the idea is installing the files in the system, the Filesystem Hierarchy Standard (FHS) must be respected, and thus things will need to be place in their proper directories. For read-only files, this is not a big deal, all that has to be done is replacing the relative file name in the file opening commands with the absolute one, doing fopen(”/usr/share/games/package/dir/file”) instead of fopen(”dir/file”). I usually prefer to do it like fopen(DATADIR “/dir/file”) and set DATADIR from the Makefile, with a -DDATADIR=\”/usr/share/games/package\” switch added to the CFLAGS, and maybe also setting it inside the code if it’s not previously defined (#ifndef and so). There are some files and directories in which doing this is not possible, because they want read-write permissions. This files include saving the configuration, hiscores, new levels created with the game editor, game saves and so. They might be moved to some directory under “/var/lib/”, and create a new group en the system so that it’s writable, and so on. I don’t like that approach a single bit. I prefer to move all tthat data to the user’s directory. This is not as straightforward as it was for read-only data, but it’s not really that difficult anyway. It would be more or less like:

#ifndef _WIN32
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <limits.h>
#include <pwd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>
#endif
#ifndef _WIN32
char file[PATH_MAX];
char *home;
struct passwd *passwd;
if (!getuid()   !(home = getenv("HOME"))) 
passwd = getpwuid (getuid());
home=passwd->pw_dir;
if (!home) 
fprintf(stderr, "$HOME is not defined.n");
exit(-1)
 
 
if (strlen(home) > PATH_MAX - sizeof("/.package/settings.ini")) 
fprintf(stderr, "$HOME is excessively long.n");
exit(-1)
 
snprintf(file, sizeof(file), "%s/.package", home);
mkdir(file, S_IRWXU   S_IRWXG   S_IROTH   S_IXOTH) == 0;
strncat(file, "/settings.ini", sizeof(file)-1);
#else
char file[21];
snprintf(file, sizeof(file), "./Data/settings.ini");
#endif
FILE *f = fopen(file, "w");

Sometimes you also need that the files are already created, you can check if they already exist with stat(), and then acting accordingly, either creating them from your C code, or maybe triggering a system() shell call whith whatever is needed.

struct stat stat_buf;
stat(file, &stat_buf);
if (stat(file, &stat_buf) == -1) 
int settings_fd = creat(file, O_WRONLY);
close(settings_fd);
 

NOTE: I’ve updated the code to add some suggestions. Thanks to Gon ri Le Bouder and Nico Golde.

Watching the popular Inbox Zero video would probally improve my email handling skills better. But this took less time and I wanted to play around with Net::XMPP;

#!/usr/bin/perl -l
use warnings;
use strict;
use Config::Simple;
use Linux::Inotify2;
use Email::Abstract;
use Net::XMPP; # aka Jabber and Gtalk
use POSIX;
my $DEBUG = 0;
our %config;
Config::Simple->import_from("$ENV HOME /.mailnotifyrc", %config);
deamonize() unless $DEBUG;
my $inotify = new Linux::Inotify2
     or die "Unable to create new inotify object: $!";
# Different Maildir implementations triggers different events"
#   IN_MOVED_TO: rename("tmp/file","new/file")
#   IN_CREATE:   link("tmp/file", "new/file") && unlink("tmp/file")
#
# At this point the file should be written and closed.
$inotify->watch("$config Maildir /new", IN_MOVED_TO IN_CREATE, sub  
        my $e = shift;
        my ($fh, $xmpp, $email, $message);
        debug('Got event for ' . $e->fullname);
        open $fh, "<", $e->fullname;
        $email = new Email::Abstract join("", <$fh>);
        close $fh;
        $message = 'Mail from ' . $email->get_header('From') .
                   ' concerning "' . $email->get_header('Subject') .'"';
        debug("Getting ready to send [$message]");
        my $sender   = new Net::XMPP::JID ($config Sender );
        my $receiver = new Net::XMPP::JID ($config Receiver );
        $xmpp = new Net::XMPP::Client();
        $xmpp->Connect( hostname => $sender->GetServer,
                        port     => $config port    5222,
                        tls      => $config usetls    0,
                      );
        $xmpp->AuthSend( username => $sender->GetUserID,
                         password => $config password ,
                         resource => $sender->GetResource   'mailnotify',
                       );
        $xmpp->MessageSend( to   => $receiver,
                            type => $config MessageType    'chat',
                            body => $message,
                          );
        $xmpp->Process(1);
        $xmpp->Disconnect;
        debug("Event done");
 );
1 while $inotify->poll;
sub deamonize  
        my $pid = fork();
        if ($pid)  
                exit 0;
         
        ### close all input/output and separate
        ### from the parent process group
        open STDIN,  '</dev/null' or die "Can't open STDIN from /dev/null: [$!]n";
        open STDOUT, '>/dev/null' or die "Can't open STDOUT to /dev/null: [$!]n";
        open STDERR, '>&STDOUT'   or die "Can't open STDERR to STDOUT: [$!]n";
        ### Change to root dir to avoid locking a mounted file system
        ### does this mean to be chroot ?
        chdir '/'                 or die "Can't chdir to \"/\": [$!]";
        ### Turn process into session leader, and ensure no controlling terminal
        POSIX::setsid();
 
sub debug   return unless $DEBUG; print STDERR for @_;  
__END__