Gnome Shell's calendar and Thunderbird

After I installed Fedora 20, I noticed that the calendar in Gnome Shell's clock doesn't work, i.e. it doesn't show scheduled entries. Actually, this didn't work in the older version of Fedora, neither. But now, I decided to make it work. Before describing what I've tried, and what I did, I have to describe my setup. First of, I'm using Thunderbird. Evolution proved too unstable for me so I ditched it. Next, all my calendars are stored on Google, so, no local calendar in Thunderbird. The reason I'm using Google calendars is to be able to sync with mobile phone. The reason for local client, instead of Web client, is pure habit and comotion, I like more desktop clients than the Web based. Finally, I don't mind having some additional software being installed no matter if I use it directly or not. So, usually, I have Evolution installed alongside Thunderbird.

Gnome Shell's calendar allows integration only with Evolution, Thunderbird isn't allowed. This is actually expected, as Thunderbird is primarily mail application. But using Lightning plugin, it is a very good calendar solution, too. So, no easy way to define Thunderbird as default calendar application. After some quick googling, I found the following plugin for Thunderbird. Basically, it synces Thunderbird's calendar with Evolution's, one way, and that's it. When I wanted to install it, I had a small, and unrelated, problem. Namely, I could not find how to install it in Thunderburd?! There was no option in Thunderbird for managing Addons!? After some short Googling I finally realized that the menu option on the upper right hand side (icon with three parallel lines) isn't actually the full menu! I managed to open full Tools menu item by pressing Alt+F.

After I installed this plugin, and restarting Gnome and then Thunderbird, it didn't work So, the next I tried this. But first, I checked what was the current setting:

$ gsettings get org.gnome.desktop.default-applications.office.calendar exec
'evolution -c calendar'

Ok, now I changed the value using the following command:

$ gsettings set org.gnome.desktop.default-applications.office.calendar exec thunderbird

That didn't work either. It occured to me that the problem might be that I'm using Thunderbird profiles, so I also tried to define a profile in the command:

gsettings set org.gnome.desktop.default-applications.office.calendar exec 'thunderbird -P MyProfile'

Still, no luck! Then I went back to the plugin page and saw there that I have to create initial Evolution profile. I tried that too, but again, no luck. Maybe the problem was that I'm not using local calendars but remote ones. But then I realized that there is very easy solution. Namely, I created Evolution profile that is connected to Google calendars and synces with them. Google calendars are, in turn, connected to Thunderbird and everything works!

Yet, I didn't managed to get Thunderbird used when I click on Open Calendar option in the Gnome Shell's clock. Evolution is always used. Note that I tried two things, and both didn't help. First, I tried to define Thunderbird as default Calendar application using gsettings command as described above. Next, I tried to define Thunderbird default Calendar application in menu that is accessed by selecting All setting application, Details button, and there Default applications menu option. Note that Thunderbird isn't shown as a possible Calendar application. That is because its MIME type doesn't specify it as such. To change that I used procedure described here. In short, open file /usr/share/applications/mozilla-thunderbird.desktop in text editor and modify line MimeType so that it is

MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/x-vcard;:

Now, close text editor and update database file:

update-desktop-database -q

Finally, go to Details button and you'll see Thunderbird is now offered as a Calendar application, too.

In the end, I lost few hours investigating this and trying different solutions. Hopefully, someone will find this useful and will have to waste a lot less time.

Systemd waiting for external crypted disks...

I have an external, encrypted, disk that I periodically connect to the laptop. In order to have some easy to remember name, instead of UUID, I placed an entry in /etc/crypttab:

EXTDISK UUID=a809c218-f828-4149-bd9e-1c352a5f94df none

That way, when I connect disk, it will be automatically named EXTDISK and it will have an entry in /dev/mapper directory. Eventually, it will be mounted under /run/media/<userid>/EXTDISK. Note that there are only three fields in the line, each field separated from the other using space. The last field is passphrase placeholder, but I didn't want to have it written on the disk, so I used keyword none to signal that I want to type it each time the disk is opened.

The problem with this setup is that during  boot procedure, systemd waits for this disk to appear and, since there is no disk, it has to timeout. In system logs there will be messages like the following ones:

Dec 29 13:32:15 w530 systemd: Dependency failed for Cryptography Setup for EXTDISK.
Dec 29 13:32:15 w530 systemd: Dependency failed for dev-mapper-EXTDISK.device.
Dec 29 13:37:27 w530 systemd: Expecting device dev-mapper-EXTDISK.device...

The solution is simple. In newer versions of /etc/crypttab there is nofail option that should be added as a part of the fourth field. Note that, if there are multiple options in the fourth field, they all should be separated using commas and no spaces are allowed there. This option isn't listed in the manual page I linked in the introductory section of the post, so check your local manual page about crypttab.

As a side note, while searching for the solution of this timeout problem, I needed at one point to know which physical devices are beneath luks devices, i.e. my /dev/mapper directory looks like this:

# ls -l /dev/mapper/
total 0
crw-------. 1 root root 10, 236 Dec 29 13:27 control
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-home -> ../dm-3
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-root -> ../dm-2
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 fedora-swap -> ../dm-1
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43 -> ../dm-0
lrwxrwxrwx. 1 root root       7 Dec 29 13:27 luks-c7e8d2f7-1114-45c0-333b-fb8444222884 -> ../dm-4

What I was curious about are those two luks symlinks for which I didn't know their physical devices. It turned out its easy to find out, using cryptsetup tool:

# cryptsetup status luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43
/dev/mapper/luks-a2c17ceb-222e-4cd2-3330-24a0a1111b43  is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda2
  offset:  4096 sectors
  size:    999184384 sectors
  mode:    read/write

So, there is an answer, /dev/sda2.

Sudden crash during uprgrades on Fedora 20

It happened several times already that when I started upgrade via 'yum update' gnome-shell, or X, would crash and leave package database in an inconsistent state. One of those inconsistent states is the following one:

# yum check
Loaded plugins: langpacks, refresh-packagekit
apr-1.5.0-2.fc20.x86_64 is a duplicate with apr-1.4.8-2.fc20.x86_64
apr-util-1.5.3-1.fc20.x86_64 is a duplicate with apr-util-1.5.2-4.fc20.x86_64
apr-util-ldap-1.5.3-1.fc20.x86_64 is a duplicate with apr-util-ldap-1.5.2-4.fc20.x86_64
bijiben-3.10.2-1.fc20.x86_64 is a duplicate with bijiben-3.10.1-1.fc20.x86_64
cifs-utils-6.2-5.fc20.x86_64 is a duplicate with cifs-utils-6.2-4.fc20.x86_64
duplicity-0.6.22-1.fc20.x86_64 is a duplicate with duplicity-0.6.21-1.fc20.x86_64
ghc-numbers-3000.2.0.0-1.fc20.x86_64 is a duplicate with ghc-numbers-3000.1.0.3-3.fc20.x86_64

...

Error: check all

Now, you could try with yum-complete-transaction command, which should complete transaction, as suggested by its name:

# yum-complete-transaction
Loaded plugins: langpacks, refresh-packagekit
There are 1 outstanding transactions to complete. Finishing the most recent one
The remaining transaction had 46 elements left to run
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-2.fc20 will be erased
---> Package apr-util.x86_64 0:1.5.2-4.fc20 will be erased
---> Package apr-util-ldap.x86_64 0:1.5.2-4.fc20 will be erased
---> Package bijiben.x86_64 0:3.10.1-1.fc20 will be erased
---> Package cifs-utils.x86_64 0:6.2-4.fc20 will be erased
---> Package duplicity.x86_64 0:0.6.21-1.fc20 will be erased
---> Package ghc-numbers.x86_64 0:3000.1.0.3-3.fc20 will be erased
--> Processing Dependency: ghc-numbers = 3000.1.0.3-3.fc20 for package: ghc-numbers-devel-3000.1.0.3-3.fc20.x86_64
...
--> Running transaction check
---> Package ghc-numbers-devel.x86_64 0:3000.1.0.3-3.fc20 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
Transaction size changed - this means we are not doing the
same transaction as we were before. Aborting and disabling
this transaction.
You could try running: package-cleanup --problems
                       package-cleanup --dupes
                       rpm -Va --nofiles --nodigest
Transaction files renamed to:
  /var/lib/yum/transaction-all.2013-12-29.10:53.49.disabled
  /var/lib/yum/transaction-done.2013-12-29.10:53.49.disabled

This didn't help, as evidenced by running 'yum check' command. Note that running suggested commands, package-cleanup and rpm, with given options will not help either.

I solved this using 'yum reinstall' command. Namely, for each line that 'yum check' showed, e.g.

apr-1.5.0-2.fc20.x86_64 is a duplicate with apr-1.4.8-2.fc20.x86_64

I run 'yum reinstall' with a first name, i..e.

yum reinstall apr-1.5.0-2.fc20.x86_64

The problem with this approach is that it is too demanding, you have to do it package by package. Now, if you try something like this:

yum reinstall `yum check | cut -f1 -d" "`

You'll receive a message like the following one:

Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:
     
         1. You have an upgrade for gnutls which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of gnutls of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude gnutls.otherarch ... this should give you an error
            message showing the root cause of the problem.
     
         2. You have multiple architectures of gnutls installed, but
            yum can only see an upgrade for one of those architectures.
            If you don't want/need both architectures anymore then you
            can remove the one with the missing update and everything
            will work.
     
         3. You have duplicate versions of gnutls installed already.
            You can use "yum check" to get yum show these errors.
     
       ...you can also use --setopt=protected_multilib=false to remove
       this checking, however this is almost never the correct thing to
       do as something else is very likely to go wrong (often causing
       much more problems).
     
       Protected multilib versions: gnutls-3.1.18-1.fc20.i686 != gnutls-3.1.17-3.fc20.x86_64

Looking a bit what is happening here didn't reveal a course. This is the problem with multilib programs/libraries and it seems that yum isn't processing them correctly due to either a bug or, more probably, some configuration setting. Luckily, in this case there is a way around this problem, and that is to first deinstall the old versions, and then to reinstall new ones, just in case. Because we are doing two operations that depend on state of the RPM database _before_ we begin, we'll save list of problematic packages into a file:

yum check > yum_check

Now, we first deinstall old versions of packages:

yum remove `cut -f6 -d" " yum_check`

That started all right, but again the GUI crashed!? Worse, I didn't paying attention on which package! Going through the whole process again, there were no problems!? Obviously a bug, but where is a whole different story. Anyway, after removing old packages, the new ones can be reinstalled using the following command:

yum reinstall `cut -f1 -d" " yum_check`

And that's it, the package database should be good again.

One cautionary note! When you issue 'yum remove' command very carefully check what is yum going to remove. It also removes dependencies and it might remove some critical components that can make your system unusable! As a rule of thumb, in this particular case, no dependencies should be listed for removal!