3

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?

raj
  • 981
  • 2
  • 10
  • 8
    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 '22 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 (https://wiki.debian.org/LTS/Extended). If this system does _anything_ important, you should upgrade it. – Thorbjørn Ravn Andersen May 29 '22 at 09:08
  • @ThorbjørnRavnAndersen Paid extended support for Debian 7 is possible, but I'm sure support of sufficient quality would cost a metric shit-ton. ;-) And raj doesn't sound like having the funds for that… – Jürgen A. Erhard Aug 23 '23 at 13:25
  • @JürgenA.Erhard that means this is an excellent opportunity for more experienced users like yourself to help :) – Thorbjørn Ravn Andersen Aug 23 '23 at 19:36
  • Please note that I self-answered the question below quite a time ago and described how I did it. – raj Aug 24 '23 at 09:31
  • @raj looks like a lot of work just to avoid upgrading. Well, the experience is very valuable – Thorbjørn Ravn Andersen Aug 25 '23 at 11:30
  • @ThorbjørnRavnAndersen You basically cannot easily upgrade a VPS, you just reinstall it from a new version of the OS and reconfigure from scratch. I did it several times in my life. To restore all the functionality to the exact state it was before "upgrade" takes about a week of work, if I do nothing else in that time. So I really try to avoid it as much as possible. – raj Aug 25 '23 at 12:07
  • And if it's a live server that provides eg. email service, I need to first arrange some backup server that will take over that function for that week... – raj Aug 25 '23 at 12:08
  • @raj some interesting technical debt you have there. – Thorbjørn Ravn Andersen Aug 25 '23 at 20:10

2 Answers2

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)

Rizzer
  • 508
  • 2
  • 11
  • 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 '22 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 '22 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 '22 at 18:12
  • Other versions of the source package are available on [snapshots](https://snapshot.debian.org/package/mutt/), and the full history is [on Salsa](https://salsa.debian.org/mutt-team/mutt/). [The control file](https://salsa.debian.org/mutt-team/mutt/-/commits/master/debian/control) 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](https://salsa.debian.org/mutt-team/mutt/-/commit/95ee8e1995e40b4acc8264dd23a22bf519183716). – Stephen Kitt May 28 '22 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 '22 at 04:34
  • Kaz may be right. Many servers are dropping support for TLS 1.0 and TLS 1.1. And Debian 7 is old enough to not support TLS 1.2. https://serverfault.com/questions/637165/is-it-possible-to-enable-tls-v-1-2-in-debian-squeeze – Oskar Skog May 29 '22 at 14:58
  • At least my local mirror no longer supports TLS 1.0 and 1.1 (ftp.acc.umu.se) – Oskar Skog May 29 '22 at 15:02
  • My machine does TLS 1.2 with no problem. – raj May 29 '22 at 19:08
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 :)

raj
  • 981
  • 2
  • 10