Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 09Jun2019 21:13, Frank Watt  wrote:
I'll look into getmail which might avoid all the roadblocks so far 
encountered.   Thanks for the suggestions.


I use getmail. I get it to deliver to a spool Maildir, and monitor that 
for new mail, which is then filtered.


Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

On 9/06/19 6:36 AM, Kurt Hackenberg wrote:

On 2019-06-07 05:08, Frank Watt wrote:


| However, fetchmail has a -m option, which can probably deliver directly
| to procmail, bypassing the local mail system entirely.

Looks like that's not as simple as I'd hoped.
I'm sort of jumping in blind here -- don't know exactly what you're 
trying to do -- but have you considered other software? Getmail is an 


The aim has changed several times since this thread's subject at which 
time, I was trying to compile a newer version of mutt so that I could 
avoid sendmail; then found out that fetchmail still required sendmail 
and wouldn't use nullmailer.  Then tried to find out about maildrop to 
replace procmail.



alternative to fetchmail; getmail can deliver to local mailboxes 
directly. And apparently there's something called fdm that does 
retrieval, filtering, and delivery.


I'll look into getmail which might avoid all the roadblocks so far 
encountered.   Thanks for the suggestions.





https://en.wikipedia.org/wiki/Fetchmail
https://en.wikipedia.org/wiki/Getmail
https://github.com/nicm/fdm

Re: Compiling a newer version than the latest .deb package

[Kurt Hackenberg]

On 2019-06-07 05:08, Frank Watt wrote:


| However, fetchmail has a -m option, which can probably deliver directly
| to procmail, bypassing the local mail system entirely.

Looks like that's not as simple as I'd hoped.
I'm sort of jumping in blind here -- don't know exactly what you're 
trying to do -- but have you considered other software? Getmail is an 
alternative to fetchmail; getmail can deliver to local mailboxes 
directly. And apparently there's something called fdm that does 
retrieval, filtering, and delivery.


https://en.wikipedia.org/wiki/Fetchmail
https://en.wikipedia.org/wiki/Getmail
https://github.com/nicm/fdm

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 08Jun2019 02:42, Kurt Hackenberg  wrote:

On 2019-06-08 00:41, Cameron Simpson wrote:
Well, the From_ isn't just a delimiter for mbox lines, it also 
historically contains the envelope address from the mail system - the 
address used for this delivery (versus whatever may be in the 
headers).


It's the envelope sender address, who SMTP said the message is from 
(possibly different from header From:).


Um, yes, brain must be on backwards today.

 Header fields are lines beginning with a field name, followed by a  
 colon (":"), followed by a field body, and terminated by CRLF.  A  
 field name MUST be composed of printable US-ASCII characters (i.e.,  
 characters that have values between 33 and 126, inclusive), except  
 colon.


Well, there's the thing about registering header names with IANA, or 
starting unregistered ones with "X-". But it's a fine point in this 
situation.


Pedantry is important. Point taken, thanks.

Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Kurt Hackenberg]

On 2019-06-08 00:41, Cameron Simpson wrote:

Well, the From_ isn't just a delimiter for mbox lines, it also 
historically contains the envelope address from the mail system - the 
address used for this delivery (versus whatever may be in the headers). 


It's the envelope sender address, who SMTP said the message is from 
(possibly different from header From:). That's redundant these days. The 
envelope sender address is also in Return-Path:. That header probably 
didn't exist when mbox was invented, in the 1970s, but it's been around 
for a long time. Oh look, Return-Path: is in RFC 822, published in 1982. 
Its syntax is a little different in RFC 2822, 2001.


  Header fields are lines beginning with a field name, followed by a 
  colon (":"), followed by a field body, and terminated by CRLF.  A 
  field name MUST be composed of printable US-ASCII characters (i.e., 
  characters that have values between 33 and 126, inclusive), except 
  colon.


Well, there's the thing about registering header names with IANA, or 
starting unregistered ones with "X-". But it's a fine point in this 
situation.

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 07Jun2019 23:22, Kurt Hackenberg  wrote:

On 2019-06-07 07:22, Cameron Simpson wrote:
If fetchmail's delivering to a programme, nothing prevents that being 
an arbitrary script to premangle a leading From_ line. Hmm.  I've got 
a script in my bin directory called "unfrom_" for exactly this 
purpose, which reads:


 #!/usr/bin/env sed -f
 #
 # Transmute leading "From " line on email message, if any.
 #    - Cameron Simpson  13jul2002
 #

 1{s/^From /From_: /}

You can just include that script in a pipeline ahead of maildrop.


Yep.

I've also seen From_ lines in maildir message files, and on the stdin 
of delivery agents. Both are wrong, in my opinion. I think mbox From_ 
lines should not exist anywhere outside mbox files.


Well, the From_ isn't just a delimiter for mbox lines, it also 
historically contains the envelope address from the mail system - the 
address used for this delivery (versus whatever may be in the headers).  
So it has some useful forensic information.


I've written a script much like yours, to drop the damn From_ line 
from an incoming message passed to a delivery agent. I think your 
script does something that's not quite right: it transforms the mbox 
From_ line to something that's not RFC 822. You could do, say,


   s/^From /X-Mbox-From: /


I'm digging through RFC 8522:

 https://tools.ietf.org/rfcmarkup/5322

which is the modern incarnation of RFC822, but it doesn't seem very 
prohibitive on header field names. Section 2.2 says:


 Header fields are lines beginning with a field name, followed by a 
 colon (":"), followed by a field body, and terminated by CRLF.  A 
 field name MUST be composed of printable US-ASCII characters (i.e., 
 characters that have values between 33 and 126, inclusive), except 
 colon.


This is confirmed in section 3.6.8:

 optional-field  =   field-name ":" unstructured CRLF
 field-name  =   1*ftext
 ftext   =   %d33-57 /  ; Printable US-ASCII
 %d59-126   ;  characters not including
;  ":".

So I think "_" is permitted :-)

Or -- my recommendation -- just drop it. (Of course, drop it only if 
that first line really is an mbox From_ line.)


I'm a hoarder and dislike discarding anything.

Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Kurt Hackenberg]

On 2019-06-07 07:22, Cameron Simpson wrote:

Are you looking in mbox files or in other places. [...] Hmm, my maildir 
message files also have From_ lines.


If fetchmail's delivering to a programme, nothing prevents that being an 
arbitrary script to premangle a leading From_ line. Hmm. I've got a 
script in my bin directory called "unfrom_" for exactly this purpose, 
which reads:


  #!/usr/bin/env sed -f
  #
  # Transmute leading "From " line on email message, if any.
  #    - Cameron Simpson  13jul2002
  #

  1{s/^From /From_: /}

