Ramble On

Title Editing and a New Repository

Fri, 27 Aug 2010 14:23:00 +0100

Yesterday I released Nautilus Flickr Uploader 0.07 with just one new feature: photo title editing.

It was a really easy to implement feature, that I don’t know why I hadn’t implemented until now, because it’s very useful.

In fact, I pushed the changes to GIT repo about two weeks ago, and I found myself using the development code instead the previous public version that I had installed in my personal laptop. I was used to setting the photo titles in the Filckr website after uploading, but now I feel it’s more comfortable doing it in the application.

I know it’s a very small enhancement, and I released 0.06 less than one month ago, but I really think it’s worth it, so it’s the only noticeable change.

That fast release cycle made me think about updates. Currently there are +550 Flickr users that have authorized the application, and I’m curious: which version are they running? Do they upgrade when there’s a new version?

Because of that I’ve decided to give better support to upgrades providing a Fedora repository (when I have some spare time, I’ll try to create a PPA for Ubuntu/Debian).

I know it implies certain responsibility, because maintaining a repository means that any new release will be installed automatically. Starting with 0.07 I’m going to sign the RPM packages with my GPG key (EA112704), although I expect people to have good practices such as checking the packages that are going to be installed in every update.

Using the repository it’s very straightforward:

wget http://www.usebox.net/jjm/nautilus-flickr-uploader/repo/nautilus-flickr-uploader.repo
su -c "cp nautilus-flickr-uploader.repo /etc/yum.repos.d/"

And now you can yum udpate (if you’re already using the application), or yum install nautilus-flickr-uploader if you’re a new user.

Besides that, yesterday I recorded a screencast showing 0.07 in action. It’s just couple of minutes, but anyway… it might be worth watching if you don’t know the application.

Nautilus Flickr Uploader 0.06 Released

Sun, 08 Aug 2010 20:30:00 +0100

This is mainly a bug fix release, with a new translation added (Arabic, that’s nine translations already in Transifex!), and I moved from the deprecated Gtk2::SimpleList to Gtk2::Ex::Simple::List.

About 6 months ago I was celebrating 100 authenticated users according to Flickr, and today I just realized that right now there are 504 authenticated users. How amazing is when someone is using something you did and shared, isn’t it?

I’ve updated the Fedora, Debian and Ubuntu packages, and you can get them all from Nautilus Flickr Uploader website (as usual).

I’ve updated the the package review request, and someone heard my call for a DEB maintainer, so the application may be submitted to Debian too. Great!

One Week Left

Sat, 07 Aug 2010 11:43:00 +0100

Six months ago we were unpacking in Exeter, and in less than seven days, we’ll be packing again. We’re leaving Exeter and Devon, and after the 15th of August we’ll be settled in Reading (Berkshire).

Our reasons to move are professional, because I have a deal with my current company to start doing business stuff in UK, and that means being near of London.

Moreover Alex is looking for a school for the next course, and for some reason, Exeter isn’t the best place to find a job. May be it’s the good weather or the high quality of life, I really don’t know.

In those six months I’ve tried to get involved with the Linux local communities in the area, going to D&C GNU/Linux User Group meetings (although we just went once, because one hour train isn’t what I call local) and E-Space meetings (in Exeter, but unfortunately not really Linux/OSS related); but I somewhat failed.

Moreover I’ve lost track with the Fedora ambassadors list, mainly because it isn’t that easy to start in a new country, and when things started to stabilize, the ambassador list got lost in my TODO list. Shame on me.

Anyway, not everything’s lost. I’ve been planing different initiatives that, because I ran out of time, I won’t start in Exeter, but hopefully I’ll manage to run in Reading.

One of them will be based in the public library. From my experience in Exeter (and I believe this applies to all public libraries in Devon), they have some spaces where you can put non-profit advertisements, and it can be a good start for a Fedora/OSS information point.

