Notification to speakers

The GUADEC 2012 programme committee took a bit more time than first anticipated to evaluate all talk submissions, but it's now all done: this morning, we finally sent the notification to speakers. Thanks to everyone who submitted a talk: it looks like we'll have a great GUADEC :-) Of course, we still need to create the schedule, but that should be trivial, right? (hmm...)

If you submitted a talk and didn't get a positive or negative answer by mail, please first check your spam folder: mail is from guadec-papers, and contains Your talk at GUADEC 2012 in the subject. If you don't find anything, feel free to ping me.

Help organize the lightning talks!

Next step is the call for lightning talks and for BoFs! I guess this will happen in the next few days. I don't think we have anyone in charge of this yet, so if that's something you'd like to help with, just drop us a quick mail on guadec-list and we'll happily give you a I'm fantastic: I'm helping organize GUADEC badge ;-)

Writing cross platform code is easy nowadays. You use Qt, implement stuff, and it compiles and runs almost everywhere. I also enjoy that in my work on the ownCloud desktop client. But, as you know, there is the other part in the client called csync. Its the syncing engine underneath. And that does not build up on Qt, but is plain C. Adventure starts here.

This bug took me on an interesting (well…) journey into what cross platform really means.It is about a complex thing like filenames containing special characters, my favorite example is the directory “Übergröße”. Directories and files like this could not successfully be synced with the latest client.

Windows does not utf8 by default. As far as I understood it, it does a local encoding by default. If you use normal C functions to access the filesystem, something like readdir or so, you get the names in that encoding. But, because that caused problems in some point, there is another set of functions which often start with _w (for example _wreaddir) and that has an interface to deal with wide characters. This is the way to internationalization.

So what needs to be done is to use the wide character implementations everywhere where you deal with filenames (in my case). That, in turn, requires to use wchar_t instead of normal char. But that again requires a lot of #ifdef _WIN32, if its done the naive way at every place it needs to be done. I learned that typedef helps here and a meta type is defined called _TCHAR. And also for all the needed functions, meta functions are defined which are replaced by tricky defines depending on the platform. For example _treaddir becomes readdir on linux and _wreaddir on win32, while _TCHAR becomes wchar_t on Win and char on linux. The code is written using the meta types to not poison it too much with platform ifdefs.

But that is only the first step. Wide character is not utf8! And since utf8 should be used within the software all over, a conversion from wide character to utf8 and back is needed whenever the file system is accessed. Thankfully from csyncs nature, these places are quite nicely concentrated.

All that combines into a larger patch. And now the “Übergröße” folder can be synced correctly from Windows to Linux and back. Great.

What can we learn from that? Well, easy, and once again: If you have no Qt, you’re alone. Better don’t let that happen. If you have Qt, be happy and aware of what it does for you :-)

Some applications seems unlucky to find their way in the hearts their intended users.

Reading today  thread  "What does this error message mean?", I can see Apper sinking another few notches.

Is it Apper's fault?

The answer is not, but being visible component that appears when disharmony in software management shows up, it can fall as a victim. Use Google to find out about "opensuse apper" and you can read about a lot of problems, and advice to remove it was given so many times that new user has no problem to find it. 

Do we need simpler software management?
For sure, yes. YaST module Software Management is old guy that is exactly what old Linux users need, versatile tools for software management, not simple install or remove software  utility that we can see in some popular distros. But, times are changing, old, technically inclined computer users that were almost only Linux users are now in minority, and new generation wants to use computers, not to deal with them.

Speaking of Packman mirrors... we're in a pretty sorry state regarding that so if you're aware of sites that do mirror Packman but never told us (I'm aware of the one at yandex.ru, have to get it on that mirror list), or if you can get in touch with some mirror sites near you or even on your continent to ask them to mirror Packman, please do.

They can then simply contact us on our mailing-list (that's packman followed by an "at" sign followed by "links2linux" and a dot and "de" -- grrr to spammers) and we'll get back to them with the details for rsync.

The Packman mirror at packman.inode.at is down. We don't know yet what happened nor whether it will be back up soon (or not).

In the mean time, please use another mirror in the mean time.

Here's a quick copy'n'paste one-liner you can put in a shell (konsole, gnome-terminal, xterm, urxvt, ...) as root to switch:

perl -p -i.old -e \
's,^(baseurl=).*(/suse/.+)$,${1}http://ftp.halifax.rwth-aachen.de/packman${2}, if /^baseurl=.*packman\.inode\.at.*/' \
/etc/zypp/repos.d/*packman*.repo

Here we are in an era in which ad-based services (like LastFM) and closed-products (like Apple ones) are on the rise.

But contradicting what you may think, open source is still friendly to them.

If you have an Apple device supported by libgpod* and you're an avid user of LastFM's scrobbling feature, you can today configure Banshee to send all the songs that were played on your device to your LastFM account the next time you connect your device while you have Banshee running.

Pretty handy, especially if you own a device that doesn't have internet connection these days (something definitely not on the rise). You should thank our new Banshee developer Phil Trimble for doing an awesome job on implementing this feature (and on resisting to not sending me to hell when I made the patch reviews...).

The next version of Banshee, in the 2.5.x series, should include this feature. Until then, hold on to your seats! (or compile it yourself from master ;) )

* Beware: not the last generation ones! you would have to donate to libgpod project if you want those recognised.

PS: If you're a developer and want to extend this feature to other kind of devices, you should just implement the interface IBatchScrobblerSource in the corresponding Source class of your device. If you want to make it scrobble to a different service than LastFM, just create a Banshee addin (simple sample here) that subscribes to the ServiceManager.SourceManager.SourceAdded event to then later subscribe to the IBatchScrobbleSource.ReadyToScrobble event from it, to later make the corresponding HttpWebRequests to the scrobbling service.

... when make spends maybe 15 CPU minutes thinking really hard, with no output, and then says Nothing to be done for `slowcheck'. The mind boggles at how slow it might have been otherwise.

Bugtracker! I meant to say "bugtracker", I swear!

So, the oh so popular and useful Packman project finally has a proper bugtracker, how awesome is that? Yes, truckloads of awesome. More seriously, it was about time and I finally just decided to do it.

From now on, please use our bugtracker to submit bugs, package requests, etc..., rather than using the mailing-list, although the latter is still fine for discussions and such, obviously.

Using a bugtracker will make it a lot easier for everyone to keep up with what needs to be done, for the packagers to pick things to do when they're bored (hah! right... I had to look up that word in the dictionary), and to make it clear once more that we definitely need more packagers to join and help out.

One needs to create a user account to be able to file a bug/request, but that's quick and doesn't involve any pain. We cannot use openSUSE accounts (as on .opensuse.org), sadly.

In case you didn't notice from the links above, the URL of the Packman bugtracker is https://bugs.links2linux.org.