You can just include that script in a pipeline ahead of maildrop.


Yep.

I've also seen From_ lines in maildir message files, and on the stdin of 
delivery agents. Both are wrong, in my opinion. I think mbox From_ lines 
should not exist anywhere outside mbox files.


I've written a script much like yours, to drop the damn From_ line from 
an incoming message passed to a delivery agent. I think your script does 
something that's not quite right: it transforms the mbox From_ line to 
something that's not RFC 822. You could do, say,


s/^From /X-Mbox-From: /

Or -- my recommendation -- just drop it. (Of course, drop it only if 
that first line really is an mbox From_ line.)

Re: Compiling a newer version than the latest .deb package

[Kurt Hackenberg]

On 2019-06-07 05:08, Frank Watt wrote:


When I look at the headers of most mail, I see an mbox-style From
line. Where do we make use of the 'reformat -f0' and "Return-Path"
advice?


In the stream of data that ends up on the standard input of the delivery 
agent (procmail, maildrop, whatever).


If fetchmail -m works the same as an MTA directed by .forward to hand 
over a message to a delivery agent, then fetchmail sets up a pipe from 
itself to the delivery agent, so the delivery agent reads a single 
message on its standard input. Some MTAs precede the message with an 
mbox-style From_ line; some don't. Fetchmail may or may not add a From_ 
line.


You can find out by having fetchmail hand the message to a script that 
you write, which both saves a copy of its stdin and passes it on to a 
delivery agent. The script would be something like this:


#!/bin/sh

tee -a $HOME/fetchmail.test | maildrop

Re: Compiling a newer version than the latest .deb package

[Patrick Shanahan]

* Cameron Simpson  [06-07-19 19:43]:
> On 07Jun2019 07:37, Patrick Shanahan  wrote:
> > * Cameron Simpson  [06-07-19 07:24]:
> > > It does look that way. I left procmail because I disliked its rule
> > > syntax,
> > > its totally regexp based matching system (ok for subject lines, ghastly 
> > > for
> > > email addresses) and the performance cost incurred by it rereading the
> > > filter files from scratch on every message processed. I've got about 2000
> > > filing rules myself - procmail starts to scale badly for that.
> > 
> > 
> > adjust the order of your rules so that the most likely matchs appear at
> > the top of the rc file
> > 
> 
> I'm aware of that technique. I expect to multifile my email; almost all my
> rules are not match-and-stop, they're match-and-continue. I do have some
> critical match-and-stop rules at the front, but they are few.
> 
> As an example, an email to me personally and also CCed to a list needs to
> land in my inbox (because it is for my attention) but also in the mailing
> list folder (for archiving and general well filedness). So, match and
> continue.

and I abhor receiving duplicate mail.  I read a list and communicate there
and notice email there.  personal mail goes to my inbox, list mail is not
personal and list communication should normally be conducted there.  be we
all have different expectations and utilize linux to achieve them.  :)

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 07Jun2019 07:37, Patrick Shanahan  wrote:

* Cameron Simpson  [06-07-19 07:24]:
It does look that way. I left procmail because I disliked its rule 
syntax,

its totally regexp based matching system (ok for subject lines, ghastly for
email addresses) and the performance cost incurred by it rereading the
filter files from scratch on every message processed. I've got about 2000
filing rules myself - procmail starts to scale badly for that.



adjust the order of your rules so that the most likely matchs appear at
the top of the rc file



I'm aware of that technique. I expect to multifile my email; almost all 
my rules are not match-and-stop, they're match-and-continue. I do have 
some critical match-and-stop rules at the front, but they are few.


As an example, an email to me personally and also CCed to a list needs 
to land in my inbox (because it is for my attention) but also in the 
mailing list folder (for archiving and general well filedness). So, 
match and continue.


Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Patrick Shanahan]

* Patrick Shanahan  [06-07-19 07:38]:
> * Cameron Simpson  [06-07-19 07:24]:
>  [...]
> > How's fetchmail run by your system? Cron? Something else?
> 
> not that fetchmail has a daemon, "fetchmail -d 150" runs every 150
> seconds.

s/not/note
 

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Re: Compiling a newer version than the latest .deb package

[Patrick Shanahan]

* Cameron Simpson  [06-07-19 07:24]:
 [...]
> How's fetchmail run by your system? Cron? Something else?

not that fetchmail has a daemon, "fetchmail -d 150" runs every 150
seconds.

 [...] 
> It does look that way. I left procmail because I disliked its rule syntax,
> its totally regexp based matching system (ok for subject lines, ghastly for
> email addresses) and the performance cost incurred by it rereading the
> filter files from scratch on every message processed. I've got about 2000
> filing rules myself - procmail starts to scale badly for that.

 
adjust the order of your rules so that the most likely matchs appear at
the top of the rc file
 

 {...] 
> That said, many people use procmail with little apparent pain.

for many years.  :)
 

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Registered Linux User #207535@ http://linuxcounter.net
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 07Jun2019 21:08, Frank Watt  wrote:

First of all, apologies for munging the thread: Gmail didn't deliver
Cameron's response.  I had to get the text from the archives.


That seems to happen to me quite a bit. I harbour some suspicions to do 
with years of maintaining the adzapper project (which is filled with 
spamlike domain strings). Please see if I'm in your spam folder; marking 
my messages as not spam might improve future delivery.



Cameron Simpson wrote:
| Procmail generally relies on being installed in the user's ~/.forward
| file to cause sendmail (the mail system) to deliver email to the
| procmail programme instead of the default.

I don't have a ~/.forward: I have a ~/.fetchmailrc and a ~/.procmail
file, the former having this statement in its first line:

# Configuration created Fri Dec 13 22:30:42 2002 by fetchmailconf

I don't recall doing that, but I edited that file a number of times
since 2002.


Ok, so fetchmail collects your email and hands it to procmail? I'd have 
thought that should continue to work regardless of what you've done with 
the system MTA (sendmail/nullmailer/whatever).


How's fetchmail run by your system? Cron? Something else?


| fetchmail collects email and delivered it to the local email system.
| Which means it delivers to sendmail. And sendmail hands it to
| procmail...
|
| However, fetchmail has a -m option, which can probably deliver directly
| to procmail, bypassing the local mail system entirely.

Looks like that's not as simple as I'd hoped.  From the fetchmail man
page:
  -m  | --mda 
 This option lets fetchmail use a Message or Local
 Delivery Agent (MDA or LDA) directly, rather than
 forward via SMTP or LMTP.

 To avoid losing mail, use this option only with MDAs
 like maildrop or MTAs like sendmail that exit with a
 nonzero status on disk-full and other delivery errors;

