Mutt - Neomutt and Debian Stretch

[leo]

Hi everybody,
I'm writing because I've a question about Mutt and Neomutt on Debian.
My operating system is actually Debian Stable (Stretch) and I've
installed the mutt package (1.7.2-1).

How can you see here [1] when you install Mutt, the repository
automatically install Neomutt.

I've read that Neomutt is not a fork "We merge all of Mutt's changes
into NeoMutt and get features into a state that Mutt will accept" [2].
It isn't a big problem ;) but I want Mutt and not Neomutt.

Does anyone know a solution to solve my problem (possibly without
compiling the source).

Cheers and thanks a lot:)

leo:)


[1] https://packages.debian.org/stretch/mutt
[2] https://www.neomutt.org/about.html

[steve]

Hi leo,

I have the same setup as you do (debian stretch+mutt).

On [1], one can read:

This package is built with the NeoMutt patchset, which includes a number
of additional features compared to the stock Mutt.

Which I don't interpret as you do; debian's mutt is compiled with the
NeoMutt patchset, but it's mutt and not neomutt.

So you have mutt ;)

Best,
Steve

[1] https://packages.debian.org/stretch/mutt

[Francesco Ariis]

Post by steve
Hi leo,
I have the same setup as you do (debian stretch+mutt).
This package is built with the NeoMutt patchset, which includes a number
of additional features compared to the stock Mutt.
Which I don't interpret as you do; debian's mutt is compiled with the
NeoMutt patchset, but it's mutt and not neomutt.
So you have mutt ;)
Best,
Steve

Ohhh I noticed now. I am using debian too, is our useragent actually
correct or should we change it (not that it matters much)
-F

[Kevin J. McCarthy]

Post by leo
I've read that Neomutt is not a fork "We merge all of Mutt's changes
into NeoMutt and get features into a state that Mutt will accept" [2].

No, it's a fork. And no, they don't get features into a state I will
accept.

Post by leo
It isn't a big problem ;) but I want Mutt and not Neomutt.

Let Debian know then. I used to spend time looking at Debian bugs, but
don't bother anymore. I wish they would rename their package to NeoMutt
since they've basically switched their upstream.

[leo]

Hi everybody,
thanks a lot for all your answer.

Post by Kevin J. McCarthy

Post by leo
I've read that Neomutt is not a fork "We merge all of Mutt's changes
into NeoMutt and get features into a state that Mutt will accept" [2].

No, it's a fork. And no, they don't get features into a state I will
accept.

Ok, thanks, it was a quote taken from neomutt website [1] and not my
personal interpretation;)

Post by Kevin J. McCarthy

Post by leo
It isn't a big problem ;) but I want Mutt and not Neomutt.

Let Debian know then. I used to spend time looking at Debian bugs, but
don't bother anymore. I wish they would rename their package to NeoMutt
since they've basically switched their upstream.

Yes, I'm going to let them know because of freedom of choice and
openness that because if I want mutt I install mutt, if I want neomutt I
install neomutt;)

Cheers leo


[1] https://www.neomutt.org/about.html

[Antonio Radici]

Post by Kevin J. McCarthy

Post by leo
I've read that Neomutt is not a fork "We merge all of Mutt's changes
into NeoMutt and get features into a state that Mutt will accept" [2].

No, it's a fork. And no, they don't get features into a state I will
accept.

Post by leo
It isn't a big problem ;) but I want Mutt and not Neomutt.

Let Debian know then. I used to spend time looking at Debian bugs, but
don't bother anymore. I wish they would rename their package to NeoMutt
since they've basically switched their upstream.

Hi Kevin :)
it's the Debian maintainer of the package here. As you know I've been maintaing
the package for > 8 years and we had various interactions in the past.

I agree that the naming + versioning is confusing but I've sorted that out since
we switched .tar.gz from usptream a week ago, not +neomutt2017xxxx is in the
version, for example the latest version of mutt is 1.8.3+neomutt20170609-2.
The main reason for the switch was that they have standardized code indenting,
therefore a theoretical neomutt patch would have been bigger than the source
code itself.

The reason why we don't have two source packages shipping the same binary is
because there is a huge duplication of work required on our side (we end up
applying the same patches, building it with the same flags and so on), I'll be
open to reconsider this if/when the neomutt devs stop rebasing their changes
from the latest mutt source tarball.

