<p>ⓒ Richard Levitte</p>
http://journal.richard.levitte.org/tags/hacking/Richard Levitte's journalikiwiki2013-10-15T10:20:25ZDropping CTWMhttp://journal.richard.levitte.org/entries/dropping-ctwm/2013-10-15T10:20:25Z2013-09-11T12:06:04Z
<p>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.</p>
<p>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.</p>
<p>This is what I wrote on the mailing list:</p>
<blockquote>
<p>Hi all,</p>
<p>Actually, the subject line doesn't say it all, it's really been
time for quite a while.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Cheers, Richard</p>
<p>P.S. If there are no takers, I will have to consider simply
dropping the project. Nothing I particularly enjoy, but...</p>
</blockquote>
<p>Among the things I've thought about but never got to actually
doing is to add full support for <a href=
"https://en.wikipedia.org/wiki/Inter%2DClient%5FCommunication%5FConventions%5FManual">
Inter-Client Communication Conventions Manual</a>. I hope whoever
takes over gets that going, it would be a nice addition.</p>
R.I.P. VMShttp://journal.richard.levitte.org/entries/RIP-VMS/2013-06-11T08:26:49Z2013-06-11T08:26:49Z
<p>The news today, provided by The Register, is that <a href=
"http://www.theregister.co.uk/2013/06/10/openvms_death_notice/">HP
has decided to put an end to VMS</a>.</p>
<p>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 <a href=
"https://en.wikipedia.org/wiki/DIGITAL%5FCommand%5FLanguage">DCL</a>,
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.</p>
<p>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.</p>
<p>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.<br />
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.<br />
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).</p>
<p>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.</p>
<p>Today, it's like finally parting from a friend that I've seen
slowly fade away over a few years.</p>
<p>Goodbye, friend...</p>
Go sit by the lakehttp://journal.richard.levitte.org/entries/go-sit-by-the-lake/2012-03-02T10:42:48Z2012-03-02T10:42:48Z
<p><img src="http://imgs.xkcd.com/comics/error_code.png" align=
"right" width="50%" /> <a href="http://xkcd.com">xkcd</a> 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 <img src="http://journal.richard.levitte.org/smileys/smile4.png" alt=";-)" /></p>
Commenting...http://journal.richard.levitte.org/entries/commenting/2011-07-18T19:23:51Z2011-07-18T19:23:51Z
<p>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.</p>
<p>Today, however, I stumbled upon <a href=
"http://disqus.com">disqus</a>, 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...</p>
<p>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.</p>
commit-patchhttp://journal.richard.levitte.org/entries/commit-patch/2011-04-19T07:55:22Z2011-04-19T07:55:22Z
<p><a href="http://www.porkrind.org/commit-patch/">commit-patch</a>
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.</p>
<p>I recall that some people have asked if there might be some
build in support for partial commits in <a href=
"http://www.monotone.ca/">monotone</a>... there isn't. However, a
cool little tool like <a href=
"http://www.porkrind.org/commit-patch/">commit-patch</a> fits the
job perfectly.</p>
<p>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.</p>
Monotone branch renaming revisitedhttp://journal.richard.levitte.org/entries/monotone-branch-renaming/2011-02-28T10:51:41Z2011-02-28T07:40:35Z
<p>Up until now, <a href=
"http://wiki.monotone.ca/BranchRenaming/">branch renaming</a> has
been a tricky issue with <a href=
"http://www.monotone.ca/">monotone</a>... 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.</p>
<p>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.</p>
<p>My question is, though, is that really true any more? After all,
since that time, <a href="http://www.monotone.ca/">monotone</a> has
evolved further, new features have been added, and they might help
us in this case.</p>
<p>Let me introduce you to this little command:</p>
<pre>
mtn suspend
</pre>
<p>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.</p>
<pre>
$ ########################################
$ # 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
$
</pre>
<p>Now, if you commit a new revision on a branch where the head is
suspended, that branch will reappear.</p>
<pre>
$ 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
$
</pre>
<p>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.</p>
<pre>
$ # 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
$
</pre>
<p>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.</p>
<pre>
$ # 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
$
</pre>
<p>So, this isn't reeeally branch <strong>renaming</strong> per se,
but it has the same effect in practice, <em>and</em> 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.</p>
Hacking the Debian build system from within...http://journal.richard.levitte.org/entries/hacking-debian-build-system/2011-07-23T14:24:45Z2011-02-26T08:38:52Z
<p><a class="FlattrButton" href=
"http://journal.richard.levitte.org/entries/hacking-debian-build-system/"
title="Hacking the Debian build system from within..." rev=
"flattr;uid:levitte;button:compact;category:text;tags:hacking,debian,dpkg-buildpackage;">
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.</a></p>
<p>It seems there's an annoying fault in <a href=
"http://www.debian.org/doc/maint-guide/ch-build.en.html">dpkg-buildpackage</a>,
it doesn't support <tt>build-arch</tt> and <tt>build-indep</tt> in
the file <tt>debian/rules</tt>. 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 <tt>build</tt> target.</p>
<p>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 <a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893">#218893</a>
and <a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357">#229357</a>,
but also more recently, <a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604397">#604397</a>).</p>
<p><a href=
"http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules">
Debian Policy Manual, section 4.9 (debian/rules)</a> seems to say,
however, that it's perfectly acceptable to have the package built
via <tt>binary</tt> / <tt>binary-indep</tt> /
<tt>binary-arch</tt>:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Unfortunately, those targets are run via <tt>fakeroot</tt>,
which is not recommended for <tt>configure</tt>, and sometimes not
build building or testing.</p>
<p>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 <tt>debhelper</tt> and the script
<tt>dh</tt>.</p>
<p>In <tt>debian/rules</tt>, disable the build target entirely, by
having this as early as possible (and most definitely before the
<tt>%</tt> target that's usually seen in a <tt>debian/rules</tt>
that uses the command <tt>dh</tt>):</p>
<pre>
build:
@echo 'The build target is disabled, please use the appropriate binary target.'
</pre>
<p>Add the script <tt>nofakeroot</tt> in the <tt>debian/</tt>
directory, and don't forget to make it executable. Here's what the
script looks like:</p>
<pre>
#! /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 "$@"
</pre>
<p>Finally, add a few overrides in <tt>debian/rules</tt>:</p>
<pre>
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
</pre>
<p>The entire <tt>debian/rules</tt> looks like this:</p>
<pre>
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
</pre>
Done packaging usherhttp://journal.richard.levitte.org/entries/usher-done/2010-12-02T22:27:17Z2010-12-02T22:27:17Z
<p>I've finished packaging usher... at least the upcoming 1.0
<em>(which comes as <a href=
"https://code.monotone.ca/p/contrib/source/tree/1d4ef14f99fbafcc9071db37de41cfa4138dbb8d/">
1.0~dev</a> for now)</em>. Some have asked me if I can backport it
to usher <a href=
"https://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/">0.99</a>,
and sure, I certainly can. There are two ways to do that, one is to
have the tool <tt>usherctl</tt> <em>(which is part of 1.0~dev but
not 0.99)</em> be part of the debian package, or do things a bit
differently <em>(and quite hard-coded, I might add. Still, it's
quite possible to do)</em>. Choices, choices, both are ugly, just
from different points of view, but may be worth it.</p>
<p>I've updated <a href=
"http://journal.richard.levitte.org/entries/things-to-do-for-monotone-1.0/">my list of things to
do</a>.</p>
Hacking your own bloghttp://journal.richard.levitte.org/entries/hacking-your-own-blog/2010-11-24T10:06:25Z2010-11-24T10:06:25Z
<p>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.</p>
<p>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!</p>
Things to do for monotone v1.0http://journal.richard.levitte.org/entries/things-to-do-for-monotone-1.0/2010-12-02T22:35:26Z2010-11-18T15:18:32Z
<p>For monotone v1.0, it would be nice if we actually released
something that felt fairly complete. The question is, what should
be included?</p>
<p>Right this moment, I'm looking through the <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib">
contributed scripts that are packaged in the source
distribution</a>, making sure they work properly with <a href=
"https://code.monotone.ca/p/monotone/source/tree/t:monotone-0.99.1/">
the latest release</a>, 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 <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone.bash_completion">
old bash completion script</a> into a <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone.bash_completion2">
new version</a> that <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib/monotone_gen_bash_completion_table.pl">
gets its data directly from the current man page</a>.</p>
<p>What else have I been thinking of? Well, a few things
actually:</p>
<ul>
<li>having newer versions of <a href=
"http://buildbot.net/">buildbot</a> 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. <strong>this
is actually pretty high priority</strong></li>
<li>packaging <a href=
"https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.contrib.usher/">
usher</a> for Debian. <a href=
"https://code.monotone.ca/p/debian-mtn/source/tree/h:org.debian.usher/">
I've started on the program itself</a>, I still need to add the
information for a server package around usher (I plan to call it
monotone-server-usher).<br />
<strong>DONE</strong></li>
<li>Keep working on the scripts in the <a href=
"https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone/contrib">
<tt>contrib/</tt> directory</a> with the intention to try to see
what could become supported stuff.</li>
<li>Finish up the <a href=
"https://code.monotone.ca/p/monotone/source/changes/h:net.venge.monotone.bugfest-2010.28805-rlevitte/">
bugfix</a> I worked on during the last <a href=
"http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-08">
bug</a><a href=
"http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-09">fe</a><a href="http://colabti.org/irclogger/irclogger_log/monotone?date=2010-05-10">st</a>.</li>
</ul>
<p>The list could probably be made longer. Any ideas or wishes?
Please email me.</p>
<p><strong>Update 2010-12-03</strong> (<a href="http://journal.richard.levitte.org/tags/hacking/#fn:iso" id=
"fnref:iso" class="footnote" name="fnref:iso">1</a>): I've now done
what's needed to package usher 1.0~dev. Well, ok, except there's
still no manpage for <tt>usherctl</tt>, but that's a relatively
small thing...</p>
<div class="footnotes">
<hr />
<ol>
<li id="fn:iso">
<p>That's december 3rd 2010 <img src="http://journal.richard.levitte.org/smileys/smile4.png" alt=";-)" /><a href="http://journal.richard.levitte.org/tags/hacking/#fnref:iso" class=
"reversefootnote"> ↩</a></p>
</li>
</ol>
</div>