[...]

 The well-known procmail(1) package is very hard to
 configure properly, it has a very nasty "fall through to
 the next rule" behavior on delivery errors (even
 temporary ones, such as out of disk space if another
 user's mail daemon copies the mailbox around to purge
 old messages), so your mail will end up in the wrong
 mailbox sooner or later. The proper procmail
 configuration is outside the scope of this
 document. Using maildrop(1) is usually much easier, and
 many users find the filter syntax used by mail‐ drop
 easier to understand.

That seems to be a big incentive not to use procmail.


It does look that way. I left procmail because I disliked its rule 
syntax, its totally regexp based matching system (ok for subject lines, 
ghastly for email addresses) and the performance cost incurred by it 
rereading the filter files from scratch on every message processed. I've 
got about 2000 filing rules myself - procmail starts to scale badly for 
that.


Is your procmailrc extensive? Would it be hard to switch filers?

That said, many people use procmail with little apparent pain.


Meanwhile, in
the man pages for maildrop:

DESCRIPTION

[...]

  maildrop does not accept an mbox-style From_ line before the
  first header line.  maildrop does not accept leading empty
  lines before the first non-blank header line. If the message
  can possibly start with empty lines, and a From_ line, use
  reformail -f0 to remove any initial empty lines, and replace a
  From_ line with a proper “Return-Path:” header; then pipe it to
  maildrop.

When I look at the headers of most mail, I see an mbox-style From
line. Where do we make use of the 'reformat -f0' and "Return-Path"
advice?


Are you looking in mbox files or in other places. [...] Hmm, my maildir 
message files also have From_ lines.


If fetchmail's delivering to a programme, nothing prevents that being an 
arbitrary script to premangle a leading From_ line. Hmm. I've got a 
script in my bin directory called "unfrom_" for exactly this purpose, 
which reads:


 #!/usr/bin/env sed -f
 #
 # Transmute leading "From " line on email message, if any.
 #- Cameron Simpson  13jul2002
 #

 1{s/^From /From_: /}

You can just include that script in a pipeline ahead of maildrop.

Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

First of all, apologies for munging the thread: Gmail didn't deliver
Cameron's response.  I had to get the text from the archives.

Cameron Simpson wrote:

[...]


| Procmail generally relies on being installed in the user's ~/.forward
| file to cause sendmail (the mail system) to deliver email to the
| procmail programme instead of the default.

I don't have a ~/.forward: I have a ~/.fetchmailrc and a ~/.procmail
file, the former having this statement in its first line:

# Configuration created Fri Dec 13 22:30:42 2002 by fetchmailconf

I don't recall doing that, but I edited that file a number of times
since 2002.


|
| So...
|
| fetchmail collects email and delivered it to the local email system.
| Which means it delivers to sendmail. And sendmail hands it to
| procmail...
|
| However, fetchmail has a -m option, which can probably deliver directly
| to procmail, bypassing the local mail system entirely.

Looks like that's not as simple as I'd hoped.  From the fetchmail man
page:
   -m  | --mda 
  (Keyword: mda)

  This option lets fetchmail use a Message or Local
  Delivery Agent (MDA or LDA) directly, rather than
  forward via SMTP or LMTP.

  To avoid losing mail, use this option only with MDAs
  like maildrop or MTAs like sendmail that exit with a
  nonzero status on disk-full and other delivery errors;
  the nonzero status tells fetchmail that deliv‐ ery
  failed and prevents the message from being deleted on
  the server.

[...]

  The well-known procmail(1) package is very hard to
  configure properly, it has a very nasty "fall through to
  the next rule" behavior on delivery errors (even
  temporary ones, such as out of disk space if another
  user's mail daemon copies the mailbox around to purge
  old messages), so your mail will end up in the wrong
  mailbox sooner or later. The proper procmail
  configuration is outside the scope of this
  document. Using maildrop(1) is usually much easier, and
  many users find the filter syntax used by mail‐ drop
  easier to understand.

That seems to be a big incentive not to use procmail. Meanwhile, in
the man pages for maildrop:

DESCRIPTION

[...]

   maildrop does not accept an mbox-style From_ line before the
   first header line.  maildrop does not accept leading empty
   lines before the first non-blank header line. If the message
   can possibly start with empty lines, and a From_ line, use
   reformail -f0 to remove any initial empty lines, and replace a
   From_ line with a proper “Return-Path:” header; then pipe it to
   maildrop.

When I look at the headers of most mail, I see an mbox-style From
line. Where do we make use of the 'reformat -f0' and "Return-Path"
advice?

TIA

Frank

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 06.06.19 18:59, Cameron Simpson wrote:
> But nullmailer really sounds very promising - it has a queue and delivers to
> a smarthost, which is all most people really need on their personal
> machines.

That's about the size of it. But if a traditional mail set-up is valued,
it's only one config command for postfix:

# postconf -ev relayhost=[yourmailhost.your.isp.domain]

The [] are needed.

Update running instance:

# postfix reload

Erik

-- 
Habit is habit, and not to be flung out of the window by any man, but
coaxed down-stairs a step at a time.
  - Mark Twain, "Pudd'nhead Wilson's Calendar

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 06.06.19 20:47, Frank Watt wrote:
> I thought fetchmail had nothing to do with sendmail, but that evidently
> isn't the case.  I installed nullmailer and fetchmail ceased to work.

» DESCRIPTION
 fetchmail  is  a  mail-retrieval  and  forwarding  utility;  it fetches
 mail from remote mailservers and forwards it to your local (client)
 machine's  delivery  system. «

» As each message is retrieved, fetchmail normally delivers it via SMTP
to port 25 on the machine it is running on (localhost), just as though
it were being passed in over a normal TCP/IP link. «

