This feed contains the 10 most recent pages in the "hacking" category.

Today, I've finally decided to drop this project. I really should have done it years ago, but there you go, these decisions take a while with me.

I've been thinking about it over the summer, and I came to realise that my motivation to keep on going with it is virtually none.

This is what I wrote on the mailing list:

Hi all,

Actually, the subject line doesn't say it all, it's really been time for quite a while.

Things are changing, life is going on, and I've been quite aware for a while that I haven't lifted a finger on this project for a long while. I've done some thinking on this and other stuff during the summer, to see where I feel motivated... and I came to the conclusion that my motivation to keep working on ctwm has been close to none for that long while, and that I really need to let go, let someone else take over.

Any takers? I've noticed some activity just recently, so I imagine there should be some interest. As a side note, there's a clone/fork on github, https://github.com/sroracle/ctwm . I believe this was mentioned on this list some time ago. I have no idea if it's of interest.

From a practical point of view, I can keep the web site, monotone database, mail and all that running on my server, but in the long run, it might be a good idea to move it wherever the one taking over wishes. Just tell me what you need and I'll help as much as I can.

Cheers, Richard

P.S. If there are no takers, I will have to consider simply dropping the project. Nothing I particularly enjoy, but...

Among the things I've thought about but never got to actually doing is to add full support for Inter-Client Communication Conventions Manual. I hope whoever takes over gets that going, it would be a nice addition.

Posted Sep 11, 2013, 2:06:04 PM +0200 | Tags: hacking

The news today, provided by The Register, is that HP has decided to put an end to VMS.

Somehow, the only thing happening in me is a sigh and a silent final goodbye. I think I've seen this coming for years, even though not very consciously... it's been ages since I wrote a single line of DCL, it's a couple of years since I last logged in on a VMS machine... I think I personally let VMS die a long time ago, a slow death.

VMS is worth remembering, though. In many ways, it's a fantastic operating system. Not for the command line, but for the internal functionality. In my mind, nothing beats the system services provided, nothing beats the $QIO and events functionality, it was possible to write a completely event driven program with just a few lines of code.

My life with VMS started 1989/1990, when I landed a part time job as a system manager. Shortly before, I had fallen in love with GNU emacs, and was amazed that there was a pretty damn good port of version 18.55 for VMS. That was a somewhat aged version, though, and I knew that I wanted to be able to use version 18.59 that was the current version at the time. So I started working on porting it and sharing the results, and enhancing things that I wanted to work better than before.
In a few years, I had learned OpenVMS (Digital renamed the operating system to indicate that it got POSIX certified), grew into a good system admin as well as programmer, dived into the free software/opensource community and gained some fame for working on and maintaining the port of emacs for VMS.
A few years later, I started enhancing the port of SSLeay for VMS, later to become the port of OpenSSL. This lead to a job, further enhancements of OpenSSL and a membership in the OpenSSL development team, and somewhere along the way, I became fairly good at writing code that would build and run smootly on multiple operating system families (OpenVMS and Unix, first of all).

In the end, I can't thank VMS enough. It provided me with an entrance to so many things that shaped me for some 20+ years, and has been fun to play with and work with for many of those years.

Today, it's like finally parting from a friend that I've seen slowly fade away over a few years.

Goodbye, friend...

Posted Jun 11, 2013, 10:26:49 AM +0200 | Tags: hacking

xkcd featured a strip that I really like, today. Basically, I'd love it if my programs sometimes told me error -41... or having that book, for that matter ;-)

Posted Mar 2, 2012, 11:42:48 AM +0100 | Tags: hacking

I've long avoided having public comments here, for two reasons. One was that I didn't want to clutter things up to much, and another was that I was lazy about setting it up.

Today, however, I stumbled upon disqus, which does all the nifty things you might want out of a blog commenting system, all you need is to hook things up. And it wasn't even hard, and I've all the controls I might desire and stuff...

I think I'm happy with the result so far... There was some mysteries to resolve, mostly because I had hacked in some css stuff in the wrong spot, but it didn't take too long to do.

Posted Jul 18, 2011, 9:23:51 PM +0200 | Tags: hacking

commit-patch is a cool little tool, if you want to quickly commit a patch even though the affected files are filled with other changes that you don't want to undo or commit at the time.

I recall that some people have asked if there might be some build in support for partial commits in monotone... there isn't. However, a cool little tool like commit-patch fits the job perfectly.

There is just one little problem, it doesn't have monotone support. Yet. I've added a small change that implements this and sent it to the author. If there are no issues with it, I'm guessing we'll soon see a tool that can help with partial commits with monotone.

