4

I have a machine with Debian 7 (yes, I know this system is quite old, but right now I can't upgrade to a newer version). This version has mutt version 1.5.21 in the repositories, but I would like to have mutt at least 2.0.7, because I will soon need OAuth2 support that has been introduced in this version of mutt (Gmail is withdrawing password-only login for IMAP).

I assume there's no prebuilt backport package with mutt >= 2.0.7 for Debian 7 (at least I haven't found any - if one exists, please point me to it). So I will have to compile from source. But I would like to keep Debian-specific changes to the upstream source. Can I just take a source RPM prepared for a newer Debian release and compile it on my system or will this rather not work?

Improve this question
2
  • 7
    I know you are aware that Debian 7 / wheezy is end-of-life. I'm still going to write this here, because there's going to be future readers through search engines: A debian LTS release like debian 7 being 4 years after end-of-life means that there is no security updates anymore for these. Your system might have security vulnerabilities that have literally be patched everywhere else (think heartbleed, log4shell…), and there's not going to be patches. Don't use this for everyday work like browsing, writing emails, or for servers reachable via local network or the internet!
    – Marcus Müller
    May 28 at 20:36
  • 2
    Often it is possible to get paid extended support for EOL-ed systems. Even that has run out for Debian 7 (wiki.debian.org/LTS/Extended). If this system does anything important, you should upgrade it.
    – Thorbjørn Ravn Andersen
    May 29 at 9:08

2 Answers 2

Reset to default
8

Building a deb package from source is relatively easy (note you want the DEB source not RPM) but you need to be careful with library dependencies. The new mutt might need library versions not available for the old Debian installation.

Inspect package requirements from the package page at https://tracker.debian.org/pkg/mutt . Notice the versioned links. The "box" symbol links the control file, which lists Build-Dependencies.

The most recent version 2.2.4-1 requires

Build-Depends: debhelper-compat (= 12),
 docbook-xml,
 docbook-xsl,
 gawk,
 gettext,
 libgnutls28-dev,
 libgpgme11-dev,
 libidn2-dev,
 libkrb5-dev,
 libncurses5-dev,
 libncursesw5-dev,
 libgsasl-dev,
 libtokyocabinet-dev,
 pkg-config,
 w3m,
 xsltproc,
 zlib1g-dev

Notice some of these have version numbers in the package name. Are they available for Debian 7? If not, it's going to be a nightmare iterating recursively down the chain of Build-Dependencies, probably not worth it. The next oldest version packaged for Debian was 2.0.5, not recent enough for your requirements.

If Debian 7 does happen to have the required libraries (libgnutls28-dev, libgpgme11-dev, etc), then the next step would be to download the orig tar file (the upstream source tarball), the debian .dsc file and the debian diff file (.debian.tar.xz), all available from the package page at https://packages.debian.org/unstable/mutt.

If you download those 3 files (and maybe the orig.tar.gz.asc for checksum), then you would unpack with

dpkg-source -x mutt_2.2.4-1.dsc

(dpkg-source is in the dpkg-dev package)

Then cd into the source dir (mutt-2.2.4). If all build dependencies are in order, all you would need to do is run

dpkg-buildpackage

The .deb binary will be created in the parent directory, which you can install manually,

sudo dpkg -i mutt_2.2.4*.deb

You'll likely have problems with the required library versions listed in Build-Dependencies. I expect that it will not work on Debian 7 (without rebuilding the entire chain of libaries, which I'd judge as not worth the effort).

Apart from that you'd probably have a problem with Build-Depends: debhelper-compat (= 12), which is more easily dealt with. Replace debhelper-compat (= 12) with debhelper (>= 9~) and create a file debian/compat containing simply the number 9.

For good measure you'd want to create your own debian/changelog entry to mark your local build with its own version number, which you can do using dch (debchange from the devscripts package)

