We had to stop releasing the Qtel client, as it relied on Qt3 which we no longer ship in Gentoo. On top of this, the ebuild installed non-Gentoo init scripts, fails to build with gcc-4.6 and fails due to underlinking. (My thanks go to Diego for pointing these flaws out.)
At the moment I’m working on the first problem, which is that the builds that were in-tree are crusty and old. svxlink did release version 11.05 not long back, and ohh yes, they’ve changed their versioning scheme too to match Ubuntu. However, their trunk branch is still dependent on Qt3 if you want Qtel. There is an experimental Qt4 branch, which is what I’ve been working with.
One irritation I had was trying to make it possible to install the client component or the server component. svxlink has its own, very custom, build system based on recursive makefiles. (Yes, I know, considered harmful and all that.) The build system first builds the core libraries, then it starts looking at Qtel and svxlink’s server components. The first thing was to try and split these up.
The new ebuilds will introduce a svxlink-libs package. This is relatively straightforward, and it just builds & installs the libasync, libechlib and liblocationinfo libraries. The catch is when building qtel and svxlink, the build system looks for the built binaries inside the source tree.
I have submitted a patch upstream that remedies this. Eventually I’ll look at how we can fix some of the other flaws in the build system. So far I’m still battling svxlink itself, but I soon will have svxlink-libs and qtel packages available for testing in the Portage tree. svxlink itself will also need to wait until I can set up a test node on simplex somewhere… my O2 looks like a likely possibility.
I’ll keep you all informed as this progresses. Qtel appears to be working (although I’m battling some funnies with the sound device on the Apple MacBook)… just a matter of fixing some issues with the build system for svxlink and I should be able to have svxlink back in the tree once again.