In the past (until 3-4 years ago?) we had more sporadic releases of mutt, which
required more work to integrate all the features, and maintaing mutt and
mutt-patched was a lot of work :(

I know it is not simple to add a feature to the main code base because certain
standards have to be respected and some patches might generate undesiderable
side effect; at the same time Debian users have grown used to features that have
been there even before I started maintaing mutt (compressed folders, sidebar,
etc) so I have to play a balancing act there.

Nothing changes from my side, I will always troubleshoot all bugs reported to
Debian (so no need for you to look at the huge bug list :) ) and I will triage
bugs to determine whether the culprit is in the mutt source code or the neomutt
patches, in either case I will always report the bug + stacktrace + patch if
available. I might have made some mistakes in the past so I'm sorry if I caused
extra work on your side, but it is my intention to do a fair amount of
investigation work before reporting any bug.

[Kevin J. McCarthy]

Post by Antonio Radici
I agree that the naming + versioning is confusing but I've sorted that out since
we switched .tar.gz from usptream a week ago, not +neomutt2017xxxx is in the
version, for example the latest version of mutt is 1.8.3+neomutt20170609-2.
The main reason for the switch was that they have standardized code indenting,
therefore a theoretical neomutt patch would have been bigger than the source
code itself.

Here's the thing. Your tarball is not just Mutt 1.8.3 + some NeoMutt
stuff. It includes most everything in my development (default) branch
for 1.9.0 as of 20170609. Stuff that hasn't had time to bake, or that I
feel I have the right to change.

NeoMutt pulls all the stuff out of *my* default branch, packs it in, and
gives to you as if it were extra NeoMutt "goodness".

With the new release numbering, I try very hard to keep the "patch"
versions, e.g. 1.8.[1-3], as bug-fix only releases. They are released
out of the "stable" branch. By calling your package "mutt 1.8.3",
regardless of what extra version labels you attach, you are reflecting
on me and making my efforts at stable releases irrelevant.

As you know, the same thing happened with 1.6.2, when you first started
incorporating NeoMutt. Your NeoMutt patches included half implemented
features from 1.7.0 development, and was broken.

Post by Antonio Radici
[...], I'll be open to reconsider this if/when the neomutt devs stop
rebasing their changes from the latest mutt source tarball.

This furthers my point: if NeoMutt drives your decisions as a packager,
you should name your package neomutt.

Post by Antonio Radici
I know it is not simple to add a feature to the main code base because certain
standards have to be respected and some patches might generate undesiderable
side effect; at the same time Debian users have grown used to features that have
been there even before I started maintaing mutt (compressed folders, sidebar,
etc) so I have to play a balancing act there.

You mean the compressed folders that I fixed up and included in 1.8.0?
Or the sidebar I spent a huge amount of effort fixing and included in
1.7.0? Wait, I must be mistaken, https://packages.debian.org/sid/mutt
says those are NeoMutt additions.

Post by Antonio Radici
I might have made some mistakes in the past so I'm sorry if I caused
extra work on your side, but it is my intention to do a fair amount of
investigation work before reporting any bug.

The problem is not in your triaging, but that not every user picks up on
the distinction when you call your package mutt. People show up in the
IRC channel or mutt-users, or submit tickets directly. Then I end up
trying to debug a problem that isn't even in the version they purport to
be using.

I understand your point about the extra work involved in multiple
packages. But it is disrespectful to me for Debian to label a *fork's*
tarball as the package "mutt". It is frustrating and demotivating that
all my work towards resuscitating mutt is lost and mislabeled to the
huge user base encompassed by Debian and all its derivatives.

[Job Snijders]

The convention is to give a fork a new, different name.
The neomutt fork did so by calling their project "neomutt".
So far so good.

I'm surprised and disappointed to see that Debian as of now
has chosen to conflate the two projects and pollute the
namespace.

Renaming Debian's "mutt" to "neomutt" will ensure that each
project receives the proper attribution and attention, and
ease triage.

Name squatting is silly and pointless.

Kind regards,

Job

[Antonio Radici]

This post might be inappropriate. Click to display it.

[Kevin J. McCarthy]

Post by Antonio Radici

