The GPG key has expired, this produces the following warning:

==> Verifying source file signatures with gpg...
    neomutt-20170714.tar.gz ... Passed (WARNING: the key has expired.)
==> WARNING: Warnings have occurred while verifying the signatures.
    Please make sure you really trust them.
:: Building neomutt package(s)...

It's only a warning, the package still builds correctly.

Hello @neomutt/arch-users!

Management of Arch/AUR

There are a lot of changes coming to NeoMutt's build and install.
I suggest using this issue as a discussion board and creating pull-requests as needed.
Whether you make changes as they happen in NeoMutt, or wait for us to finish, is up to you.

If you have any questions you'd like me to answer, please @mention me.
Any of the Team's maintainers can authorise adding new members to @neomutt/arch-users.

You can create any branches you need.
You can merge any commits you like.

At release time, @shioyama or @flatcap can push the changes to the AUR repo.

Changes

Pull-request neomutt/neomutt#763 renames a few more files to ensure that Mutt and NeoMutt can be installed in parallel.

Obvious changes:

• Binary is now called neomutt.
• Version number doesn't contain Mutt's version
• Strings presented to the user refer to NeoMutt, not Mutt

The Build

Since its creation NeoMutt has stripped out a lot of compatibility code that Mutt had, for: regexes, iconv, ... We now rely on the host system to provide these.

Also, we have reduced the number of build choices.
Having so many configure options made testing the Mutt build a nightmare.
Any options that didn't require any external dependencies are now built-in by default:

• compressed
• imap
• nntp
• pop
• sidebar
• smtp

I suggest making all the remaining configurable options available to the user.

Testing

@hobarrera has hooked up GitHub to Travis and Docker.

All new commits to GitHub will be tested.
You may wish to tweak the Travis options if you with to reduce the load on Travis.

For more details, see:

• .travis.yml
• docker-makepkg

Should we fork this repo into NeoMutt?
Should we adopt the repo completely?

The New Build

Future change

The plan is to replace the autoconf build system with autosetup.
autosetup will make it easier for us to maintain the build system.
Also, it's simpler to use and quicker to run.

The configure options have changed and been standardised:

• Summary of changes
• autosetup-rename.sed

You can experiment with it in the autosetup branch devel/autosetup.

Both systems will be available in parallel for several releases

Splitting the Build

Future change

Currently, there's one repo which contains everything.
The plan is to split into three repos: code, docs, contrib.

This will make more packages to deal with, but will make each one much simpler.

Do you need more repos?
Would extra branches be enough?

Deprecation Warnings

Future change

There are 24 config symbols that are aliases for other config items.
They haven't been documented for many years. They will be removed in a future release of NeoMutt.

For compatibility, NeoMutt loads config from Mutt locations, such as .muttrc, /etc/Muttrc. They will stop being read in a future release of NeoMutt.

These changes will be introduced very gradually, over many releases.
The current idea is:

1. Advanced notices to users
   No warnings or errors
   New CLI option mutt -DX to list any future problems

2. Warn user once after startup (suggest mutt -DX)
   Warn user if they source
   Warn user if they manually enter
   Symbols are recognised as deprecated, but still accepted

3. Warn user of every symbol
   Pause after warnings
   Symbols are recognised as deprecated, but still accepted

4. Deprecation 1
   Symbols are recognised as deprecated, but not accepted
   Warnings for unrecognised symbols

5. Deprecation 2
   Symbols are no longer recognised at all

Distro Pages

The distro pages should be a good starting place for new users.
Their instructions should be understandable by a complete novice.
This includes NeoMutt developers who might have a VM with your OS in it.

They should start with:

• Name and home of distro
• Contact details for Distro's NeoMutt package

Imagine they've started with a minimal install of the OS, what do they need to do?

• Support
  Which versions / streams of the OS are supported?

• Installation
  Simple instructions to install NeoMutt

• Update
  How to update both NeoMutt and the main system

• Removal
  How to remove NeoMutt
  How to downgrade to Mutt

• Building from Source
  How to install the build requirements for NeoMutt
  (the specifics of the build are common to all)
  How to install NeoMutt

• Debugging
  How to install the debugging requirements for NeoMutt
  (the specifics of debugging NeoMutt are common to all)