FOSSCOMM (GR)

FOSSCOMM(GR) has been announced.

The 1st Free Software and Open Source Software conference, is the offspring of earlier efforts (as very aptly pointed out by Asteris). What is unique about this conference is that it is more centered around getting Greek FS/OSS teams and developers to get acquainted with each other.

Translating parts of the the announcement of the conference to English:

We are pleased to invite you to the 1st Conference of Greek FS/OSS Communities (Free Software and Open Source Software Communities), which will be hosted on March 21 and 22, 2008, by the National Technical University of Athens, in Athens, Greece.

The conference includes presentations from Organizations / Communities / Teams co-operating and involved in development, promotion and advance of FS/OSS in Greece.

The schedule includes presentations from FS/OSS communities, speeches about free software, and workshops. The aim of the conference is to get the various FS/OSS communities to know each other, to find ways of co-operating even more with other FS/OSS teams which are active in the region, and to present the work of the various teams to a wider audience.

Up to date information about the conference is always available online at:

http://www.fosscomm.gr

The maximum timeslot duration for each presentation is one (1) hour.

Talk topics may include any one of:

1. Community description of a FS/OSS team
2. Description of a specific team project, or an innovative use of FS/OSS
3. Special talks (government & public sector organizations, special guests, etc.)

Teams and projects who are interested to give talks should register their intent until February 18, 2008, by sending an email to epitropi_synedrio@hellug.gr or by contacting Mr L. Mourikis by phene at +30 6937 224 764.

With regards,
Hellenic Linux Users’ Group (HELLUG), http://www.hellug.gr/
FOSS team of the National Technical University of Athens, http://foss.ntua.gr/wiki/index.php
Greek Debian Community, http://www.debian.gr/
Linux Users’ Group of Ioannina, http://www.ilug.gr/
Slackel, Greek Slackware Distribution team, http://www.slackel.gr/

This sounds like a very interesting event/conference, so if you are living in Greece, and you are involved in a free software or open source software project, team, or community, or even if you are simply interested to find out more about what free software is, the way free software works, and the people behind free software in Greece, my humble opinion is that FOSSCOMM(GR) is something you cannot afford to miss.

See you everyone in Athens!

HP3I: or “HP’s Insanely Idiotic Installers”

After my Canon i320 printer died earlier this week, I purchased a new HP D2460 this afternoon.

One of the computers which has to use this printer is a Windows machine, which is mostly used by the people who stubbornly refuse to stop using Microsoft Office at home. Unfortunately, the onus of “supporting” the idiotic joke from Redmond which pretends to be an operating system, falls on me.

This means I have to deal with the crap that comes out of Windows developers, like the error message of the HP D2460 installation CD-ROM shown below:

As you can see the installer bombs out because it can’t access a file in the G: drive. The main problem is that the particular system has no G: drive AT ALL.

This is the installer which launches from the officially packaged driver CD-ROM, and is bundled as the “driver software” with the printer itself. I’m filing a complaint with HP early tomorrow morning, but I consider this sort of bug something that should NOT have been there in the first place.

It looks like someone forgot a hardcoded path somewhere in the program’s source, but can you configure where this path points? No, because “printer drivers” for Windows are monstrously large sets of obscurely packaged binaries. Forget about “apt-get” like your Debian can do, or the simple extractable tarball of your BSD’s “pkg_add” utility. These are “teh” drivers baby… the official, the one, the only, and unfortunately — at least in my cases — the ones with the insanely idiotic installer.

(Footnote: Downloading the latest version of the 78 MB self-extracting Windows executable “printer software” from www.hp.com is not going to help, thank you. The same bug is present in that version too).

Off to see if the “basic driver” executable from the same manufacturer’s web site has a better chance of working in the aforementioned joke of an “OS”.

.. and yes, I know this post may be unfair to HP, but I didn’t buy a printer to have to deal with crappy installers like this. I also don’t care if “Windows is crappy and we have to go through shit like this” is even viable as an excuse.

This sucks HP!

UPDATE (after about an hour or so): After fidding a bit with the options of the installer, and trying both the installer of the bundled CD-ROM and the installers I downloaded from www.hp.com, several times in a row, it occured to me that it may be possible to “trick” the installer into believing that there *is* a G: drive, by:

• Sharing any random local directory through the network
• Mapping the shared directory at G: through Explorer
• Creating (through the mapped drive, to check that writing new stuff is possible) a new G:\TEMP directory

This seems to have worked around the installer stupidity, but now the installer is stuck for the last 15 minutes in “A device has been found. Waiting to complete device installation.”