I can be in the library for one hour every week (Saturday morning, for example), and give lightning talks about Fedora and OSS to anyone interested, and it could even be a good start point for a release party for the upcoming Fedora 14.

So, I want to catch up with the list and my local ambassador activities, and get in touch with the local users group in Reading (SCLUG). I really want it to work this time, because I’m going to stay in Reading for a long while.

Is your Liferea 1.6.2 Getting Somewhat Slow?

Tue, 13 Jul 2010 14:49:07 +0100

Because mine was. I’m running Liferea for some months, with lots of feeds, and I’ve noticed lately that it was getting slower. I couldn’t say how much, but it was noticeable.

I’ve tried to unfragment the database:

$ cd ~/.liferea_1.6
$ cp liferea.db bak.db
$ sqlite3 liferea.db VACUUM;

My liferea.db was 18MB before the VACUUM and 15MB after, but the point is that I’ve noticed it’s faster starting and updating the feeds after the surgery.

Once you run Liferea and everything’s OK, you can remove the bak.db.

We're going to Barcamp Oxford

Fri, 25 Jun 2010 14:39:01 +0100

Alex finished her course yesterday (she’s now a new qualified MFL teacher, yay!), and with the intense work of the last days, we totally forgot the Barcamp Oxford that will be held tomorrow in the University Club, Mansfield Road, Oxford (obviously).

Fortunately it’s not too late! We booked two train tickets, and we’re going to the barcamp (2:30h of train but, who cares?). We have never been in Oxford, so we’re double-excited about the trip.

The worst part it’s that I don’t feel like giving a talk about anything without some previous preparation, but I’ll try to participate as much as possible.

It would be great to meet other Fedora users in the barcamp, and if you’re a Fedora ambassador planning something and need some help, don’t hesitate to contact me ASAP!

Workaround for the Battery Issue

Tue, 22 Jun 2010 20:15:00 +0100

Since I upgraded the firmware of my Acer Aspire One 110, I’ve noticed some little problems with the 6 cells battery: the laptop switches off when about one hour of battery time is left.

Well, it’s not really switch off but like it hangs: the power light it’s on, and the side cooler is working, and I have to press the power button for some seconds to stop it.

I did some research and tests, and these are the results:

$ cat /proc/acpi/battery/BAT1/info 
present:                 yes
design capacity:         7200 mAh
last full capacity:      6610 mAh
battery technology:      rechargeable
design voltage:          11100 mV
design capacity warning: 300 mAh
design capacity low:     264 mAh
capacity granularity 1:  32 mAh
capacity granularity 2:  32 mAh
model number:            UM08A73
serial number:           096D
battery type:            LION
OEM info:                SIMPLO

$ cat /proc/acpi/battery/BAT1/state 
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            824 mA
remaining capacity:      6569 mAh
present voltage:         12232 mV

The remaining capacity (green) it’s the actual battery charge, and the design capacity warning (yellow) and the design capacity low (red) are the values I assume ACPI and the battery applet are checking to calculate the remaining battery charge:

$ acpi
Battery 0: Discharging, 97%, 08:41:40 remaining

I don’t know if I’m getting it wrong, but it makes sense to me (and that 08:41:40 remaining is obviously wrong). The netbook freezes when the charge reaches 19% (aprox).

I guess the battery is advertising wrong values, and because the applet uses time as factor, I can’t adjust it properly.

So I programmed a Perl script to run by cron every minute, to check the battery charge value instead of the time:

#!/usr/bin/perl

use strict;
use warnings;

# empirical fix
my $fix = 1200;

sub getData
{
        my $file = shift;

        open(FD, '<', $file) or
                die('failed to open: ' .$file);
        my @lines = ;
        close(FD);

        my %data;
        foreach(@lines)
        {
                chomp;
                s/\s+//g;
                s/mAh//g;

                my ($key, $value) = split(':');
                $data{$key} = $value;
        }

        return %data;
}

