::: [signoff/#debian-devel] Osk_epic (goodbye, epic) [01:35]

After many years using EPIC as my IRC client, I just moved to irssi, which probably has a more active development community and a lot more plugins. I never found an epic4 script that completely satisfied me, and for now, I feel a bit lost with irssi, but it's probably a matter of time.

Probably the most uninteresting blog entry ever. Sorry. :)

Some weeks ago, I discovered I was included in the list of people who were going to do talks in this year's Campus Party, although nobody had asked me in advance. A few weeks later I did get a mail regarding this, which I answered, but I never heard anything else, so I assumed I didn't have to do it in the end.

Well, it actually seems like they still counted on me, apparently, as I was listed in the time table to do a workshop on Debian last Tuesday. So not only they didn't call me to give me details on dates for the talk, but they also didn't remove them from their planning. I imagine participants went into the room last Tuesday, waited a bit for me, thought I was a bastard for not showing up and went back to their computers to play some more of whatever the current 3D bloodfest game is right now.

In the case that anyone at Campus Party is reading this: sorry, I didn't show up because I was never informed.

Chris Blizzard posted about Mozilla translation management. While I haven't been involved directly in Catalan translations of Mozilla, I maintain a few Debian packages of Mozilla translations to Basque and Catalan, and know now painful it can get to translate a Mozilla product.

The biggest problem, to the eyes of a translator completely used to gettext, is that Mozilla uses its own native i18n/l10n system and that's a very immediate barrier, as Chris points out. I think it would be very beneficial if Mozilla created an "official" bridge from their native formats to the PO format, which was integrated in the Mozilla build setup. Mozilla could distribute the POT file of their releases (alpha, beta, rcX), which translators could pick up, translate using well-known tools, and submit back to bugzilla. The po files would be integrated in upstream CVS, and could be available for the final releases. This would probably mean enforcing a string freeze of some kind in the final stage of the release process, so translations for rc2 would still be complete in the final version, like GNOME does already.

Right now, the Translate project is on the lead providing a suite of scripts that convert from mozilla to po and viceversa, but the process is still annoying enough and error prone to scare non-technical translators away. If Mozilla could take this and integrate it in their trees so that translators just need to care about translating the messages, and not about creating XPI files and so, I'm sure the translating effort would improve a lot in the mozilla world. MozillaTranslator is just not good enough anymore.

There are other minor problems, like some Mozilla dialogs having an apparent fixed size. For example, the account creation helper in the Catalan version of Thunderbird just shows half of the "Cancel" and "Ok" buttons, probably because the Catalan text is one or two lines longer than the original, and the dialog doesn't resize to fit correctly or so; you get a scrollbar instead. In other cases, like the About dialog, you don't even get a scrollbar. In some cases, the translator can define the size of the dialog, but this is just another problem in the translation process. GTK apps, for example, do resize and wrap text as needed. I don't know much about XUL, so I'm probably saying nonsense here.

(In a GNOME desktop, really)...

The other day I was looking for some easy-to-use GNOME frontend for GNU parted, but all I could find in Debian was QtParted, which isn't quite GNOMEish at all. So I started thinking on the apps GNOME is missing and I'd like to use, besides the parted frontend.