Post by Kevin J. McCarthy
As you know, the same thing happened with 1.6.2, when you first started
incorporating NeoMutt. Your NeoMutt patches included half implemented
features from 1.7.0 development, and was broken.

I will be happy to understand what we are trying to achieve and mediate between
the parts if possible. Is it about having a package that contains *only* the
mutt source code as you release it? It was never like this even before 1.6.*,
when we had extra patches on the top of mutt, what should I do with
patches/features which are (and were) expected on the top of mutt?

Starting with a vanilla mutt tarball and adding a set of patches, broken
out by bug fix or feature, is fairly standard practice. It's easy to
see what is changed, and I think is still fair to call mutt.

If you take a vanilla mutt tarball and add a 30k+ line "blob patch"
called "neomutt", I don't think it's fair to call that mutt anymore.

If you don't even package a vanilla mutt tarball, but take the tarball
from a completely different project, it most definitely is not mutt.

I think it comes down to accountability. If you know the changes you
are making, then there is something of a guarantee the result is a
*Debian* packaged version of *Mutt*. Debian may have made some changes, but
is vouching that this is essentially Mutt, plus changes they comprehend
and can vouch for.

By switching out the tarball to someone something generated by another
project, or adding a ginormous "blob patch", Mutt can not and should not
vouch for it. You are relying on the other project's reputation, not
ours. It is then completely inappropriate for you to call it mutt.
It's not mutt. It's not "mutt + neomutt". It's neomutt.

Post by Antonio Radici
I don't believe that your work is lost, all your code ends up in
Debian (and derivatives) and yes there will be patches on the top of
it.

Perhaps lost was the wrong word. The code may be mixed in, but as Mutt
project maintainer, the package has nothing to do with my work anymore.
The package you are calling "mutt" is not something I've helped create.
Your version "1.8.3+blah" is not even remotely the code I decided should
be in version "1.8.3". It's code the NeoMutt project made the decision
on. Is it that hard to understand why calling it mutt upsets me?

[Erik Christiansen]

Post by Kevin J. McCarthy
Starting with a vanilla mutt tarball and adding a set of patches, broken
out by bug fix or feature, is fairly standard practice. It's easy to
see what is changed, and I think is still fair to call mutt.
If you take a vanilla mutt tarball and add a 30k+ line "blob patch"
called "neomutt", I don't think it's fair to call that mutt anymore.
If you don't even package a vanilla mutt tarball, but take the tarball
from a completely different project, it most definitely is not mutt.
I think it comes down to accountability. If you know the changes you
are making, then there is something of a guarantee the result is a
*Debian* packaged version of *Mutt*. Debian may have made some changes, but
is vouching that this is essentially Mutt, plus changes they comprehend
and can vouch for.
By switching out the tarball to someone something generated by another
project, or adding a ginormous "blob patch", Mutt can not and should not
vouch for it. You are relying on the other project's reputation, not
ours. It is then completely inappropriate for you to call it mutt.
It's not mutt. It's not "mutt + neomutt". It's neomutt.

Post by Antonio Radici
I don't believe that your work is lost, all your code ends up in
Debian (and derivatives) and yes there will be patches on the top of
it.

Perhaps lost was the wrong word. The code may be mixed in, but as Mutt
project maintainer, the package has nothing to do with my work anymore.
The package you are calling "mutt" is not something I've helped create.
Your version "1.8.3+blah" is not even remotely the code I decided should
be in version "1.8.3". It's code the NeoMutt project made the decision
on. Is it that hard to understand why calling it mutt upsets me?

Looking in /usr/local/src/mutt-1.8.0/COPYRIGHT, I see a long history of
copyright assertion:

Copyright (C) 1996-2016 Michael R. Elkins <***@cs.hmc.edu>
Copyright (C) 1996-2002 Brandon Long <***@fiction.net>
Copyright (C) 1997-2009 Thomas Roessler <***@does-not-exist.org>
Copyright (C) 1998-2005 Werner Koch <***@isil.d.shuttle.de>
Copyright (C) 1999-2014 Brendan Cully <***@kublai.com>
Copyright (C) 1999-2002 Tommi Komulainen <***@iki.fi>
Copyright (C) 2000-2004 Edmund Grimley Evans <***@rano.org>
Copyright (C) 2006-2009 Rocco Rutte <***@gmx.net>
Copyright (C) 2014-2016 Kevin J. McCarthy <***@8t8.us>