Improve this answer
8
  • Of course it's DEB not RPM. I made that mistake as I was recently compiling a lot of packages for CentOS and I'm still thinking about RPMs :). Thank you for your explanation, seems quite complicated but I'd have probably to try anyway...
    – raj
    May 28 at 18:08
  • With regards to those library versions, you could try replacing libgnutls28-dev etc with the equivalent available counterpart in Debian 7. Depending on how the new mutt is designed, perhaps it will work. You can test local build capability with a conventional manual build (./configure; make)
    – Rizzer
    May 28 at 18:09
  • Second comment: the process is somewhat simpler when rebuilding existing versions (e.g. to customize the build). In that case apt-get source mutt will set up the source directory (for the "standard" version) ready for build.
    – Rizzer
    May 28 at 18:12
  • Other versions of the source package are available on snapshots, and the full history is on Salsa. The control file hasn’t changed much in recent years but a few of the changes are probably significant for a backport attempt to Debian 7; this one in particular.
    – Stephen Kitt
    May 28 at 19:04
  • 1
    Debian 7 might not have sufficiently up-to-date SSL/TLS so that you can even fetch packages.
    – Kaz
    May 29 at 4:34
0

Finally I had some time to do it.

First, I was wrong about the needed mutt version; the information I got from some website turned out to be incorrect. Reading the mutt changelog I found out that support for OAUTHBEARER authentication method has been introduced in mutt 1.11.0 (and in 1.11.4 some important bug regarding particularly Gmail was fixed), and support for XOAUTH2 has been introduced in version 2.0.0. But for Gmail you don't need XOAUTH2; OAUTHBEARER is sufficient. So the lowest mutt version that I need is actually 1.11.4.

Thanks to link provided by @Stephen Kitt I was able to find various versions of mutt that were packaged for Debian and found out that the highest one that compiles without problems on my system is 1.14.4-1. Except debhelper (>= 10) (my system has debhelper 9) all the libraries it depends on are present on my system or can be installed (like libgnutls28-dev which can be installed from wheezy-backports).

It turned out that the build also required automake 1.16, which is not available for Debian 7. As this is just a script and doesn't have any specific dependencies, I was able to install a package intended for one of the later Debian releases.

The build went without problems. It is not the case for later versions (starting with 1.14.4-2) - these have dependency on debhelper-compat (= 12) and build fails with some automake related errors. It probably can be fixed, but I didn't investigate this further as I had a version that builds properly.

Getting the newly built mutt to actually work was however another thing. First, it turned out that GPG support isn't working. This is due to the fact that new mutt (contrary to the old one) wants to use libgpgme by default - this is achieved with setting set crypt_use_gpgme=yes in the default config file provided with the distribution (and I was still using the old config file). With this setting, GPG support works, but I'm not satisfied with it, as libgpgme in version 1.4.3 (build required upgrade to version at least 1.4.0) uses gpg2 (and pulls it in as dependency during installation), and gpg2 in my locale has completely broken character encoding on the screen where it asks for passphrase: enter image description here This looks very ugly, and also if that screen appears even once, mutt does not clean up the screen properly on exit, and you are left with the remains of mutt output on your terminal, and Linux prompt somewhere in the middle...

So I didn't want to use libgpgme and switch back to "classic" GPG support (set crypt_use_gpgme=no, which is the built-in program default), but - as I mentioned - this didn't work. It took me quite a lot of time to find out, that there is another default that changed, which is not mentioned in the documentation - the new mutt expects gpg-agent to be running (which is generally not the case for non-GUI systems) and does not ask for GPG passphrase by itself, leaving it to gpg-agent. I needed to put another setting set pgp_use_gpg_agent=no in the config file to bring back the old behavior.

Then I also noticed some differences in the UI behavior from the old mutt that were annoying me - first, when I used the v key to display attachments, and pressed Enter on a text/html part, it was displayed in internal viewer as raw HTML while the old mutt called the browser specified in the mailcap file (ie. w3m) to display it. The second, when I used the M key to move a message to folder, instead of cursor positioned on last-used folder, it was always positioned on top of the folder list. Having three screens of folders, it is really annoying to have to scroll each time to the one I need.

It turned out there were two specific patches in the old mutt responsible for this behavior, that somehow didn't make it to the later release. I had to integrate these patches into the source and rebuild.

That's it for mutt itself. But the REAL challenge was the helper script mutt_oauth2.py which actually obtains the authentication token from Google. It is written in Python 3.7 and uses a lot of features from this version. And the highest Python version you can get for Debian 7 is 3.2. So it required really LOT of work - too much to describe here - to change the script to make it work with Python 3.2.

But finally it works :)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.