From time to time I find myself using git-svn with projects using subversion, this is all nice and fine but it takes quite some time to do the ''initial import'' if you are doing it over a remote transport such as ssh+svn.

One trick to speed things up is to use rsync to copy the svn repo locally and then ''git-svn'' it from your harddisk. The idea is originally documented at the allegro wiki

For example a typical sourceforge project will be done like this:

DESTDIR=/your/dest
PROJECTNAME=vde
PROJECTURL=https://$PROJECTNAME.svn.sourceforge.net/svnroot/$PROJECTNAME
SVN_COPY=$(mktemp -d)
rsync -c -av $PROJECTNAME.svn.sourceforge.net::svn/$PROJECTNAME/'*' $SVN_COPY
mkdir -p $DESTDIR
cd $DESTDIR
git svn init file://$SVN_COPY --rewrite-root=$PROJECTURL --stdlayout
git svn fetch
# ... git svn imports the repo ...
sed -i "s@url =.*@url = $PROJECTURL@" .git/config
rm -rf $SVN_COPY

The important bit is to remember to update the url key after updating otherwise subsequent commits will go to your rsync-ed repo and not the original one!

While working on freej we'd need to update spidermonkey/mozjs to the latest version and while doing that integrate it better with the rest of autoconf/automake. AFAICT spidermonkey/mozjs is distributed as part of XULRunner nowadays.

The requirements are to make it easy to put a new version of spidermonkey into the tree and redistribute it with make dist and also to have a successful make distcheck.

The first step is a trick explained in automake manual about third-party Makefiles so we're using a GNUMakefile.in (git) to "proxy" the targets down to the real Makefile or to ignore some targets called by autotools, e.g:

# otherwise linking static libmozjs.a with dynamic libfreej.so won't work
CFLAGS += -fPIC

# the makefile to proxy targets to
js_makefile = $(builddir)/Makefile

# proxy these targets to the real makefile
all export js-config clean libs tools:
  $(MAKE) -f $(js_makefile) $(AM_MAKEFLAGS) $@

# targets required by autotools but which we don't need at all
.PHONY: dvi pdf ps info html installcheck check install uninstall
dvi pdf ps info html installcheck check install uninstall:

This more or less fixes the make part, now for the autoconf part there's a similar tecnique in the autoconf manual involving running arbitrary configuration commands. I first tried to treat spidermonkey as a separate project via AC_CONFIG_SUBDIRS as expained in Configuring Other Packages in Subdirectories but it didn't work and I forgot exactly why.

The configure.ac (git) snippet is something like this: (sorry no highlighting, highlight doesn't support m4 yet)

if test x$have_mozjs = xno || test x$static_mozjs = xyes; then
  dnl run lib/javascript/configure after freej's configure, building it static
  AC_CONFIG_COMMANDS([lib/javascript/.xulrunner-subdir],
    (cd lib/javascript &&
      CXXFLAGS="$GLOBAL_CFLAGS $CXXFLAGS -fPIC" \
      CFLAGS="$GLOBAL_CFLAGS $CFLAGS -fPIC" \
      $ac_srcdir/configure --enable-static \
        --enable-js-static-build --disable-jit) || exit $?
  ])
fi

This will run spidermonkey configure after the main configure, at this point config.status will also expand GNUmakefile.in into GNUmakefile with the correct variables. The final step after all this work is of course to add the spidermonkey directory to SUBDIRS (e.g. SUBDIRS += lib/javascript), after that make will hopefully recurse into lib/javascript and use our GNUmakefile.

While this is nice it doesn't cater for the make dist family of autotools targets which build the real distribution tarball.

To accomplish this I've used an explicit list of spidermonkey files that will end up in the tarball and made make distdir to copy only those files plus GNUmakefile.in and the list itself (.js-distfiles). Which is the second part of the GNUmakefile.in above, i.e. distdir/distfiles targets plus distclean to clean them up, see comments in the file as well.

I hope this is somewhat useful to people who are trying to properly (autotools-wise) ship spidermonkey in their project, comments welcome as usual