Posted Apr 19, 2011, 9:55:22 AM +0200 | Tags: hacking

Up until now, branch renaming has been a tricky issue with monotone... and for good reasons. What makes it tricky is that as soon as a branch has left the building (in this case, your own database) out into the world (basically, any other database), you're stuck with what there is unless you track down every damn database where it has ended up and convince every last owner of those databases to do the same change you did. That might be hard work.

So far, it has been recommended to think of what globally unique name you should use for your branch from the start, since you can't undo it later.

My question is, though, is that really true any more? After all, since that time, monotone has evolved further, new features have been added, and they might help us in this case.

Let me introduce you to this little command:

mtn suspend

This little command, which has been around since version 0.41 (September 2008), allows anyone to mark a revision as suspended, discontinued. If all heads of a branch are suspended, that branch will not be displayed any more. It will become invisible.

$ ########################################
$ # Preparations
$ #
$ mtn -d foo.mtn db init
$ mtn -d foo.mtn setup workspace -b foo -k richard@levitte.org
$ cd workspace
$ echo a > a; mtn add a; mtn ci -m "initial commit"
mtn: adding a to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
$ ########################################
$ # Done with the preparations
$ #
$ mtn ls branch
foo
$ mtn suspend w:
mtn: expanding selection 'w:'
mtn: expanded to 'bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2'
$ mtn ls branch
$

Now, if you commit a new revision on a branch where the head is suspended, that branch will reappear.

$ echo b > b; mtn add b; mtn ci -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'foo'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
foo
$

However, if you commit that same new revision with a new branch name, the old branch (whose head is the parent of the newly committed revision) will remain invisible, while the new one appears, with a history that goes back into the old (now invisible) branch.

$ # This example is instead of the previous commit
$ echo b > b; mtn add b; mtn ci -b bar -m 'b' b
mtn: adding b to workspace manifest
mtn: beginning commit on branch 'bar'
mtn: committed revision fc6c73dc99a8f71350507a5369bdd0fa93664b41
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: fc6c73dc99a8f71350507a5369bdd0fa93664b41
Parent:   bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:32:41
Branch:   bar

Changelog: 

b

Changes against parent bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2

  added    b

----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:31:19
Branch:   foo

Changelog: 

initial commit

Changes

  added    
  added    a

$

Another way to achieve the same effect without committing something new is, of course, to simply add another branch cert to the revision you just suspended.

$ # This example is instead of any of the two previous commits
$ mtn cert bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2 branch "bar"
$ mtn ls branch
bar
$ mtn log --no-graph
----------------------------------------------------------------------
Revision: bb0a1222004d13502ff27be2c92fbe6cb3f7ebf2
Author:   Richard Levitte <richard@levitte.ord>
Date:     02/28/11 08:31:19
Branch:   bar
Branch:   foo

Changelog: 

initial commit

Changes

  added    
  added    a

$

So, this isn't reeeally branch renaming per se, but it has the same effect in practice, and it comes with the benefit that this is entirely supported by monotone, there's no need to remove a whole bunch of branch certs and add the same number of new ones, there's no need to chase down every damn database this might have spread to. There's no need for trickery.

Posted Feb 28, 2011, 8:40:35 AM +0100 | Tags: hacking

It seems there's an annoying fault in dpkg-buildpackage, it doesn't support build-arch and build-indep in the file debian/rules. This blog entry talks about an easy way to solve this.

It seems there's an annoying fault in dpkg-buildpackage, it doesn't support build-arch and build-indep in the file debian/rules. Even when given the options to create architecture dependent binary packages only (-B) or architecture independent packages only (-A), it still insists on using the build target.

