Today I decided to tell how I reported a bug (then ended up fixing it) on a non-GIMP related project. Well I do regularly this kind of stuff, and this could have just been one more of these silent commits to a random project as I did many times in my life. But since I decided recently to post more articles, well… I may as well tell a story as one-time contributor (as opposed to “regular contributor”) for once!

Also I think the whole process of reporting a bug on projects you don’t know at all — worse! A whole stack of software you don’t know much! — is quite interesting for people wondering how they should report bugs happening to them.

Finally another reason is to advertise a bit my work, since I remind I am trying to get my Free Software coding crowdfunded through ZeMarmot project.  I am hopeful these kinds of side-stories highlight how our project is useful for Free Software as a whole, not just GIMP. Because yes, that seems unrelated, but in the same time, if I can be funded to hack Free Software full-time, it means more such unrelated bugs can be fixed! So you can consider that this kind of patch is also funded when you crowdfund ZeMarmot. 😉

The context

My main input is the ibus-hangul (Korean) input engine,  and the main languages I write are English (ibus-hangul is basically the same as “English (US)” layout when in LATIN mode, which is my default mode) and French! Sometimes when needed, I can easily switch to writing Korean while keeping the same layout.

To write French, I simply mapped a Compose key on the CapsLock key (which I don’t need). Why not switching to a layout with French characters? Well mostly because I don’t like the default French layout and am used to the US one (I have used it for a few years now), and I am also used to using Compose (I can write quickly enough all French characters with Compose, most people would not know the difference in term of typing speed).
Moreover I don’t mind changing layouts but this can be a bit confusing at times, especially if you need to change your layouts every few minutes. It’s better to just keep the same if possible.

Finally this is also the input which Aryeom uses (her main language being Korean) and she writes both in Korean and in French on daily use.

The route from bug to patch…

Or: how to report a bug … when you know very little about a software stack of dozens of software (really device input goes through so many layers that it’s making me crazy!)

Step 0: the bug!

We were using successfully our setup up until Fedora 25: Korean’s ibus-hangul IME with a Compose key. This Compose key settings was done through GNOME Tweaks Tool.

 

Then some fateful day, we updated to Fedora 26. And paf! The Compose key stopped working. Oh fateful day!

We hoped that it would be fixed by Fedora 27 (since we updated late to Fedora 26, Fedora 27 release was just a month away), but it didn’t.

Step 1: I click this button and it doesn’t work => GUI problem?

Back then though, I didn’t link the bug to ibus or ibus-hangul yet.

I first tried to track this issue in GNOME Tweaks tool (hoping that might have just been just a GUI bug; by the way, now the bug is fixed and the issue was not in Tweaks, but it seems I cannot close the report in gitlab and nobody is answering! If someone from the project reads me: just close the report, please) since that’s where I was setting the feature.

Of course, my secret hope was to just see other developers take care of it and not having to dive into unknown code. Don’t get me wrong, I’d love to fix every bug I encounter myself, but I also have a limited life span! ;P
Also I am lazy. I hear that’s a good trait by the way, nothing to be ashamed of. So really hoping someone else does the job at your place is my best expectation.

Step 2: going deeper into layers

But then after waiting for more than a month with a broken compose key, I couldn’t stand anymore to write my French texts without accents. So I investigated a bit more by myself and whistled in the wind (as you can see, I still haven’t had a single answer in 3 months on this first bug report. Bit sad ?), looking for which dconf key Tweaks Tool was changing, and seeing that it worked at least here: the dconf key was properly updated so Tweaks was likely not at fault.

So was GNOME the culprit not doing proper action with this dconf value? To decide this, after I understood that this was just a X11 options (the bug also happened on Wayland though), I tried various combinations of trying to set “compose:caps” directly with setxkbmap, or even updating XKBOPTIONS directly inside X11 config files (something I hoped I would never have to do ever again, and for years it seemed like it would hold) and restarting X.

It didn’t work. So I became more certain the problem may be deeper and something was broken in X and Wayland. I asked someone who knows better than I on this whole graphics desktop stack (Thanks Carlos for always helping me out! I know I can be annoying sometimes! ?).  He advised me to open a bug report at libxkbcommon, which was used both for X11 and Wayland. So I did.

Step 3: …and deeper…

Continuing my own investigations, I realized that the problem was not happening on every input method, but even stranger, the input order changed the behavior! ?

