BerliOS, and picking up “dead” projects

So, Tomáš also posted on the gentoo-dev mailing list about the BerliOS shut down that I have noted after forking unpaper which is/was hosted on that platform as well.

And yes, I do note the irony that I’m the one talking about forks, after what I wrote on the subject — but there are times when a fork is indeed necessary, at least to continue development on a project. And I should probably consider unpaper more a take over than a fork, given that the original developer seem to be unreachable (he hasn’t answered my mail yet).

Of course nobody expected unpaper to be the only project that was hosted on BerliOS, nor the only one dead. Indeed, back in the days when interface was obnoxious but still usable, BerliOS was considered a quite decent alternative, at least for the fact that there was Subversion support quite a bit of time before SourceForge supported anything other than CVS. Even I started not one, but two projects using BerliOS. One is the same unieject that I have now mostly abandoned and is available on Gitorious; the other was an Ultima OnLine server emulator, which was, really, my first try at coordinating a Free Software project.

Update (2017-04-22): as you may know, Gitorious was acquired by GitLab in 2015 and turned down the service. My projects previously hosted there are now hosted on GitHub.

Said project, was started by me and a handful of friends, some of whom were players on the same unofficial “shard” as me, while another was a fellow developer in another similar software (NoX-Wizard), was basically a from scratch implementation, in what at the time I considered modern C++ (it might even have been, considering that we just came out of the GCC 2.96 trouble). It was also my first encounter with Python used as a scripting environment within another software. The code was originally developed by me in CVS; then it was moved to SVN on a local repository, then again on BerliOS.. with the result that my commits actually showed up under a long series of names, d’oh!

Well, a couple of weeks ago I decided to import the code to GitHub — and with a bit of help from git svn I was able to also merge back my commits under a single name (and those of another developer as well, not under mine of course). It’s impressive how straightforward is to import a whole repository’s history nowadays. I remember going crazy to do the same thing at the time, when moving from CVS to SVN, and to import the local SVN to BerliOS.

This should actually be considered a stating point: indeed the fact that it’s relatively trivial to import a repository’s history nowadays should make it much easier to preserve the most important repositories of BerliOS itself — I just wonder if there’s hope to save all the content in BerliOS. This becomes quite interesting when you note that it comes not a long time after the KO, which has seen a number of projects migrate here and there, including Linux-PAM which seem to be maintained now on Fedora’s hardware (and in GIT, finally! — this means that the next time I’ll have to patch Linux-PAM, which I hope will be far into the future, I’ll be able to provide proper backports in Gentoo infrastructure, like I do for other packages including quagga).

Changing times?

Building against non-installed libraries

If you have seen my repositories lately, you’d probably have noticed that I started working more on third-party projects, in particular you can see repositories for libxdg-basedir (which I’ve been using already for a while for xine-lib) and libxr (which is new, recently added to portage by Luca), together with those you can find a bunch of repositories from lscube and some from Lennart .

The reason for this is that I started considering taking a more active stance when I need something fixed, in particular, I’m just making my changes and then sending upstream the repositories, hoping they get merged quickly. This is the nice thing about having repositories available with GIT and all the like. Unfortunately a lot of projects are still managed with Subversion or, even worse, CVS, or other DVCS which I don’t have set up on midas (yet).

At any rate, one of the changes that is tied with all these project is probably the introduction of the -uninstalled variant of pkg-config files. Simon McVittie writes more about it than I could probably write myself.

There are a few interesting notes about this though. The first is that -uninstalled variants of pkg-config files gets often in the way of libtool; for instance you’d have to point them to the .libs/ directory used internally by libtool, or you’d be able to link against them just with libtool (as they’d point to the .la file). The other problem is that, if you’re building with libtool, it will properly set the rpath/runpath to make sure that the resulting binary is executed against the uninstalled version, but this does not happen, by default, outside of libtool. I’m still pondering whether I should change the -uninstalled.pc files to set the runpath by themselves. Unfortunately it would then work only with ld compatible with GNU syntax.

The nice part of building against non-installed libraries is that it makes it much easier to run a series of tests on the project, which is very nice once you set up unit tests .

Now if only I can solve the unit testing problem, I could be focusing on working on unit testing and possibly to extend unit testing coverage in as many software as possible, which I use, so that I don’t have to worry about broken behaviour. But this is work for another day, right now I have enough to do, I should be writing docs and articles, and converting to Glib and writing tests.

And I just came out of the hospital! I hope the games I ordered from Amazon will arrive soon so I can at least relax a bit during the weekends.

Why documentation is important

So, although I said I wanted to take a break, there was one bug I wanted to smash as soon as I can, it’s bug #131456. This bug is annoying for users and I can understand why it is, upstream fixed it so one might think it wouldn’t be difficult to backport. Yeah sure.

The upstream bug report is #0002067, and only references the bug as “Fixed on Hg repo.”, thing that does not really says much to me. I know that Hg is mercurial, but that’s just a clue. A quick glance to ALSA website doesn’t show me much about that repository.

There’s a Development Wiki but no reference, the only reference I found, in the place I wasn’t thinking of, is in the Download page. Sigh. Now it’s time to check how to get the right patch out of hg, hopefully it won’t take that much time, but the checkout itself takes a bit.

I think I’ll have the ALSA Maintainer Guide to describe the Mercurial repository later today, and here goes all my break idea.

Okay okay, I can simply put that on my TODO list and do all tomorrow, but well.. I will probably forgot at this point :(