my %state = getData('/proc/acpi/battery/BAT1/state');

exit 0 unless $state{'chargingstate'} eq 'discharging';

my %info = getData('/proc/acpi/battery/BAT1/info');

if($state{'remainingcapacity'} <= $info{'designcapacitywarning'} + $fix)
{
        system('aplay alarm.wav');
}

if($state{'remainingcapacity'} <= $info{'designcapacitywarning'} + $fix - 100)
{
        system('sudo /sbin/halt -p');
}

exit 0;
# EOF

Please, keep into account that this is a hack. After some tests, I’ve found that adding 1200 to design capacity warning it’s a good fix.

When the limit is reached, I play an alarm sound, until I call halt to switch off the netbook as cleanly as possible (notice that I’ve configured sudo to let my user run halt without password).

With this little workaround, everything in my LXDE based Fedora 13 fit my needs!

Recover your Crappy Hardware

Sun, 06 Jun 2010 22:18:00 +0100

I haven’t had the time yet to upgrade my main system to the shiny new Fedora 13, but yesterday I tried the LXDE spin in my Acer Aspire One 110 netbook, and I must say I’m very impressed.

This model of Aspire One has a couple of problems: the SSD, that it’s very slow, and the 512MB of RAM, that is certainly too short for a modern desktop.

I’ve tried a couple of distributions that implement Ubuntu Netbook Remix, because the interface it’s quite adequate for a small screen (I like the ‘maximized window’ idea), and although it’s almost usable, when the system uses the disk… it’s really annoying.

Finally I was committed to even move to just a window manager. I’ve used IceWM and WindowMaker in the past, and although I’m getting old and lazy (yes, the desktops make our lives easier), it’s OK for a device that I use mostly when I travel.

But… first I wanted to give a last chance to the desktop. I’ve used XFCE in old hardware with good results, but… what about LXDE?

After a couple of hours working with it, it has almost everything I need in that crappy hardware: good responsiveness and almost no need to use the annoying SSD.

The only downside so far is that the battery applet doesn’t seem to work properly, I have a 6 cells battery, but… 7 hours of battery life sounds too much. Indeed, I went out of battery and the applet didn’t say a thing (needless to say).

I’ll try to workaround the problem, because I really love the look and feel of LXDE. If anyone has any tips on this, please share! Thanks.

Desktop Evolution (?)

Sat, 24 Apr 2010 21:55:00 +0100

There’s a meme out there about how looked like your first desktop, and how it looks right now (related to theme changes in the next Ubuntu release).

I don’t have a screenshot of my first desktop, but I have one shot from 2003:

If I recall correctly that was a KDE 3.1.1 running in a Debian Woody with lots of steroids (please notice the Mozilla 1.0.0, great browser back in the days!).

I’ve tried to reproduce that screenshot again with my Fedora 12 and Gnome 2.28.2 (and Chromium 5.0.382.0), and this is the result:

Not that different I guess, but I don’t know if it’s good or not. I’m looking forward to see if Gnome 3 is the answer to that question.

Why My Bug isn't Being Fixed?

Mon, 19 Apr 2010 17:15:06 +0100

Today I was chatting with a workmate about some problems we’re having with different SIP softphones in Linux and the sound support, specially with Ekiga, Ubuntu and Pulseaudio.

But it’s not about that what I want to talk today, but about the feeling of my workmate that filing a bug report is useless: I’ve done it in the past, without positive results, he said.

That’s very intringuing for me, because I’ve been involved in several success stories of bugs being fixed, even in hours. Yes, Open Source rocks, but we must know how to deal with it.

So, the question is: why my bug isn’t being fixed? Let’s try to answer this question.

Nowadays it’s very frequent to use a distribution, in my case I run Fedora at home (and Ubuntu and CentOS at work), and when something fails, I usualy file a bug report. The first problem is to find where I must report.