Here, that was sendmail 15 years ago, now postfix. AIUI, mutt can fetch
mail itself, but then where would the procmail filter go? And what would
you do for outgoing mail? (Maybe mutt can go direct in that direction too
- I haven't looked.)

> Does procmail use sendmail?

It's the other way round, going by invocation.

» procmail - autonomous mail processor
Procmail  can  also  be  used as a general purpose mail filter, i.e.,
provisions have been made to enable procmail to be invoked in a special
sendmail rule. «

For the postfix equivalent, I have run this configuration command:

# postconf -ev mailbox_command='/usr/bin/procmail -t -a $EXTENSION'

Hmmm, did I substitute $EXTENSION at that time? Let's look:

$ /usr/sbin/postconf -n | grep mailbox_command
mailbox_command = /usr/bin/procmail -t -a $EXTENSION

Nope, works as is.

So the mail path is: fetchmail -> postfix/sendmail -> procmail -> mailbox
  later: mutt <- mailbox

For a single user, that is perhaps overweight, but if that's what one is
used to setting up, then it's no bother.

Erik

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 06Jun2019 20:47, Frank Watt  wrote:

On 5/06/19 10:37 PM, Nathan Stratton Treadway wrote:

On Wed, Jun 05, 2019 at 21:30:51 +1200, Frank Watt wrote:

Would that really work?  It's an attractive idea, avoiding the
complications of compiling new code with ancient functionality and
getting rid of sendmail's idiosynchracies. Is there any reason not to
try?


Well, the first question is "how does your incoming email get
delivered"?  If it's delivered locally to the machine where you are
running Mutt, you will need to be sure that sendmail is not involved in
delivering it (because nullmailer is specifically designed not to
support delivering mail to local mailboxes).


I thought fetchmail had nothing to do with sendmail, but that 
evidently isn't the case.  I installed nullmailer and fetchmail ceased 
to work. Does procmail use sendmail?


Procmail generally relies on being installed in the user's ~/.forward 
file to cause sendmail (the mail system) to deliver email to the 
procmail programme instead of the default.


So...

fetchmail collects email and delivered it to the local email system.  
Which means it delivers to sendmail. And sendmail hands it to 
procmail...


However, fetchmail has a -m option, which can probably deliver directly 
to procmail, bypassing the local mail system entirely.


At least it was simple to get back to where I was by reinstalling 
sendmail.  So sendmail still works where it used to with fetchmail, 
but not where it used to work with my ISP's SMTP server :-(


Fiddle fetchmail to deliver to procmail. When that's working, put 
nullmailer back.


I didn't get Nullmailer to send any mail.  That might be because I 
screwed up the configuration.  There's not much point figuring that 
out if I can't use fetchmail.


Yah, debug it second.

Should I go back to getting qmail (or something else) to replace 
sendmail?


Qmail is extremely simple, so much so that I find it hard to set up. I 
personally like postfix.


But nullmailer really sounds very promising - it has a queue and 
delivers to a smarthost, which is all most people really need on their 
personal machines.


Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

Thanks, Nathan,

On 5/06/19 10:37 PM, Nathan Stratton Treadway wrote:

On Wed, Jun 05, 2019 at 21:30:51 +1200, Frank Watt wrote:


[...]



Would that really work?  It's an attractive idea, avoiding the
complications of compiling new code with ancient functionality and
getting rid of sendmail's idiosynchracies. Is there any reason not to
try?


Well, the first question is "how does your incoming email get
delivered"?  If it's delivered locally to the machine where you are
running Mutt, you will need to be sure that sendmail is not involved in
delivering it (because nullmailer is specifically designed not to
support delivering mail to local mailboxes).


I thought fetchmail had nothing to do with sendmail, but that evidently 
isn't the case.  I installed nullmailer and fetchmail ceased to work. 
Does procmail use sendmail?


At least it was simple to get back to where I was by reinstalling 
sendmail.  So sendmail still works where it used to with fetchmail, but 
not where it used to work with my ISP's SMTP server :-(


I didn't get Nullmailer to send any mail.  That might be because I 
screwed up the configuration.  There's not much point figuring that out 
if I can't use fetchmail.




On the other hand, if you do only need "/usr/sbin/sendmail" for sending
outgoing messages, then yes, Nullmailer is very likely to work as a
replacement for Sendmail.

(With the caveat that whether Nullmailer can actually work around your
current problem does depend on what exactly is going wrong with your
current configuration...).


Well, that's still  very much a yet to be sorted out issue.

Should I go back to getting qmail (or something else) to replace sendmail?

Thank you all for your various helpful information.


Frank

Re: Compiling a newer version than the latest .deb package

[Nathan Stratton Treadway]

On Wed, Jun 05, 2019 at 21:30:51 +1200, Frank Watt wrote:
> I wasn't clear.  I'm quite content with an old mutt, but I've come to
> the end of the line with sendmail (which I can't get to work, though
> it used to work).

Ah!  In that case, definitely don't try recompiling anything :)
 
> What I'm thinking of doing is remove the old mutt package; install
> nullmailer (which process deletes sendmail (not sorry to see that go);
> then reinstall the 9-year old mutt package.  I'd assume I'd have to
> make some edits to Muttrc &/or ~/.mutt.rc to specify my ISP's SMTP
> server.  The man muttrc is dated 2002!!

You don't need to uninstall mutt --  the nullmailer package should
simply replace the sendmailer package.  Most likely you would only need
to configure nullmailer (and not make any changes to the mutt config);
mutt will still call /usr/sbin/sendmail as it does now, but that program
will be Nullmailer rather than Sendmail.

(Also, by default the sendmail package will be removed rather than
purged, so your existing configuration files will be left installed, and
you could go back if you decided to for some reason.)

> Would that really work?  It's an attractive idea, avoiding the
> complications of compiling new code with ancient functionality and
> getting rid of sendmail's idiosynchracies. Is there any reason not to
> try?

Well, the first question is "how does your incoming email get
delivered"?  If it's delivered locally to the machine where you are
running Mutt, you will need to be sure that sendmail is not involved in
delivering it (because nullmailer is specifically designed not to
support delivering mail to local mailboxes).

On the other hand, if you do only need "/usr/sbin/sendmail" for sending
outgoing messages, then yes, Nullmailer is very likely to work as a
replacement for Sendmail.

(With the caveat that whether Nullmailer can actually work around your
current problem does depend on what exactly is going wrong with your
current configuration...).

Nathan

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 05Jun2019 19:56, Erik Christiansen  wrote:

On 05.06.19 21:30, Frank Watt wrote:

I wasn't clear.  I'm quite content with an old mutt, but I've come to
the end of the line with sendmail (which I can't get to work, though
it used to work).


I'm impressed. When I finally switched to postfix around 15 years ago, I
thought I might be one of the last sendmail users. (The vulnerabilities
reported back then were sufficient motive, despite many years of happy
sendmail use.) Postfix has a sendmail compatibility interface, and so I
administer it rather like sendmail, after set-up with postfix config.


Yeah, I'm a postfix person too. It is a lot more approachable. I tend to 
put all my local settings at the top of /etc/postfix/main.cf and you're 
basicly there.


That said, nullmailer looks like a great idea. This URL looks quite 
encouraging:


 http://troubleshooters.com/linux/nullmailer/

As you say, provided your mutt's already configured to send with the 
sendmail command, it will just work. (Though this is true with most UNIX 
mail systems - they all provide a sendmail executable for mail 
submission.)


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)

You want to tempt the wrath of the whatever from high atop the thing?
- Toby Zeigler, _The_West_Wing_ - Election Night

Re: Compiling a newer version than the latest .deb package

[Erik Christiansen]

On 05.06.19 21:30, Frank Watt wrote:
> I wasn't clear.  I'm quite content with an old mutt, but I've come to
> the end of the line with sendmail (which I can't get to work, though
> it used to work).

I'm impressed. When I finally switched to postfix around 15 years ago, I
thought I might be one of the last sendmail users. (The vulnerabilities
reported back then were sufficient motive, despite many years of happy
sendmail use.) Postfix has a sendmail compatibility interface, and so I
administer it rather like sendmail, after set-up with postfix config. It
was pretty easy to get going. OK, like a number of others on the list, I
find fetchmail fine for pulling mail in from the ISP, and procmail for
collating it in a number of delivery mailboxes.

Can't advise on the other stuff, though.

Erik
(Who is also too content with an old mutt version to stop and update.)

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

Christian Brabant wrote:

| On Di, 04 Jun 2019, Frank Watt wrote:
|
[.]

|

| > Were I to install nullmailer, it would remove sendmail, but is
| > that any use with a 9 year old mutt?  I find everything I need in
| > it.  Would it work to reinstall the old mutt deb after replacing
| > sendmail with nullmailer?  I get the impression that the deb
| > configures the installation to use the mta present at the time.
|
| Yes, because it listens on your port 25, which can of course be only
| one single pakage. Therefore the different MTAs conflict each
| other. If you are satisifed with sendmail and it does everything you
| need, I wouldn't change it.

I wasn't clear.  I'm quite content with an old mutt, but I've come to
the end of the line with sendmail (which I can't get to work, though
it used to work).

What I'm thinking of doing is remove the old mutt package; install
nullmailer (which process deletes sendmail (not sorry to see that go);
then reinstall the 9-year old mutt package.  I'd assume I'd have to
make some edits to Muttrc &/or ~/.mutt.rc to specify my ISP's SMTP
server.  The man muttrc is dated 2002!!

Would that really work?  It's an attractive idea, avoiding the
complications of compiling new code with ancient functionality and
getting rid of sendmail's idiosynchracies. Is there any reason not to
try?

| regards,
| Christian
| --
| Those who don't understand Linux are doomed to reinvent it, poorly.
|   -- unidentified source

It's hard work inventing that has been done by much more talented folk
already. :-(

Frank

Re: Compiling a newer version than the latest .deb package

[Christian Brabandt]

On Di, 04 Jun 2019, Frank Watt wrote:

> 
> 
> On 4/06/19 1:24 AM, Dan Ritter wrote:
> > Frank Watt wrote:
> > > 
> > > |You seem to be on x86_64 (or amd64 as debian calls it), so unless
> > > |you are building as 32-bit you don't need any of these.
> > > |
> > > |The -dev versions include headers, so you need those to compile, the
> > > |more-basic versions are only the libraries (for packages provided by
> > > |debian). And 'ncurses5' is the old version for ASCII or ISO-8859-N
> > > |versions - these days, 'ncurses5w' is probably what you need
> > 
> > 
> > 95% of your problems here will go away with:
> > 
> > sudo apt build-dep mutt
> > 
> > which will fetch and install all the libraries and tools
> > necessary to build Debian's current version of mutt.
> 
> # sudo apt build-dep mutt
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to find a source package for mutt
> Tui mutt-1.12.0 # which mutt
> /usr/bin/mutt
> Tui mutt-1.12.0 # dpkg -S /usr/bin/mutt
> dpkg-query: no path found matching pattern /usr/bin/mutt

You need deb-src urls in your /etc/apt/sources.list. 

> What am I to infer from that?  Could that be because I'm not a Debian purist
> since I use Linux Mint?

Yes, very likely.

> Were I to install nullmailer, it would remove sendmail, but is that any use
> with a 9 year old mutt?  I find everything I need in it.  Would it work to
> reinstall the old mutt deb after replacing sendmail with nullmailer?  I get
> the impression that the deb configures the installation to use the mta
> present at the time.

Yes, because it listens on your port 25, which can of course be only one 
single pakage. Therefore the different MTAs conflict each other. If you 
are satisifed with sendmail and it does everything you need, I wouldn't 
change it.

regards,
Christian
-- 
Those who don't understand Linux are doomed to reinvent it, poorly.
-- unidentified source

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

On 4/06/19 1:24 AM, Dan Ritter wrote:

Frank Watt wrote:


|You seem to be on x86_64 (or amd64 as debian calls it), so unless
|you are building as 32-bit you don't need any of these.
|
|The -dev versions include headers, so you need those to compile, the
|more-basic versions are only the libraries (for packages provided by
|debian). And 'ncurses5' is the old version for ASCII or ISO-8859-N
|versions - these days, 'ncurses5w' is probably what you need



95% of your problems here will go away with:

sudo apt build-dep mutt

which will fetch and install all the libraries and tools
necessary to build Debian's current version of mutt.


# sudo apt build-dep mutt
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for mutt
Tui mutt-1.12.0 # which mutt
/usr/bin/mutt
Tui mutt-1.12.0 # dpkg -S /usr/bin/mutt
dpkg-query: no path found matching pattern /usr/bin/mutt

and:
> apt build-dep thunderbird
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to find a source package for thunderbird

but:
> which thunderbird
/usr/bin/thunderbird
> dpkg -S /usr/bin/thunderbird
thunderbird: /usr/bin/thunderbird

What am I to infer from that?  Could that be because I'm not a Debian 
purist since I use Linux Mint?






However!

All of this may be unneeded, as Debian stable's mutt (which
is neomutt right now, yes) has


I'm not familiar with neomutt.




set smtp_url = "smtp://user@smtp.domain:25"
set smtp_pass="pass"
set from="user@domain"
set realname="username"

SMTP support.

However again!

Installing nullmailer will give you a sendmail substitute that only takes
one line of config to do its job: send all mail to some other SMTP server.


Were I to install nullmailer, it would remove sendmail, but is that any 
use with a 9 year old mutt?  I find everything I need in it.  Would it 
work to reinstall the old mutt deb after replacing sendmail with 
nullmailer?  I get the impression that the deb configures the 
installation to use the mta present at the time.


Could it be as easy as that?
Thanks for all the suggestions I'm yet to try.

Frank

Re: Compiling a newer version than the latest .deb package

[Nathan Stratton Treadway]

On Mon, Jun 03, 2019 at 06:50:15 -0700, Kevin J. McCarthy wrote:
> On Mon, Jun 03, 2019 at 12:24:33PM +1200, Frank Watt wrote:
> >configure: error: no curses library found
> 
> I think Ken and Cameron covered the bases.  However, on Debian based 
> systems another good thing to run is
>   apt-get build-dep mutt
> It's not foolproof because of the version disparity and possible 
> configuration differences, but it should get you most of the expected 
> dependencies.

Yes, exacly, I was also going mention that the maintainer(s) of the
existing Debian package already tracked down all these dependencies when
the package was built, and you might as well take advantage of all that
work

Kevin's command will install the build dependecies for the Mutt source
package from your current release.  If you want to look more closely at
what Build dependencies have been added (or updated) between that
version and the latest Mutt packages (on the theory that the build
dependencies for the 1.10 package will be closer to what you need now
than the dependencies listed for the 1.5.23 package), you could:

* track through them "manually" by starting at
https://packages.debian.org/source/jessie/mutt
  and then clicking on the different release names in the page header
  to see the build depenciences of later Mutt packages, or

* follow the "control" links from the Versioned Links section of the
  Package Tracker page to look at the original Build-Depends: lines
  directly.

  (So that would take you to:
https://tracker.debian.org/media/packages/m/mutt/control-1.5.23-3
  and
https://tracker.debian.org/media/packages/m/mutt/control-1.10.1-2.1
  )


Another hint is that although you might need to change things a bit to
get the new version to compile in your environment, you probably want to
configure your build as closely as you can to the official builds, so
that your newly-build version is compatible with your current mail setup
and so you can easily upgrade to a future official Debian version at
some later date.

So, it's probably worth your while following the "rules" links from the
Versioned Links section and then searching for a common configure
options (e.g. "--enable-compressed") to find the all the arguments
passed to "./configure" in both your current version (i.e.
  https://tracker.debian.org/media/packages/m/mutt/rules-1.5.23-3
) and the latest package (i.e.
  https://tracker.debian.org/media/packages/m/mutt/rules-1.10.1-2.1
).

Where the two differ you'll have to do a little research to figure out
which one you should use in our own build, but basing your build off
those is still probably a lot easier than starting from scratch...


Nathan

Re: Compiling a newer version than the latest .deb package

[Nathan Stratton Treadway]

On Sun, Jun 02, 2019 at 21:51:25 +1200, Frank Watt wrote:
> On 2/06/19 9:07 PM, Jens John wrote:> On Sun, 2 Jun 2019, at 05:36, 
> > (Why not just upgrade your Debian or Ubuntu release?)
>
> There's nothing newer I can find:
> https://sources.debian.org/patches/mutt/1.5.23-3/
> 

A better search for checking "what's available in later Debian
releases?" would be:

  https://packages.debian.org/search?keywords=mutt

(or you can just type in the URL "packages.debian.org/mutt" for short.)

>From that search you will see that Debian packages for Mutt v1.10.1 are
available in Buster (and Sid).  So you would get a newer version of Mutt
if you upgraded to Buster (though still not 1.12).



(If you go up a directory and look at
  https://sources.debian.org/patches/mutt/
, you will find the patches included in later package versions as well  
as the 1.5.23-3 patches you were looking at.

But probably a better page to be looking at is the Debian Package
Tracker page, which shows various sorts of developer info rather than
only "patches":
  https://tracker.debian.org/pkg/mutt

Nathan

Re: Compiling a newer version than the latest .deb package

[Kevin J. McCarthy]

On Mon, Jun 03, 2019 at 12:24:33PM +1200, Frank Watt wrote:

configure: error: no curses library found


I think Ken and Cameron covered the bases.  However, on Debian based 
systems another good thing to run is

  apt-get build-dep mutt
It's not foolproof because of the version disparity and possible 
configuration differences, but it should get you most of the expected 
dependencies.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Compiling a newer version than the latest .deb package

[Cameron Simpson]

On 03Jun2019 21:04, Frank Watt  wrote:

Despite the confusing name,
aptitude install lib64ncurses5-dev:i386

got past the curses error message.  But then I got this:

checking tcbdb.h usability... no
checking tcbdb.h presence... no
checking for tcbdb.h... no
checking villa.h usability... no
checking villa.h presence... no
checking for villa.h... no
checking for vlopen in -lqdbm... no
checking for gdbm_open... no
checking for BerkeleyDB > 4.0... no
checking for mdb_env_create... no
checking kclangc.h usability... no
checking kclangc.h presence... no
checking for kclangc.h... no
configure: error: You need Tokyo Cabinet, Kyoto Cabinet, QDBM, GDBM, 
LMDB or Berkeley DB4 for hcache


So I tried pasting that message into duckduckgo which came up first
with https://thomer.com/howtos/mutt_on_mac.html

The end of that page finishes:

The key to making the configure errors go away is including CPPFLAGS
and LDFLAGS on the command line when configuring mutt.

$ CPPFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib/ ./configure ...

I'd never thought of Mac users using mutt,


Oh, you cut me!


but is there any way I
could use that suggestion?  I've had limited experience compiling
source code but there are others much simpler to do than this one.
Maybe it's tricky even for Debian geeks and that's why the .deb files
are so old.


That suggestion, out of the box, will not directly help you.

What it does is tell the configure script to reach into /opt/local for C 
headers and  libraries. On a Mac there are a few third party package 
systems available (Fink, Homebrew and Macports), and Macports installs 
packages in /opt/local, thus the path in the suggestion.


However, your Debian system should have access to almost all the 
software you should need for a nice mutt build, you just have to fetch 
it. Let's look...


My closest Debian like system is our home server, which is running 
Ubuntu 16.04. So:


 [~]borg*> apt-cache search gdbm|grep dev
 libgdbm-dev - GNU dbm database routines (development files)
 libtdb-dev - Trivial Database - development files
 libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development]
 libntdb-dev - New Trivial Database - development files

Try this on your system. [...] Here's the output from a Debian 8.8 
system:


 libdbm-ocaml-dev - binding to the NDBM/GDBM Unix databases (development files)
 libgdbm-dev - GNU dbm database routines (development files)
 libntdb-dev - New Trivial Database - development files
 libtdb-dev - Trivial Database - development files
 libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development]

So to get GDBM:

 apt-get install libgdbm-dev

You could also get libtokyocabinet-dev it seems.

Have another review of the things configure says are not available and 
do some "apt-cache search" commands for their names, further grepping 
for dev to get the development files packages.


And you won't need to the CLFAGS= stuff because these packages will 
install stuff in the standard places.


Cheers,
Cameron Simpson 

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

Ken Moffat wrote:

|Hi Frank,
|
| I assume you probably won't get this mail (gmail dislikes my mails
|from this address), but just in case ...
|