This is when I was told the order indeed matters and that’s expected, which I find a bit weird since it makes for very particularly unique bugs. But anyway I was not here to argue about these kind of design decision. So I followed libxkbcommon‘s developer’s recommendation and opened another report at xkeyboard-config instead.

Step 4: and back up!

Then I left time pass again for about a month, but once again failed to get an answer, therefore tried to investigate more myself, once again. I reread and thought back about my previous investigations and realized that the broken inputs were all Ibus ones (it turns out I only use Ibus inputs nowadays, mainly the Korean or sometimes the Japanese one). For people wondering what is Ibus, this is the input framework for writing languages complicated enough for which just a layout change would not work (for instance Japanese, Korean, Chinese, etc.). This is when I first started to be on the right path.

But is the issue in Ibus or specifically Ibus-Hangul?
To answer this question, I thought to be clever (I wasn’t necessarily!) by checking Fedora repository contents. There I realized that Ibus-Hangul package didn’t change its version (1.5.0) from Fedora 25 to 27. Since my issue appeared in Fedora 26, I went with the assumption that the broken part was most likely Ibus (which indeed upgraded from Ibus 1.5.14 to 1.5.16). So I opened a bug report for ibus.

This time, I had a very quick response (thanks Takao!), then a few exchanges not only telling me that the issue was indeed triggered by a change in Ibus, yet that was not really a bug in Ibus (well it’s a bit sad that Ibus does not guarantee compatibility, but I can also understand why). Ibus-Hangul had to be updated to follow Ibus changes. Better, the developer of Ibus gave me the necessary hints to update Ibus-Hangul.

Step 5: the patch

And then a few hours later, I was able to clone, read, understand and finally simply patch myself Ibus-Hangul. I immediately installed it for myself and for Aryeom, then I went and did a pull-request on upstream project (⚠ important: never forget to contribute your patches upstream! ⚠ I know, it means a bit more work; sometimes making clean code which will be accepted upstream may even take longer than making the quick-and-dirty fix for just yourself. Yet that’s how the whole software ecosystem will improve! Imagine how bugged Free Software would be if others were not contributing their patches!).

Hopefully my pull request will be accepted soon even though ibus-hangul activity seems a bit slow (yet existing! There were commits 2 months ago). But anyone in our case reading this, you can already build and install with my patch if you need.

This is also a good example to work from if ever you use another Ibus input method with the same problem. That should be quite easy to update all Ibus engines hopefully.

Step 6: it’s never finished!

The issue is mostly fixed, at least on Ibus side apparently. There is still some remnant of issue, which is that my remapped CapsLock was now working both as a CapsLock and a Compose key which is obviously not the expected result! So if I want to write ‘œ’, it would output ‘Œ’ and locks capitalization. That’s not good…

Getting again a bit of help from Takao Fujiware from Ibus project (really thank you a lot!), it seems that the bug is in GNOME this time, since I can work around it by running directly a command line command:

setxkbmap -layout us -option compose:caps

Also I realize that the issue happens even with non-Ibus inputs this time. So somehow it would seem that GNOME may not set properly the option? Let’s wait and see for answers on this report. At least this time, I have a workaround (I even have 2 different workarounds, but let’s not complicate things!)! 🙂

Conclusion

On our beloved GNU/Linux operating systems, the text input situation is mostly ok, though sometimes I must admit I wonder how many people use slightly more exotic input settings since I regularly encounter funny bugs. Well I have lived in Japan for 2 years and in Korea for 1 year, so I also know that Free Software communities are unfortunately less common over there. And among these communities, people also needing a Compose key must be even rarer.

As you may know, I love languages, so I really hope that things will improve regarding any language support. 🙂

As for the whole route from a bug to a patch, it is interesting to see how it took 5 bug reports to finally get to the right project, and a little more than 3 months for a patch written in a few minutes once I knew what this was about. Somehow this is part of the “unseen”, slow, lengthy and boring work done by every contributors out there (even more one-time contributors since they start without the whole package). And no matter how good you may think you are, you are always a newbie somewhere. I personally even consider to be a constant beginner on most topics, even the ones I know best. This makes things easier because I don’t set impossible expectations on myself but also others.

Thanks for reading my story!

Reminder: my Free Software coding can be funded on:
Liberapay, Patreon or Tipeee through ZeMarmot project.