I'm still using EPIC4 as my main IRC client, although I've started to explore irssi-text to see if I end up switching, given I still don't find the perfect epic script that makes me comfortable enough. These days I wouldn't mind switching to a graphical IRC client in some cases (ie, all except when I'm on a remote link), but XChat is too complex, and I'm used to HIGgy GNOME software now. I haven't tried gnomechat, but it seems to be a bit stale lately, and I really need Jimbob to work on other fronts. ;)

I'd like to manage some stuff like my CD collection, but GTKtalog is still using GTK+ 1.2, but it seems they've been working on a GTK+ 2.0 version. I really want to avoid dealing with GTK+ 1.2 apps at this stage, and it seems the porting work is a bit stalled in CVS. For books, I want to explore Alexandria, but haven't had time yet. It looks promising. I'm not sure what the state is for Photo managers. It seems GThumb is the natural choice (as suggested by gnome-volume-manager), but as my camera isn't supported by the "Import photos" thingy, I can't say how good or bad it is.

I had thought of a nice list of programs that I would like to see born in the GNOME world, but I've forgotten of most of them. It's lovely to be underslept.

While all the critical bits are in Sarge now, there are some packages like gnome-applets that still need to transition. All of the remaining stuff is waiting on gst-plugins0.8, which should be ready to enter testing tonight. The only thing preventing this is that it needs the new version of libxml2 as well, and libxml2 isn't being built on hppa due to a binutils/gcc/whatever bug. Hopefully this will be corrected soonish and gst-plugins will finally be able to get in testing, allowing me to stop these stupid posts on the matter. ;)

Yesterday, a General Resolution was proposed to decide if the new amd64 architecture is added to the list of supported architectures in Debian 3.1. After reading the thread (and before reading it, anyway), I can't agree more with joeyh's post on the matter: if Debian as a group can't decide about things like this in a civilised discussion in the debian-devel mailing list, it probably means we're fucked. Not so long ago, proposing GR's was an exception, something we got to when reaching a reasonable consensus was completely impossible, and never for strictly technical issues like this one. We do need to vote major political issues like wiping non-free from the archive, or ammendments to the Constitution or whatever, but voting what architectures we're going to support in Sarge is wrong.

Sure, it would be very nice to have amd64 in Sarge, but how positive are the porters that this wouldn't mean yet another delay for our release? How widely tested is the port, given it hasn't entered unstable officially? I'm all for it's inclusion in unstable as soon as our infrastructure can deal with it, but making it mandatory to ship with sarge seems too dangerous to me. Besides, there are alternatives. There are no precedents, but how crackful would it be to add the port to Sarge after it is released, say in 3.1r1 or r2? Why don't we, instead of complaining that not including it would make us not support in the next 2 years an architecture that will soon become more and more popular, commit to doing more frequent releases, so this is a not-so-big issue anyway?

As joeyh and others said, I really hope things change in the future, this situation makes Debian less and less interesting.

Firefox 0.9 is now in unstable, so it was time to do the matching mozilla-firefox-locale-ca. Unfortunately, the upstream XPI had the same problems as the new Thunderbird: by default, it writes the Catalan profile stuff to the base defaults directory, instead of using a CA/ subdirectory. It's also missing some files that were present in previous versions, so I have held the upload until I discuss in the translation mailing list.

On the GNOME front, our chances of getting gst-plugins0.8 and the packages waiting for them have temporarily vanished, as an upload of gst-plugins0.8 was made. seb128 has asked David to ask before doing new uploads, so hopefully things will go better in the future. We're still missing a build of jack-audio-connection-kit for alpha to make gst-plugins0.8 a testing candidate. I'm trying to get jbailey do the dirty job for us. :)

Last night things finally worked out as we wanted and cupsys, kdelibs, samba, wine and various GNOME bits managed to entered Sarge. Thanks to all of you who had the patience to hold off your uploads to help this happen. And big thanks to vorlon and Kamion for nursing all the stuff.

More surprising is to discover, along with all of the above, that gstreamer0.8 also made it in testing, at least according to the testing output interpreter. If this is true, it would mean all of the important problems of GNOME in testing would be solved now. In any case, when you apt-get update tonight, you testing users should finally get a working gedit and other stuff.

Update: I was obviously too sleepy to blog... what we're missing is gst-plugins0.8, not gstreamer itself.

Yesterday after lunch I decided I would spend all the evening doing pending Debian work. I uploaded mozilla-locale-eu 1.7 for the Basque guys, did my own mozilla-thunderbird-locale-ca as soon as I spotted thunderbird 0.7.1 in incoming, then moved to freeciv bug triaging and ended up fixing just two bugs (other bugs are fixed upstream for 1.15), and finally I did some bug fixing in alsa-utils, including the annoying alsaconf config path bug. I'm still missing updates for mozilla-locale-ca (waiting for upstream) and mozilla-firefox-locale-ca (waiting for the unstable upload), but the Debian TODO is a lot better now.

gimp-print now has all builds ready to go into testing. Tonight we might go to bed with the nice surprise of getting the cups stuff sorted out.

Last evening, the release guys were doing simulations on the cupsys stuff, and everything looked well: qt3 has been accepted in Sarge, thus unblocking kdelibs. The Samba RC bug had been temporarily downgraded to help things a bit. Everything looked bright, and the release team started thinking the transition would be complete in yesterday's testing run... until we spotted a gimp-print upload in incoming. This made it not possible to have the transition done last night, but fortunately, the buildd's reacted promptly and at this time, all the 11 builds have been completed successfully, with just a few remaining to be uploaded to incoming.

The catch: the upload was marked with low priority, so it would have taken 10 days to enter testing. The maintainer was then asked to reupload with a higher urgency, and that just happenned. Guys, this is bad. If you need to push some urgency so a package waits less to enter testing, don't do new uploads just for this. Instead, explain why you need the higher urgency to the release team (always reachable in debian-release@lists.debian.org or #debian-release in Freenode. They can bump these things internally in the testing scripts.

On a related note, if you maintain a package that directly or indirectly uses libcupsys, please, please don't do uploads until further notice, or you'll be blocking the transition further. Thanks.

Obviously Murphy is not on vacation yet... another day passes in the testing puzzle world.