At least it got to the archives.


|[...]
|> p   lib32ncurses5 - shared libraries for
|> terminal handling (32-bit)
|> p   lib32ncurses5-dev - developer's libraries
|> for ncurses (32-bit)
|> p   lib32ncursesw5- shared libraries for
|> terminal handling (wide character
|> p   lib32ncursesw5-dev- developer's libraries
|> for ncursesw (32-bit)
|> p   lib64ncurses5:i386- shared libraries for
|
|You seem to be on x86_64 (or amd64 as debian calls it), so unless
|you are building as 32-bit you don't need any of these.
|
|The -dev versions include headers, so you need those to compile, the
|more-basic versions are only the libraries (for packages provided by
|debian). And 'ncurses5' is the old version for ASCII or ISO-8859-N
|versions - these days, 'ncurses5w' is probably what you need
|(it supports unicode).  So:
|
|> terminal handling (64-bit)
|> p   lib64ncurses5-dev:i386- developer's libraries
|> for ncurses (64-bit)
|
|?i386?  Maybe some weird naming convention in debian.  That is
|probably the right *old* (non-wide) 64-bit version.
|
|But I don't see any lib64ncursesw5 (wide 64-bit) version in what you
|listed, and I imagine that is what you need for 64-bit builds with
|unicode.

Despite the confusing name,
aptitude install lib64ncurses5-dev:i386

got past the curses error message.  But then I got this:

checking tcbdb.h usability... no
checking tcbdb.h presence... no
checking for tcbdb.h... no
checking villa.h usability... no
checking villa.h presence... no
checking for villa.h... no
checking for vlopen in -lqdbm... no
checking for gdbm_open... no
checking for BerkeleyDB > 4.0... no
checking for mdb_env_create... no
checking kclangc.h usability... no
checking kclangc.h presence... no
checking for kclangc.h... no
configure: error: You need Tokyo Cabinet, Kyoto Cabinet, QDBM, GDBM, 
LMDB or Berkeley DB4 for hcache


So I tried pasting that message into duckduckgo which came up first
with https://thomer.com/howtos/mutt_on_mac.html

The end of that page finishes:

 The key to making the configure errors go away is including CPPFLAGS
 and LDFLAGS on the command line when configuring mutt.

$ CPPFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib/ ./configure ...

I'd never thought of Mac users using mutt, but is there any way I
could use that suggestion?  I've had limited experience compiling
source code but there are others much simpler to do than this one.
Maybe it's tricky even for Debian geeks and that's why the .deb files
are so old.

|And at the risk of trying to teach my granny to such eggs, the
|following glyphs (variants of 'a' with diacritical) should be in
|unicode, so if you can read these then you _do_ need wide ncurses:
|áâà ąă

I don't know how to use these, but it looks like I can read them.

Thank you Ken for getting me this far.

Cheers
Frank

Re: Compiling a newer version than the latest .deb package

[Ken Moffat]

On Mon, Jun 03, 2019 at 12:24:33PM +1200, Frank Watt wrote:
> 
> I had to leave out gpgme, but I had a problem with
> 
> configure: error: no curses library found
> 
Hi Frank,

 I assume you probably won't get this mail (gmail dislikes my mails
from this address), but just in case ...