This was long due, I switched from pyblosxom to the marvelous ikiwiki and gave a general revamp to my website by tweaking ikiwiki's default templates. note: the template still needs a general cleanup, don't look at it as it is not pretty (nor are the CSSes)

With some luck and mod_rewrite karma nobody's feed readers nor planets will be flooded.

Comments are powered by disqus.

It seems that automake 1.11 made it into unstable and, besides other features, that means silent rules like linux does since quite some time. For the impatient, in configure.ac:

AM_INIT_AUTOMAKE
m4_ifdef([[AM_SILENT_RULES([yes](AM_SILENT_RULES],))])

Then after a round of automake/configure the make invocation will be like

make[3]: Entering directory `foo'
  CXX    source1.lo
  CXX    source2.lo
  CCLD   lib1.la
[...]

Credit note: the autotools mythbuster guide

I'm an avid user of mozilla ubiquity but I couldn't find any commands related to debian to replace those of yubnub. So, prodded by zack I've produced some like bts or pts.

The command feed is located at ubiquity-commands (don't be scared by the "this-code-can-be-evil" subscription page) with the actual code maintained under ubiquity-commands.git.

Note that there's much room for improvement so it would be nice to have a common set of commands for the various debian web resources.

Trying to associate with 00:1c:58:10:1d:30 (SSID='ALMAWIFI' freq=2417 MHz)
                                     ^^^^^
Associated with 00:1c:58:10:15:b0
                            ^^^^^ WTF?

In other words, my broadcom card won't let me choose the access point to connect to, instead the driver picks one for you (my guess: the one with the best signal) except that autentication on that AP doesn't work.

I'm fine with machines trying by default to be smarter than me, I'm less fine when there's no way to convince said machine to do something supposedly not smart.

As explained before by Zack, it might happen that you co-administer a machine and have /etc under some VCS (which you should anyway by using etckeeper).

There are a few problems like detecting the identity of the committer and don't leave /etc with uncommitted changes so I recently came up with a slighly different solution than the one we thought two years ago (besides switching from bzr to git).

Take committer name/email from ~/.gitconfig of the user owning the tty or GIT_CONFIG or GIT_CONFIG_LOCAL if they are set.

Trap a function on shell's EXIT rather than loop on .bash_logout which applies only to login shell. The resulting code to be put in /root/.bashrc:

git_functions="/path/to/git-etc-common"

# export GIT_* variables
if [ -f "$git_functions" ]; then
  . "$git_functions"
  git_export_env
fi

case $- in
*i*)    # interactive shell
  check_uncommitted(){
    if [ -f "$git_functions" ]; then
      . "$git_functions"
      if ! git_etc_status; then
        echo "Uncommitted changes to /etc found, please commit them"
        bash -$-
      fi
    fi
  }
  trap check_uncommitted EXIT
;;
esac

Where git-etc-common is to be found here.

The two RSS feeds previously at http://people.debian.org/~filippo/NEW_rss/ have been moved to a more proper location on ftp-master and the script (tools/queue_rss.py) merged into dak thanks to ganneff.

JFTR the script scans a directory with .changes files (which happens to be NEW in this case) and generates the said feeds, it is not tied to ftp-master and requires python-pyrss2gen and python-debian.

I, like many others leave an IRC client always connected on a remote machine and my client of choice is irssi.

One good feature of graphical clients like xchat is the message notification when someone addresses you, which has the nice property to turn IRC from "pull" mode (you have to watch for notifications) to "push" mode (you get notified).

Notifications was the feature I missed the most from irssi so I hacked a solution:

Grab interesting messages from irssi and push them through an ssh tunnel, read them on the local machine and finally display them using libnotify. Implementation results follow:

• rnotify.pl is a script for irssi which pushes interesting messages to a local port
• notify-remote is a shell script to read messages on stdin and display them through notify-send
• esaurito the shell script to put it all together

if you have documentation: check that and then the source
if you don't have documentation: check the source
if you don't have the source: change project and choose a sourceful one
if you change project: prefer those with documentation

in other news, this blog comments are now powered by recaptha, a very cool project.