Category: Software Development

Categories
GNOME

Playing with GStreamer

I played around with GStreamer today to do what I wanted to do for a long time: encode the music from a music video DVD I bought as Ogg so that I can play it with my regular music player (Rhythmbox) as well as at home (my computer at home doesn’t have a DVD drive – can you believe that?)

Screenshot of gst-streamer with my pipeline

Well, GStreamer is really cool. I used gst-editor to click me a pipeline that decoded the DVD and then encoded the audio stream using Ogg/Vorbis. Now if gst-editor would at least pretend to be stable and some of its usability would be ironed out, I would be really happy.

Categories
GNOME

Switching to Subversion?

There is talk on gnome-hackers to switch from CVS to Subversion as version control system. Some people instead suggested to switch to another, fundamentally different versioning system like arch or monotone.

While I’m very much in favor of switching to Subversion, I am very against switching to a more radically different versioning system at this point for several reasons:

  • A switch to Subversion is fairly unobstrusive. Basically all the several hundred if not thousand people that are using GNOME CVS now need to do is:
    1. Learn to type “svn” instead of “cvs”.
    2. Checkout their repositories again and move possibly not-yet committed patches over to the new working copy. This is probably the most difficult task.
    3. Learn to type “svn status” instead of “cvs checkout” if they want to learn about local changes.
    4. Learn about tagging and branching by making copies. This is something most people don’t need to care about.

    Compare this to other versioning systems that work vastly different than CVS did.

  • It was pointed out that moving to arch or something similar would mean that GNOME has to move to a different development philosophy. I don’t think that this is something you can just force on the whole project and all contributors. This is something that needs a slow but steady introduction. An all-or-nothing move would probably drive people away who have better things to do with their time than to spend it learning all about versioning systems.
  • Currently there are several competing distributed versioning systems. None have proven to become the clear market leader so far. Personally I am not looking forward to learn a different system for each project that I am involved in. I feel that GNOME should not play early adopter here, but instead wait until one system establishes itself as clear leader in the F/OSS community. There are several reasons for this, one of them being that the GNOME project should not put its political weight behind any specific project.

    I still hope that some of the projects to product a distributed versioning system will merge, and work together on a better system.

In summary, while I think that GNOME should probably move on to a distributed versioning system in the long term, I do not think that this time is now. We should wait until either one system becomes a market leader and then slowly progress towards using that system. Forcing such a system on all contributors could prove very damaging to the development process. Stick to Subversion for now.

Categories
Debian Netatalk

New Netatalk Packages

Yesterday saw a new Netatalk package (2.0.2-2), since I forgot to include heimdal-dev in the build dependencies. Today another fix is needed (2.0.2-3), since it doesn’t build on amd64. I don’t expect this to be the last build failure. Let’s wait and see …

Of course I would prefer to check in the build fixes into upstream CVS, but due to my current problems with Sourceforge CVS I can’t.

Categories
Netatalk

Sourceforge CVS Broken?

Is it just me or is the CVS on Sourceforge really broken? When I tried to update, I got the error message that the host key had changed. So I deleted all known host keys for Sourceforge sites and tried again. After I accepted the new host key, I got the following error message:

Cannot access /cvsroot/netatalk/CVSROOT
No such file or directory

Trying it again, I instead got the well-known “host key changed” message. Whenever I try I get one of these two error messages. I know that I had similar problems two days ago, but after about five tries it worked at least a bit. This really sucks, Sourceforge!

Categories
Debian

Maintainer Responsibilities and Arrogance

When I was recently combing through new packages in aptitude, I came across a package named svn-workbench. Since I am a fan of Subversion the name got me interested. The package’s short description (“A Workbench for Subversion “) didn’t help much. So I went to the long description, which I will quote here in full:

pysvn-workbench is a workbench for subversion, written in the Python language.

Not very helpful either. So I decided to write a bug report to ask the maintainer to improve the full description to be actually useful. When I looked at the existing bug reports for svn-workbench, I saw that somebody else had already posted this problem as bug 299175.