Oh well, let’s wait a bit more and see what other surprises this crapware will come up with for tonight :-)

Reading: Lawrence Lessig, “The Future of Ideas”

Through a post by Palm Powered Doctor, I found out about a new book by Lawrence Lessig:

The Future of Ideas

Neatly typeset, freely available in PDF booklet format, with a very readable font and a cool-looking design, the book seems like a very intriguing and interesting piece of work. The text itself seems to be of the usual lucid quality which prof. Lessig has gotten us used to expect.

I’m off to read more of it…

Checking build environment…

Checking whether build environment is sane … build environment is grinning and holding a spatula. Guess not.

XKCD did it once more… /me grins

Mirroring the varnish-cache repository with svnsync

Quoting the Wikipedia about Varnish cache:

Varnish is a high performance HTTP accelerator designed for content-heavy dynamic web sites.

The main development repository of Varnish is very easy to browse, using Trac. You can see the latest changes through the web interface at:

http://varnish.projects.linpro.no/browser/

If you want to browse the history of Varnish when you are offline, a web interface doesn’t really cut it. You will have to somehow “mirror” the official repository.

Fortunately, Subversion supports read-only mirroring of repositories, using the svnsync utility. The documentation of svnsync is not really very good, but after a bit of Googling, it is easy to locate the svnsync mini-guide of Paul Querna at:

http://journal.paul.querna.org/articles/2006/09/14/using-svnsync/

Adopting this mini-guide to the Varnish repository, here’s a short guide which lists all the steps you will have to perform to create a read-only mirror of the Subversion repository of Varnish.

1. Initialize a new, empty Subversion repository

$ mkdir -p /ws/varnish/svnroot
$ svnadmin create /ws/varnish/svnroot

2. Create an empty ‘pre-revprop-change’ hook

The svnsync utility requires a valid “pre-revprop-change” hook script in the target Subversion repository. It does not really matter if the hook does absolutely nothing. The only requirement is that it exists, and that it is executable:

$ echo '#!/bin/sh' > /ws/varnish/svnroot/hooks/pre-revprop-change
$ chmod 0755 /ws/varnish/svnroot/hooks/pre-revprop-change

3. Set up your environment for the conversion

It gets tedious having to type the same stuff multiple times, so it will be useful to have the source and target repositories available as handy shell variables:

$ export TOREPO='file:///ws/varnish/svnroot'
export FROMREPO='http://varnish.projects.linpro.no/svn'

4. Initialize the target repository of svnsync

$ svnsync init ${TOREPO} ${FROMREPO}
$ svn proplist --revprop -r 0 ${TOREPO}

After this step it should be possible to look at the “svn:sync-from-url” property of the target repository and see the stored URI of the source repository:

$ svn propget svn:sync-from-url --revprop -r 0 ${TOREPO}
http://varnish.projects.linpro.no/svn

5. Start the synchronization of the target repository

svnsync --non-interactive sync ${TOREPO}

This should start pulling changesets over HTTP and committing them in the target repository.

The synchronization process may be interrupted and resumed later. It will keep pulling changes incrementally, from the point where it stopped.

Notes

The whole synchronization thing is not really optimal, as far as speed or time is concerned, because it pulls each Subversion changeset separately. This tends to be a bit slow, if you are behind a congested or slow connection. But it eventually completes. When it does, you can use the read-only local repository mirror quite easily:

$ svn log -r 1314 file:///ws/varnish/svnroot
------------------------------------------------------------------------
r1314 | phk | 2007-04-19 12:34:45 +0300 (Thu, 19 Apr 2007) | 3 lines

Standards compliance: fputs(3) returns non-negative on success.

------------------------------------------------------------------------

Experimenting with Mercurial “named branches”

As an experiment with the “named branch” support of Mercurial (Hg hereafter), I’ve started updating the editors/emacs-devel port of FreeBSD, using an Hg repository with two branches:

• HEAD is the main branch where history is imported from the official FreeBSD CVS repository
• keramida is a named branch where my own, local changes are committed

The experiment seems to be going pretty well so far, and the port has been updated to a CVS snapshot of the GNU Emacs source tree obtained at 1 Jan 2008, 21:19:17 UTC. You can see the Hg repository with the two named branches at:

http://hg.hellug.gr/keramida/ports/emacs-devel/

I’ll keep the converted port repository around, and see how future updates work. I’m really interested to see what happens with “merges” of upstream code, after the current “keramida” branch has been committed upstream, to the official FreeBSD ports/ repository :-)