> There are many packages available with 'curses' in the name, some of them
> are installed, but I don't know if any of them would be the issue. It's a
> bit long to experiment with.
> 
> (The list doesn't display well in Thunderbird, but with any luck, someone
> will be able to spot which I'm missing)
> 
[...]
> p   lib32ncurses5 - shared libraries for
> terminal handling (32-bit)
> p   lib32ncurses5-dev - developer's libraries
> for ncurses (32-bit)
> p   lib32ncursesw5- shared libraries for
> terminal handling (wide character
> p   lib32ncursesw5-dev- developer's libraries
> for ncursesw (32-bit)
> p   lib64ncurses5:i386- shared libraries for

You seem to be on x86_64 (or amd64 as debian calls it), so unless
you are building as 32-bit you don't need any of these.

The -dev versions include headers, so you need those to compile, the
more-basic versions are only the libraries (for packages provided by
debian). And 'ncurses5' is the old version for ASCII or ISO-8859-N
versions - these days, 'ncurses5w' is probably what you need
(it supports unicode).  So:

> terminal handling (64-bit)
> p   lib64ncurses5-dev:i386- developer's libraries
> for ncurses (64-bit)

?i386?  Maybe some weird naming convention in debian.  That is
probably the right *old* (non-wide) 64-bit version.

But I don't see any lib64ncursesw5 (wide 64-bit) version in what you
listed, and I imagine that is what you need for 64-bit builds with
unicode.

And at the risk of trying to teach my granny to such eggs, the
following glyphs (variants of 'a' with diacritical) should be in
unicode, so if you can read these then you _do_ need wide ncurses:
áâàąă

BTW - the x32 versions are an uncommon requirement (64-bit, but with
small but with only 32-bit pointers for smaller builds, not commonly
used on desktop builds).
https://en.wikipedia.org/wiki/X32_ABI

ĸen
> 
> Thanks for any suggestions.
> 
> Frank

-- 
Before the universe began, there was a sound. It went: "One, two, ONE,
two, three, four" [...] The cataclysmic power chord that followed was
the creation of time and space and matter and it does Not Fade Away.
 - wiki.lspace.org/mediawiki/Music_With_Rocks_In

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

On 3/06/19 2:00 AM, Kevin J. McCarthy wrote:
[...]


Lastly, the latest mutt releases have started to bump up system 
requirements:

  * If your gpgme library is too old and you don't use gpgme,
    you can just leave '--enable-gpgme' out.
  * If your OpenSSL version is too old, you could try '--with-gnutls'
    instead of '--with-ssl'
  * An old system likely does not come with idn2, so you would
    want to use '--with-idn' instead.



I had to leave out gpgme, but I had a problem with

configure: error: no curses library found

There are many packages available with 'curses' in the name, some of 
them are installed, but I don't know if any of them would be the issue. 
It's a bit long to experiment with.


(The list doesn't display well in Thunderbird, but with any luck, 
someone will be able to spot which I'm missing)




p   ekg2-ui-ncurses   - instant messenger 
and IRC client for UNIX systems - ncu
p   ekg2-ui-ncurses:i386  - instant messenger 
and IRC client for UNIX systems - ncu
p   fizmo-ncursesw- Ncurses-based 
Z-machine interpreter for Infocom/Inform
p   fizmo-ncursesw:i386   - Ncurses-based 
Z-machine interpreter for Infocom/Inform
p   lib32ncurses5 - shared libraries for 
terminal handling (32-bit)
p   lib32ncurses5-dev - developer's 
libraries for ncurses (32-bit)
p   lib32ncursesw5- shared libraries for 
terminal handling (wide character
p   lib32ncursesw5-dev- developer's 
libraries for ncursesw (32-bit)
p   lib64ncurses5:i386- shared libraries for 
terminal handling (64-bit)
p   lib64ncurses5-dev:i386- developer's 
libraries for ncurses (64-bit)
p   libcunit1-ncurses - Unit Testing Library 
for C (ncurses)
p   libcunit1-ncurses:i386- Unit Testing Library 
for C (ncurses)
p   libcunit1-ncurses-dev - Unit Testing Library 
for C (ncurses) -- development fil
p   libcunit1-ncurses-dev:i386- Unit Testing Library 
for C (ncurses) -- development fil
p   libghc-ncurses-dev- Haskell bindings to 
the GNU ncurses library
p   libghc-ncurses-dev:i386   - Haskell bindings to 
the GNU ncurses library
v   libghc-ncurses-dev-0.2.1-62800:i386   - 

v   libghc-ncurses-dev-0.2.1-778a0- 

p   libghc-ncurses-doc- Haskell bindings to 
the GNU ncurses library; documentat
p   libghc-ncurses-prof   - Haskell bindings to 
the GNU ncurses library; profiling
p   libghc-ncurses-prof:i386  - Haskell bindings to 
the GNU ncurses library; profiling
v   libghc-ncurses-prof-0.2.1-62800:i386  - 

v   libghc-ncurses-prof-0.2.1-778a0   - 

p   libkaya-ncurses-dev   - Ncurses binding for 
kaya
p   libkaya-ncurses-dev:i386  - Ncurses binding for 
kaya
p   libkaya-ncursesw-dev  - Ncurses binding for 
kaya
p   libkaya-ncursesw-dev:i386 - Ncurses binding for 
kaya
v   libncurses-dev- 

v   libncurses-dev:i386   - 

p   libncurses-gst- Ncurses bindings for 
GNU Smalltalk
i   libncurses5   - shared libraries for 
terminal handling
i   libncurses5:i386  - shared libraries for 
terminal handling
p   libncurses5-dbg   - debugging/profiling 
libraries for ncurses
p   libncurses5-dbg:i386  - debugging/profiling 
libraries for ncurses
p   libncurses5-dev   - developer's 
libraries for ncurses
p   libncurses5-dev:i386  - developer's 
libraries for ncurses
p   libncursesada-dbg - Ada binding to the 
ncurses text interface library: debu
p   libncursesada-dbg:i386- Ada binding to the 
ncurses text interface library: debu
p   libncursesada-doc - Ada binding to the 
ncurses text interface library: docu
p   libncursesada2- Ada binding to the 
ncurses text interface library: shar
p   libncursesada2:i386   - Ada binding to the 
ncurses text interface library: shar
p   libncursesada2-dev- Ada binding to the 
ncurses text interface library: deve
p   libncursesada2-dev:i386   - Ada binding to the 
ncurses text interface library: deve
i   libncursesw5  - shared libraries for 
terminal handling (wide character
i   libncursesw5:i386 - shared 

Re: Compiling a newer version than the latest .deb package

[Kevin J. McCarthy]

On Sun, Jun 02, 2019 at 09:51:25PM +1200, Frank Watt wrote:
On 2/06/19 9:07 PM, Jens John wrote:> On Sun, 2 Jun 2019, at 05:36, 
Frank Watt wrote:

[1] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mutt#n21


That's just the sort of information I was seeking.  Thanks for the tip.


That's a good starting place.  However, I would suggest using
 --prefix=/usr/local
and removing
 --sysconfdir=/etc
to make sure things are installed separately from rpm-managed files.

Also,
 --enable-debug
is good to have, in case you run into problems.

Lastly, the latest mutt releases have started to bump up system 
requirements:

 * If your gpgme library is too old and you don't use gpgme,
   you can just leave '--enable-gpgme' out.
 * If your OpenSSL version is too old, you could try '--with-gnutls'
   instead of '--with-ssl'
 * An old system likely does not come with idn2, so you would
   want to use '--with-idn' instead.

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Compiling a newer version than the latest .deb package

[Frank Watt]

On 2/06/19 9:07 PM, Jens John wrote:> On Sun, 2 Jun 2019, at 05:36, 
Frank Watt wrote:

>> Am I to assume that I would have had sendmail in my environment at the
>> time the deb was installed?  So I'd need to remove it so that I can
>> compile mutt with built-in SMTP.  What else would I need to bear in
>> mind?
>>
>> I'm a bit apprehensive about compiling code outside the control of a
>> package manager, but I can't see a way around it -- unless someone has
>> made a more recent .deb.
>
> (Why not just upgrade your Debian or Ubuntu release?)
There's nothing newer I can find:

https://sources.debian.org/patches/mutt/1.5.23-3/

> Anyway, whether sendmail (or compatible provider of it, such as
> postfix) is installed at compile time has, if I see it correctly, no
> bearing on whether the built-in SMTP client will be compiled or
> not. Just remember to select the configure flags you need – you
> likely want TLS support – and perhaps install into /usr/local or
> /opt/mutt if you compile from source.

Yes, I understood that.  I mentioned sendmail because it evidently isn't 
set in Muttrc or ~/.muttrc so I figured it happened when the .deb was 
installed.   Since I don't have any  other use for sendmail, should I 
delete it?


> A reasonable set of configure flags yielding a versatile mutt can 
e.g. be found at [1].

>
> ---
> [1] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mutt#n21


That's just the sort of information I was seeking.  Thanks for the tip.

Frank

Re: Compiling a newer version than the latest .deb package

[Jens John]

On Sun, 2 Jun 2019, at 05:36, Frank Watt wrote:
> Am I to assume that I would have had sendmail in my environment at the
> time the deb was installed?  So I'd need to remove it so that I can
> compile mutt with built-in SMTP.  What else would I need to bear in
> mind?
> 
> I'm a bit apprehensive about compiling code outside the control of a
> package manager, but I can't see a way around it -- unless someone has
> made a more recent .deb.

(Why not just upgrade your Debian or Ubuntu release?)

Anyway, whether sendmail (or compatible provider of it, such as postfix) is 
installed at compile time has, if I see it correctly, no bearing on whether the 
built-in SMTP client will be compiled or not. Just remember to select the 
configure flags you need – you likely want TLS support – and perhaps install 
into /usr/local or /opt/mutt if you compile from source.

A reasonable set of configure flags yielding a versatile mutt can e.g. be found 
at [1].

---
[1] 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mutt#n21