Motivation

I’m a long time user of Jabber and Empathy. I use it for every day’s communications and, in Igalia, we have several internal rooms in which we coordinate ourselves. Because of the amount of rooms in which I am as a regular basis, Empathy’s chat window is unable to display the tabs of each of them in the top bar of the conversations.

This forces me either to split in different windows or just to navigate among them every now and then to check if there is any interesting update. Quite annoying 🙂 .

Some time ago, #586145 was filed requesting the possibility of having the chat room tabs not only displayed on top but also in other positions, specially in the side.

Hence, I decided to take the existing patch and perform some small changes to the work done by Neil Roberts in order to be able to have these side tabs.

With this new feature, you can change the position of the tabs just by changing a setting, as the position property is bond to it. If you want to set the tabs at ‘top’, ‘left’, ‘bottom’ or ‘right’, you should run, respectively:

Now, I’ve uploaded a new version of the patch and I’m waiting to pass the review process and land it.

This is a tiny enhancement on top of the great work that several GNOME developers have done in Empathy over the years. However, it is really making a difference to me so I’ve decided to share it quickly in case someone else would find it useful since it will take a while to come into the main distributions. Hence, I’ve ported it to the Empathy version I’m using in the Ubuntu Saucy 13.10 running on my desktop.

If you want to give it a try, just follow the instructions I’ve written at the beginning of this post.

Final notes

In addition to Empathy, you will be able to find in my PPAs:

A working (and custom) version of the faulty official icecc package with patches fixing LP#1182491.

A custom version of webkitgtk with patches fixing WK#115650 which will speed up opening new tabs in Web.

This is more a note pad for myself with quick instructions about how to upload a (usually patched) package to my own PPAs.

Patching an existing package

First thing is downloading the sources of the package from the repository that is providing the buggy binary package installed in my system.

For example, when patching webkitgtk, if my installed package is from a vanilla Ubuntu release, I only have to check that I have the source from the official Ubuntu repositories. However, if my installed package is from another PPA, I will have to check that I have the source from it or, if not, I would have to download the needed packages manually. Let’s assume my installed package is coming from the GNOME3 Team Ubuntu PPA:

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

$cd~/ppa/&&mkdir-pwebkitgtk/gnome3&&cdwebkitgtk/gnome3

$apt-getsource webkitgtk

Reading packagelists...Done

Building dependency tree

Reading state information...Done

NOTICE:'webkitgtk'packaging ismaintained inthe'Git'version control system at:

Just in case, something I like to do is to add the code from the downloaded package to a local git:

Shell

1

2

3

4

$git init

$git add*

$git commit-m"Initial commit"

...

Then, it is time to apply the needed changes to the source code. This is the reason why git comes handy, in case these changes are not trivial and they need actually some more work. When we are done with the changes, we have to add them to the debian package as an additional patch to the original source. We use dpkg-source for this:

Finally, we modify the release information adding or increasing the non-maintainer digit. For example, in this case the downloaded source version was 2.3.2-1ubuntu6~saucy1, so I’m setting 2.3.2-1ubuntu6~saucy1.1. Also, remember to provide the proper distribution name or to modify it when writing down the log of the changes. In this case, we are using saucy. Check also that you are using the proper email for the log. In my PPAs I use my personal one:

Importing patch alternative

Maybe this is a cleaner and quicker way of patching the downloaded sources. Instead of modifying the sources and running dpkg-source –commit, we can just import an existent patch that would apply on the source code.

To do this, we just have to run:

Shell

1

$quilt import/<path_to_original_patch>/my_patch.patch

This will also work in Debian packages for which version dpkg-source –commit won’t work. In addition, is the quickest way to reuse a patch from a package in a previous Ubuntu distribution into a newer one, for example.

From here we will retake the same steps than above to add the release information.

Building the source package

We just have to take into account that, when you have more than one GPG key available, the signature of the package will fail during the process, as in:

In addition, if the sources used for the package are not coming from one of the official Ubuntu repositories you will need to provide also the sources when uploading to the PPA. For this, you have to pass the -sa parameter. For the used example, as we are taking the source from the GNOME3 Team Ubuntu PPA, we will pass this parameter as in:

Shell

1

$debuild-S-sa-rfakeroot-k3FEA1034

While for other packages which we modify directly from the sources of the official packages provided by Ubuntu, we just use:

Shell

1

$debuild-S-rfakeroot-k3FEA1034

Optional local build

A local build is not really necessary but it will tell you if your applied changes are breaking or not the compilation of the package.

The best way of doing a trustful local build is using pbuilder.

When using pbuilder we have to be sure that we are using the proper packages not only from Ubuntu’s official repositories but also from the PPAs our target PPA depends on and also our own PPA itself.

I’ve already created the tarballs with the chroot distributions for my own PPAs. However, in order to show an example, we would be using a line like the following one for creating a new tarball for my gnome3 PPA which depends in my ppa PPA and also in GNOME3 Team’s gnome3 PPA:

Uploading to your PPA

The final step is uploading the package with the new changes to your PPA.

I actually have one sandbox PPA per each stable PPA. These PPAs are not intended for the general users but for being able to play with the changes until I feel they are stable enough to be published in the stable PPAs. Hence, I have 4 PPAs:

ppa: Where I keep changes from official Ubuntu packages that are useful to me.

ppa-next: Not intended for general users. Where I keep unstable packages with the changes that I will move to the ppa one once I feel they are stable enough.

gnome3: Where I keep changes on packages which source has been obtained from the GNOME3 Team PPA.

gnome3-next: Not intended for general users. Where I keep unstable packages with the changes that I will move to the gnome3 one once I feel they are stable enough.

With this, during the first cycles of development I will be uploading the changes to my unstable PPAs before uploading them to the stables. For this example, I would be uploading first to the gnome3-next one:

I’ve just received a forwarded mail, coming originally from the Spanish embassy in Finland. Its aim is to inform the Spanish citizens registered in the embassy as living permanently in Finland about the possibility of helping with comments to the draft of the law for “Transparency, Access to the Public Information and Good Government”. Glad to know that they are having the opinion of the Spanish citizens into account, for once 🙂

But there is a problem. It seems that they have thought the transparency should start with the citizens themselves so, this way, they have written all the addresses of the Spanish citizens registered in the embassy in the mail’s “To” field. The good side is that I know now who are all the Spanish citizens in Finland.

For the sake of the embassy, let’s hope that the Spanish Agency for the Personal Data Protection would not be around …

PS: If you check carefully, you will see, among all the addreses in red, some exceptions in black. Those are the addresses not even acknowledged as “valid” by my mail application. Ouch!

PPS: Just in case this is helpful for the workers at the embassy, I will leave here a link from a former post that I wrote about netiquette.

Update: Today I’ve received another forwarded mail from the embassy in which they apologize for this incident. The copy, at the bottom of the post.

I’m a Thinkpad Lenovo X61s owner with which I don’t use nor miss a mouse thanks to the awesome TrackPoint included. Because of that, the new Ubuntu’s scrollbars are, from the user interactivity point of view, just not usable.

Leading quickly to the “ham” 🙂 , disabling them is just a matter of writing in a console:

I’m not saying that the new scrollbars aren’t an enhancement. They allow a better usage of the display but, from the functional point of view, they only work as positioning indicator. They will tell you the progress in the scrollable window but, necessarily, you will need a wheel in your mouse or a way to emulate it. If you often have to grab the scrollbar, from a functional point of view, they are just a failure.

Hence, you will miss in Ubuntu a way to tune on or off its usage without having to use these kind of “hacks“.

Of course, another alternative would have been “to emulate” the mouse wheel through the middle button. I my case, this is not an option since last time I walked this path I decided to have a better “select and paste” experience with this button rather than use it as modifier for the vertical/horizontal scrolling.

Anyway, if you want to use the middle button this way, you had to do some changes to the “XOrg” config file before. Now, you just have to install the “gpointing-device-settings” package:

Shell

1

$sudo aptitude install gpointing-device-settings

and select the proper options after launching its UI from “System -> Preferences -> Pointing devices“.