I usually look in Fedora’s Bugzilla, to see if someone has found the same problem. If I find something that may be it’s the same bug, I add myself to the CC list and I try to add useful information in a new comment. In that way I can follow the bug evolution, and may be help.

But sometimes I can’t find something related, so I file a new bug; and the difficulties start.

A full working operative system it’s a complex software, and there are different components that interact together to make possible, for example, that I open an FTP session in Nautilus.

So, when it doesn’t work, first I must guess what component has the problem, and this may not be easy.

Then, I must distiguish between two actors:

The distributor: thus, Fedora. Packages and integrates software, and provides a full working operative system.
Upstream: the people that actually develops the software (ie. Gnome, Mozilla, etc).

Let’s say Nautilus has the problem. The next step is to decide who is more likely to fix the problem:

Is upstream managing bug reports with Fedora’s Bugzilla instance?
Is a problem related to packaging and, then a problem of the distributor?
Is it none of the above?

If we’re in case 1 or case 2, we file a bug in Fedora bugtracking and we’re done. Sometimes happens, like most problems with SELinux, or when it’s a problem introduced by the distributor when packaging the software.

Moreover there are chances that, if you blamed the wrong component, someone will point you the right one, and eventually the bug will get the required attention.

But If we file the bug in Fedora, and we are in case 3, most likely our bug won’t be fixed. We’re asking in the wrong place, and it’s possible that nobody will help us.

Every distribution has resources assigned to interface the distribution with upstream, but a Linux distribution is a huge project, and there are chances that these resources are busy.

In those cases, where the bug must be fixed in other place, we must look for the bugtraking for upstream, and file the bug there too, adding a reference in the bug in Fedora’s Bugzilla, so the distributor is aware of the problem (even it has to be fixed in another place).

Let’s see an example: Bug 542205.

2009-11-28: I filed a bug, but in the wrong component, and wrong place!
2010-02-05: I realized my mistake, so I filed a upstream bug #609085 (in the right component!).
2010-02-07: A developer upstream asks for information, I help in everything I can (just two comments). The bug gets fixed the same day.
2010-02-09: A package with the fix hits Fedora testing.
2010-02-23: The package it’s pushed to updates!

I think we can verify a couple or more things:

The bug in the wrong place (and in the wrong component!) will get rotten without any hope of being fixed.
After the bug was in upstream, I got a fix in about 2 days, and 2 days later I had a package to test it in my system (actually it fixed the problem).
Once QA it’s done, it hit updates and all the Fedora 12 users would benefit of my bug report.

To sum up, I would say that the main reason your bug isn’t being fixed is: the bug report is in the wrong place, and nobody is there to help you!

I know there may be other factors, but overall I think everything I have explained makes sense. I have experience with QA and QC, and open source software adds some complexities because of its bazaar nature that doesn’t exist in a privative world. What do you think?

Disclaimer: I’m not involved in Fedora QA team, and this post it’s result of my own experience.

How Many Users Are Out There?

Thu, 08 Apr 2010 10:03:00 +0100

Sean Michael Kerner gets it wrong in his article Ubuntu Claims 12 Million Users as Lucid Linux Desktop Nears, stating that […] Red Hat’s Fedora Linux was reporting usage of its Linux distribution at approximately 24 million installations, based on Fedora statistics as source.

After a quick check on the page, you’ll see that the number Kerner is tagging as “instalation” it’s instead connections to repositories (and he didn’t even use the unique IPs total).

I don’t know how’s Canonical getting the numbers, but Fedora metrics have some caveats (although seems it’s not a big deal if you’re writing an article in Linux Planet), and thus it isn’t an accurate way to answer the question: how many users are out there?

That reminds me, there’s a project called Smolt that aims to track unique installations of Fedora. You can opt-in during installation if you’re using the graphic installer, or install it later following some simple steps and submit your profile.

Update: just realized Seth Vidal commented on the great numbers in Linux Planet too.