diff --git a/FAQ b/FAQ
deleted file mode 100644
index 16a411e..0000000
--- a/FAQ
+++ /dev/null
@@ -1,19 +0,0 @@
-Q: duplicity works fine when run standalone, but complains about gpg
-"public key not found" when run from backupninja
-
-A: We bet you're using sudo to run both duplicity and backupninja, and have been
-using sudo as well when generating the GnuPG key pair used by duplicity.
-
-Quick fix: generate a new GnuPG key pair in a root shell, or using
-"sudo -H" instead of plain sudo.
-
-Another solution: import the GnuPG keypair into the root user's keyring, taking
-care of running "gpg --update-trustdb" in a root shell or using "sudo -H"
-afterwards, in order to tag this keypair as "ultimately trusted".
-
-Detailed explanation: sudo does not change $HOME by default, so GnuPG saved the
-newly generated key pair to your own keyring, rather than to the root user's
-keyring. Running "sudo duplicity" hides the problem, as it uses your own
-keyring. Running "sudo backupninja" reveals the problem, as backupninja uses
-"su" to make sure it runs duplicity in a real root environment, i.e. using the
-root user's GnuPG keyring.
diff --git a/FAQ.md b/FAQ.md
index d51bf79..2f40e0d 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -1,3 +1,23 @@
+duplicity works fine when run standalone, but complains about gpg "public key not found" when run from backupninja
+==================================================================================================================
+
+We bet you're using sudo to run both duplicity and backupninja, and have been
+using sudo as well when generating the GnuPG key pair used by duplicity.
+
+Quick fix: generate a new GnuPG key pair in a root shell, or using
+`sudo -H` instead of plain sudo.
+
+Another solution: import the GnuPG keypair into the root user's keyring, taking
+care of running `gpg --update-trustdb` in a root shell or using `sudo -H`
+afterwards, in order to tag this keypair as "ultimately trusted".
+
+Detailed explanation: sudo does not change `$HOME` by default, so GnuPG saved the
+newly generated key pair to your own keyring, rather than to the root user's
+keyring. Running `sudo duplicity` hides the problem, as it uses your own
+keyring. Running `sudo backupninja` reveals the problem, as backupninja uses
+`su` to make sure it runs duplicity in a real root environment, i.e. using the
+root user's GnuPG keyring.
+
 What should I do when rdiff-backup fails?
 =========================================
 
diff --git a/Makefile.am b/Makefile.am
index 80bf945..8b2fb8a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,7 +1,7 @@
 # vi: noexpandtab softtabstop=0
 ## Process this file with automake to produce Makefile.in
 
-EXTRA_DIST = FAQ README.md COPYING AUTHORS INSTALL.md NEWS ChangeLog \
+EXTRA_DIST = FAQ.md README.md COPYING AUTHORS INSTALL.md NEWS ChangeLog \
              backupninja.spec backupninja.spec.in autogen.sh
 
 SUBDIRS = etc examples handlers lib man src