Please take a moment to read the bug report. The original reporter pointed out clearly what the problem with the current description is. This was backed by another user who also pointed out that the Developer’s Reference recommends to include the upstream home page in the long description.

The maintainer’s response to the long description problem was simply: “send a patch”. Sorry, as a maintainer you can’t require users of your package to do your work, especially not if it’s a fundamental task as this. If you can’t even be bothered to write a short and concise description of your package, how can we assume that the rest of the package is not in the same miserable state? What does a lapidary comment such as this tell our users? In this case the seconds reporter was also Debian developer, but what if a normal user comes across this bug report? Also, why is the submitter expected to write a description of a software he doesn’t even know? If he knew he surely wouldn’t ask what the software does, would he?

Another point is the maintainer’s answer to the request to put the homepage in the description: “no, there’s one file where it belongs: debian/copyright. Adding it to several places is just a maintainance burden.” While I agree that the Developer’s Reference is not the Policy, it should not be lightly ignored. We want to have a consistent system, where users know what to expect. Also, normally there is a reason for the recommendations in the Developer’s Reference. In this case the long description should include the home page address so that users can view more information about the package before installing it. To refuse to include it in the long description for the increased “maintainance[sic!] burden” is just a weak excuse.

Our users have earned a better treatment, doko!

Categories
Debian

I’m back to Debian

So, I finally found time to do Debian work again after a far too long abstinence. Unfortunately I didn’t manage to hand over my Debian stuff gracefully, but fortunately there were people having an eye on them. Jonas Smedegaard had an eye on the Netatalk package and released a security fix for it. The GNOME team, headed by Sebastien Bacher was taking care of ORBit.

The first thing I did was to hotfix some of my packages. Get out a new ORBit release and release a first version of Netatalk 2, a much requested upgrade. This new Netatalk version has many improvements and it’s good to finally have it in Debian, though there is still much work to do. Soon after releasing netatalk-2.0.2-1 I got a bug report concerning CJK support. This is something that needs to go in ASAP, but currently I don’t have the knowledge to review and apply the referenced patch. I’m out of the loop of Netatalk programming as well.

So, let’s have a look at my packages:

gnome-chess
This is currently seriously broken and badly needs a port to GNOME 2. AFAIR there is some unfinished work in GNOME CVS, which I have to look into. But at the moment this package is not high priority.
gnome-pim
Another GNOME 1 package. Before my hiatus I started to rewrite this package for GNOME 2 and there were grand plans for it. These plans are still there and I have continued the port. I hope to have a working pre-release of the new GNOME 2 package out soon, though there’s still lot of work to do, before this can be uploaded to Debian unstable.
gtk-doc
While I’m still listed as maintainer, I handed this package over to Loic Minier a few weeks back, and it seems to be in good hands.
libidl
Base package for ORBit 2. Just updated from 0.8.3-1 to 0.8.5-1,
though the upstream changes were only very minor. No open bugs, this package seems to do fine.
linc
Base package for ORBit 1. Obsolete, see below.
netatalk
As I wrote above I just upgrade this to Netatalk 2.0. While this
was quite a major change (I got rid of the unnecessary netatalk-dev package in the process), I don’t forsee any major problems. The upstream package is quite well tested at this point and included in many other distributions. But you never know …
orbit
ORBit 1 is an old, obsolete package from GNOME 1 days. It has a
few open bugs, but probably nothing that is worth fixing. Instead my energies should be focussed on porting all stuff that still depends on it over to GNOME 2 (see also above).
orbit2
Just upgraded to upstream version 2.12.2. This is a fairly stable,
slowly developed piece of software. Only one open bug in the Debian BTS and that is a wishlist item. This package is also doing fine and needs minimal maintenance.

Now I have to get up to snuff at what’s up with Debian. I completely missed the DPL elections and so I will not vote, since I have not enough information about what’s currently going on. Then there was the interesting proposal about dropping stable support for less-used architectures after sarge. Oh yes, speaking about sarge. It’s still not released. But then I didn’t have high hopes that it would be …