People have been annoyed at this for quite a while, considering there are a number of bug reports that have still not been resolved although this has been around for years (See bugs #218893 and #229357, but also more recently, #604397).

Debian Policy Manual, section 4.9 (debian/rules) seems to say, however, that it's perfectly acceptable to have the package built via binary / binary-indep / binary-arch:

For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the build target does not make much sense. For these packages it is good enough to provide two (or more) targets (build-a and build-b or whatever) for each of the ways of building the package, and a build target that does nothing. The binary target will have to build the package in each of the possible ways and make the binary package out of each.

Unfortunately, those targets are run via fakeroot, which is not recommended for configure, and sometimes not build building or testing.

So, how to solve that? There are some convoluted half ass ways to resolve this, but can it be made cleaner? Here's my attempt, entirely based on using debhelper and the script dh.

In debian/rules, disable the build target entirely, by having this as early as possible (and most definitely before the % target that's usually seen in a debian/rules that uses the command dh):

build:
    @echo 'The build target is disabled, please use the appropriate binary target.'

Add the script nofakeroot in the debian/ directory, and don't forget to make it executable. Here's what the script looks like:

#! /bin/sh

# Usage:
#   nofakeroot [command ...]
#
# Runs command after removing any trace of fakeroot from the environment it
# receives.

my_PRELOAD=
for l in $LD_PRELOAD; do
    if ! echo $l | grep "libfakeroot[-a-z]*\\.so" > /dev/null; then
    if [ -n "$my_PRELOAD" ]; then
        my_PRELOAD="$my_PRELOAD $l"
    else
        my_PRELOAD="$l"
    fi
    fi
done

was_IFS="$IFS" IFS=:
my_LIBRARY_PATH=
for p in $LD_LIBRARY_PATH; do
    if ! echo $p | grep "/libfakeroot\$" > /dev/null; then
    if [ -n "$my_LIBRARY_PATH" ]; then
        my_LIBRARY_PATH="${my_LIBRARY_PATH}:$p"
    else
        my_LIBRARY_PATH="$p"
    fi
    fi
done
IFS="$was_IFS"

LD_PRELOAD="$my_PRELOAD" LD_LIBRARY_PATH="$my_LIBRARY_PATH" eval "$@"

Finally, add a few overrides in debian/rules:

override_dh_auto_configure:
    debian/nofakeroot dh_auto_configure

override_dh_auto_build:
    debian/nofakeroot dh_auto_build

override_dh_auto_test:
    debian/nofakeroot dh_auto_test

The entire debian/rules looks like this:

build:
    @echo 'The build target is disabled, please use the appropriate binary target.'

%:
    dh $@

override_dh_auto_configure:
    debian/nofakeroot dh_auto_configure

override_dh_auto_build:
    debian/nofakeroot dh_auto_build

override_dh_auto_test:
    debian/nofakeroot dh_auto_test

Posted Feb 26, 2011, 9:38:52 AM +0100 | Tags: hacking

I've finished packaging usher... at least the upcoming 1.0 (which comes as 1.0~dev for now). Some have asked me if I can backport it to usher 0.99, and sure, I certainly can. There are two ways to do that, one is to have the tool usherctl (which is part of 1.0~dev but not 0.99) be part of the debian package, or do things a bit differently (and quite hard-coded, I might add. Still, it's quite possible to do). Choices, choices, both are ugly, just from different points of view, but may be worth it.

I've updated my list of things to do.

Posted Dec 2, 2010, 11:27:17 PM +0100 | Tags: hacking

Working out some code to make your blog nicer, easier to work with, or something else is a bit of a privilegde, and a good reason to run it on your own server.

The change I did this time is invisible to you, and involves loading the tags cloud (over there to the right)... before my change, it was really an integral part of each page, which meant that whenever it changed, every page was rebuilt (it's comparable to throwing away your cache, except more time consuming). I changed the whole thing so the tags cloud is now in its own file, and is loaded by every page using php's include_only. Voilà, much less rebuilding!

Posted Nov 24, 2010, 11:06:25 AM +0100 | Tags: hacking

For monotone v1.0, it would be nice if we actually released something that felt fairly complete. The question is, what should be included?

Right this moment, I'm looking through the contributed scripts that are packaged in the source distribution, making sure they work properly with the latest release, that they use up to date technology (let me tell you, monotone has had some cool additions lately!), things like that. Just now, I reworked the old bash completion script into a new version that gets its data directly from the current man page.

What else have I been thinking of? Well, a few things actually:

  • having newer versions of buildbot work with monotone... sadly enough, it seems like the build in support is not up to date, and it seems like it's been removed from version 0.8. Since we're using buildbot for tests, we do need to have this working. this is actually pretty high priority
  • packaging usher for Debian. I've started on the program itself, I still need to add the information for a server package around usher (I plan to call it monotone-server-usher).
    DONE
  • Keep working on the scripts in the contrib/ directory with the intention to try to see what could become supported stuff.
  • Finish up the bugfix I worked on during the last bugfest.

The list could probably be made longer. Any ideas or wishes? Please email me.

Update 2010-12-03 (1): I've now done what's needed to package usher 1.0~dev. Well, ok, except there's still no manpage for usherctl, but that's a relatively small thing...


  1. That's december 3rd 2010 ;-) ↩

Posted Nov 18, 2010, 4:18:32 PM +0100 | Tags: hacking

To see all of them, check the archive-hacking.

blog comments powered by Disqus