and a GPL2 assertion. IME, while that permits derivative works, it does
not permit a derivative work to purport to be the copyrighted original
work. Misrepresenting the "debneomutt" work as "mutt" would seem to
clearly contravene the asserted and enforcible licence.

We pay our FOSS benefactors only in respect and correct attribution. To
fail to do so is IP theft and or misrepresentation, I contend, and is
dishonest and intolerably reprehensible. It reflects appallingly on the
debian distribution. It needs to be rectified immediately.

Erik

[Antonio Radici]

This post might be inappropriate. Click to display it.

[Ian Zimmerman]

Post by Antonio Radici
The only reason for the upstream switch was the code indenting
changes, which would have make the neomutt patch bigger than the mutt
source code, if we could get these in the main mutt source code that
I'm not saying that this is a *prerequisite* for any proposal but this
is the main reason for the upstream code switch.
Do you feel that it is possible to come up to an agreement when it
comes to the same indentation? clang-format should take care of that
pretty much automatically.

So, why can you not have a pre-configure step in debian/rules to run
clang-format and apply neomutt's indentation conventions to mutt's code?
I don't think you need upstream mutt's cooperation with that.

[Kumar Appaiah]

Post by Ian Zimmerman

Post by Antonio Radici
The only reason for the upstream switch was the code indenting
changes, which would have make the neomutt patch bigger than the mutt
source code, if we could get these in the main mutt source code that
I'm not saying that this is a *prerequisite* for any proposal but this
is the main reason for the upstream code switch.
Do you feel that it is possible to come up to an agreement when it
comes to the same indentation? clang-format should take care of that
pretty much automatically.

So, why can you not have a pre-configure step in debian/rules to run
clang-format and apply neomutt's indentation conventions to mutt's code?
I don't think you need upstream mutt's cooperation with that.

Good idea, but the patch is applied before the debian/rules commands
are executed. The method you suggest would change the code while
debian/rules runs, which is after the patches have been applied.

Kumar

[Kevin J. McCarthy]

So please submit your proposal, and I do expect something soon, but
don't expect my cooperation unless you are willing to ship something
_much_, _much_ closer to my upstream tarball.

As an update, I have filed bug 870635 in the Debian bug tracker.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870635>

[Jeremy Volkening]

I hope an amicable resolution can be worked out, but I really think
that the package should be called 'neomutt', and that the 'mutt'
package, if any, should be based on the upstream source, and should
more or less expect as people expect "mutt" to work. Or, if they want
to standardize on distributing neomutt only, at least have a package
redirection where installing "mutt" lists "neomutt" as the replacement.

I tend to agree with this. I don't know anything about it other than
what has been posted on this thread lately and don't have strong
personal feelings -- I use Debian on all my boxes including my laptop
but run neomutt from Github -- but I can sympathize with the upstream
author's point of view. I think there was a concern that moving the
Debian mutt package back closer to vanilla mutt or else changing the
name would impact existing users too greatly, but honestly it's a much
smaller deal than many of the shifts that have been made in Debian in
the past few releases and I think the suggestions from the previous
poster pretty much cover the bases.

Just my 2p.

Jeremy

[Antonio Radici]

I hope an amicable resolution can be worked out, but I really think that
the package should be called 'neomutt', and that the 'mutt' package, if
any, should be based on the upstream source, and should more or less
expect as people expect "mutt" to work. Or, if they want to standardize
on distributing neomutt only, at least have a package redirection where
installing "mutt" lists "neomutt" as the replacement.

I tend to agree with this. I don't know anything about it other than what
has been posted on this thread lately and don't have strong personal
feelings -- I use Debian on all my boxes including my laptop but run neomutt
from Github -- but I can sympathize with the upstream author's point of
view. I think there was a concern that moving the Debian mutt package back
closer to vanilla mutt or else changing the name would impact existing users
too greatly, but honestly it's a much smaller deal than many of the shifts
that have been made in Debian in the past few releases and I think the
suggestions from the previous poster pretty much cover the bases.

The reason why I haven't replied is because I was busy at work, this doesn't
mean that I forgot about this issue and it is still my top priority.

I will address this in August, I want to make clear that no new "mutt" releases
will happen in Debian until we have a solution for this problem.

The migration to neomutt under the name "mutt" predates me (it was done in a
period while I was not very active as maintainer), but I think a solution that
satisfies upstream can be found, just bear with me a couple of days/weeks
(within August anyway).

[Antonio Radici]

Post by Antonio Radici
From your statement above I understand your point clearly, I think a solution
can be found and Debian tooling provides various alternatives, I will discuss
the various options with a couple of people more expert than me on Debian
packaging and I will come back to you, this can take up to 2 weeks in the worst
case.

Have you had a chance to do this yet?

Yes, and this is why you haven't seen new releases to the Debian package
(despite we had new releases in Neomutt). This is going to be fixed in August, I
replied on the bug that you opened.

Post by Antonio Radici
* I will investigate the possible options and I will come back to both you and
Richard with one or more proposals for the future of the package in Debian.
* I know your views and I will try my best to make sure that they are
satisfied in the proposals. My understanding is that the original mutt
targz + extra feature would be OK for you as long as those features are
cleanly split in patches

Yes, this would technically satisfy the problem, but...

Post by Antonio Radici
* You let me know whether code formatting changes can be included (in one way
or another), or whether there is a future for inclusion for those changes,
this will greatly reduce the diff between the packages.

I haven't replied to this, because every time I thought about it, the
answer was "no". So it seemed a better idea to wait and see how things
went.

OK no problem, I think it's perfectly OK to say no and it's completely your call
:)

[...]

Technically, separating out the NeoMutt patches would be satisfactory,
but I would rather you make a decision which project you want to ship,
or ship two packages, not ship a bastardization.

I understand your view point and I will address it this month. We can use the
bugs on debian.org to track this at this point.

[Kevin J. McCarthy]

Post by Antonio Radici

Post by Antonio Radici
From your statement above I understand your point clearly, I think a solution
can be found and Debian tooling provides various alternatives, I will discuss
the various options with a couple of people more expert than me on Debian
packaging and I will come back to you, this can take up to 2 weeks in the worst
case.

Have you had a chance to do this yet?

Yes, and this is why you haven't seen new releases to the Debian package
(despite we had new releases in Neomutt). This is going to be fixed in August, I
replied on the bug that you opened.

Thank you for the update Antonio. I appreciate your work on resolving
this issue.

[Kevin J. McCarthy]

[Apologies if this turns out to be a dup. The email I sent yesterday
appears to have been eaten by a grue.]

Post by Kevin J. McCarthy

Post by Antonio Radici

Post by Antonio Radici
From your statement above I understand your point clearly, I think a solution
can be found and Debian tooling provides various alternatives, I will discuss
the various options with a couple of people more expert than me on Debian
packaging and I will come back to you, this can take up to 2 weeks in the worst
case.

Have you had a chance to do this yet?

Yes, and this is why you haven't seen new releases to the Debian package
(despite we had new releases in Neomutt). This is going to be fixed in August, I
replied on the bug that you opened.

Thank you for the update Antonio. I appreciate your work on resolving
this issue.

This afternoon, Antonio uploaded the mutt-1.9.1 tarball as the Debian
unstable mutt package, resolving the ticket I submitted.

I'm sure this change will not be without controversy, but I just wanted
to say thank you to Antonio for doing this.

[Michael Tatge]

Post by Kevin J. McCarthy
[Apologies if this turns out to be a dup. The email I sent yesterday
appears to have been eaten by a grue.]
This afternoon, Antonio uploaded the mutt-1.9.1 tarball as the Debian
unstable mutt package, resolving the ticket I submitted.

Seems to work. Yay.
Had to delete /etc/Muttrc.d/notmuch.rc manually though.

Michael

[Christian Brabandt]

Post by Antonio Radici
mutt source code as you release it? It was never like this even before 1.6.*,
when we had extra patches on the top of mutt, what should I do with
patches/features which are (and were) expected on the top of mutt?

That's what the mutt-patched package was for, IIRC. But there was always
the plain normal mutt package, if I remember correctly.

Unfortunately, the mutt-patched package now seems gone, otherwise, you
could make a virtual package mutt-patched that depends on the neomutt
package and which conflicts on the mutt package. However in the long
run, it would be better, if the neomutt package provided its own binary
and not call it mutt.


regards,
Christian