>‘pacman -Qi mailcap’ will query for information on that package and show
>the upstream URL is https://pagure.io/mailcap. Pagure is like a
>SourceForge or GitLab and that installation is Fedora's, despite the
>misleading domain name: https://pagure.io/about/. Fedora took Red Hat's
>source.
Ken Hornstein wrote in
<20210512224215.9969ccd...@pb-smtp1.pobox.com>:
|>nmh could adapt or build upon the src/mx/mailcap.c of my MUA. It
|>is pretty much standing on its own feet, has matured (there were
|>a few hmm nits), and offers really nice extensions like
|>x-mailx-test-once,
Michael wrote:
> I do this in .mh_profile via:
> mhshow-show-text/html: google-chrome '%f'
>
> although sometimes the file goes missing before the browser can display it.
I use this:
#: The sleep prevents removing the temp file before the quick-returning
#: google-chrome --new-window
>nmh could adapt or build upon the src/mx/mailcap.c of my MUA. It
>is pretty much standing on its own feet, has matured (there were
>a few hmm nits), and offers really nice extensions like
>x-mailx-test-once, x-mailx-ignore etc.
Thank you for that offer. And forgive me if this is a stupid
Ralph Corderoy wrote in
<20210512202431.3d70322...@orac.inputplus.co.uk>:
|Hi Valdis,
|
|> Which raises the question - what is getting into the path so when
|> Laura adds entries to /etc/mailcap, things start working for her?
|
|Ken suggested some distros might alter nmh's release when
Speaking about mhshow.
While I usually use mh-e, and it's internal html viewer, there are times when
it just fails, or I really want to use my regular browser.
I do this in .mh_profile via:
mhshow-show-text/html: google-chrome '%f'
although sometimes the file goes missing before the browser
>I'm not very clueful about how things like homebrew get prodded for
>release update. Always interests me which side of the fence makes it
>happen. Is it NMH people, or Homebrew people? (its on 1.7.1 via url
>"https://download.savannah.gnu.org/releases/nmh/nmh-1.7.1.tar.gz;)
Well, "brew log nmh"
>> There's no HARM in you putting entries there. But nmh doesn't read that
>> file either.
>
>Which raises the question - what is getting into the path so when Laura
>adds entries to /etc/mailcap, things start working for her?
That's ... a good question.
First, it's not that I don't believe
I'm not very clueful about how things like homebrew get prodded for
release update. Always interests me which side of the fence makes it
happen. Is it NMH people, or Homebrew people? (its on 1.7.1 via url
"https://download.savannah.gnu.org/releases/nmh/nmh-1.7.1.tar.gz;)
It doesn't actually
Hi Valdis,
> Which raises the question - what is getting into the path so when
> Laura adds entries to /etc/mailcap, things start working for her?
Ken suggested some distros might alter nmh's release when packaging to
use mailcap(5). Looking at
https://sources.debian.org/patches/nmh/1.7.1-4/,
Ken wrote:
> Really, you want to look at mhn.defaults. That's what nmh uses, and that
> has been the ONLY thing that it uses. mhshow(1) has the details.
Well, that depends. If your nmh was configured with a mimetypeproc,
then that will be tried first. See the paragraph containing
On Wed, 12 May 2021 12:58:23 -0400, Ken Hornstein said:
> >> Oh goodness. I had no idea. And here I have been happily editing
> >> /etc/mailcap
> >> every time somebody sends me something I cannot read, adding a rule about
> >> how to
> >> read it, and smiling contentedly when nmh starts being
>> Oh goodness. I had no idea. And here I have been happily editing
>> /etc/mailcap
>> every time somebody sends me something I cannot read, adding a rule about
>> how to
>> read it, and smiling contentedly when nmh starts being able to read it
>> properly.
>>
>> Where should I have been
In a message of Wed, 12 May 2021 12:25:30 -0400, "Valdis Klētnieks" writes:
>On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said:
>
>> Oh goodness. I had no idea. And here I have been happily editing
>> /etc/mailcap
>> every time somebody sends me something I cannot read, adding a rule
On Wed, 12 May 2021 18:16:28 +0200, Laura Creighton said:
> Oh goodness. I had no idea. And here I have been happily editing
> /etc/mailcap
> every time somebody sends me something I cannot read, adding a rule about how
> to
> read it, and smiling contentedly when nmh starts being able to
In a message of Wed, 12 May 2021 07:55:56 -0400, Ken Hornstein writes:
>>Manjaro is based on Arch linux, and Arch linux is based on debian.
>>My debian distro looks for such things in /etc/mailcap. I'd look there first.
>
>Just for the record nmh (and MH before it) has never directly used
Ralph wrote:
> I think this change fixes both things and restores the commit-hash
> removal, which you originally added.
> Happy for me to commit?
Quite. First-rate detective work. Yes, I do have git configured to add
color in this situation. I did take a run at sed but without the C locale,
>Manjaro is based on Arch linux, and Arch linux is based on debian.
>My debian distro looks for such things in /etc/mailcap. I'd look there first.
Just for the record nmh (and MH before it) has never directly used
the mailcap file. Arguably, it SHOULD, but it does not (I am aware
there are
Hi David,
> commit 9fd3638e971f661fb3af78c2aef003d17aa31798
> Author: David Levine
> Date: Tue May 11 20:05:03 2021 -0400
>
> Leave commit hashes in ChangeLog.
>
> With newer git, the yellow commit hashes slipped by the grep anyway.
> And grep tripped over an ISO8859 ü in the
Hi Steven,
>$ cat /etc/mailcap
>###
>### Begin Red Hat Mailcap
>###
...
> I'm not going to speculate on why an Arch-derived distribution has an
> /etc/mailcap sourced from Red Hat. :-/
Oh, that's right, Manjaro, don't know why I asked what system in the
other email!
‘pacman -Qi
>Also .deb files just install on Arch, no? (been a long time since I had
>one.)
No, Arch uses its own package manager:
https://wiki.archlinux.org/title/pacman
Details for the file package in Arch are here:
https://archlinux.org/packages/core/x86_64/file/
The current version is 5.40-3,
>I think it's a file(1) bug in the executable, probably known and fixed
>upstream.
That would make sense, and I'll follow it up in that direction (after
getting some sleep :-/).
>What system are you running, e.g. Ubuntu, and its version?
Like Arch, Manjaro is a rolling release, so the number
Hi Steven,
> >- What does ‘file -i’ give on the MP3 file?
>
> ...Aha! You nailed it:
>
>$ file -i /tmp/session2.mp3
>/tmp/session2.mp3: audio/mpegapplication/octet-stream; charset=binary
>
> ...and similarly,
>
>$ file --mime-type /tmp/session2.mp3
>/tmp/session2.mp3:
>My debian distro looks for such things in /etc/mailcap. I'd look there first.
Thanks!
...but I suspect that may be a Clupea harengus of the crimson variety :-),
partly because it was last modified more than a year ago:
$ ls -l /etc/mailcap
-rw-r--r-- 1 root root 272 May 5 2020
In a message of Wed, 12 May 2021 10:12:06 +0100, Ralph Corderoy writes:
>Hi Laura,
>
>> Manjaro is based on Arch linux,
>
>Yep.
>
>> and Arch linux is based on debian.
>
>No, I don't think so. I run Arch Linux here and one key reason is it
>packages upstream releases directly without much
>The complaint about ‘/octet-stream’ coupled with the trailing
>‘application’ after ‘audio/mpeg’ looks like two things are being
>combined, e.g. ‘audio/mpeg application/octet-stream’.
That makes sense.
>- How do you attach the MP3 file?
By typing "at /path/to/file.mp3" at the whatnow? prompt.
Hi Laura,
> Manjaro is based on Arch linux,
Yep.
> and Arch linux is based on debian.
No, I don't think so. I run Arch Linux here and one key reason is it
packages upstream releases directly without much tinkering or delay by
doing a ‘rolling’ release, unlike Debian which has a comprehensive
Hi Steven,
> Recently I've been seeing this message when sending email with an
> attached .mp3 file:
>
>mhbuild: extraneous information in message /home/smw/Mail/drafts/1's
> Content-Type: field
> (/octet-stream)
>
> I've appended the Fcc copy of a typical message, in which the
In a message of Wed, 12 May 2021 04:20:24 -0400, Steven Winikoff writes:
>I'm quite sure this isn't nmh's fault, but rather an error in the MIME
>configuration on my Manjaro Linux machine. I'm hoping for a hint about
>where to look for the config file responsible for "audio/mpegapplication;".
>
>
Recently I've been seeing this message when sending email with an attached
.mp3 file:
mhbuild: extraneous information in message /home/smw/Mail/drafts/1's
Content-Type: field
(/octet-stream)
I've appended the Fcc copy of a typical message, in which the Content-Type:
field for the
On Tue, 11 May 2021 17:58:21 -0700, David Levine said:
> Valdis wrote:
>
> > I originally put "patch in next mail" in the subject because the fix to not
> > use
> > a static char[] seemed obvious.
>
> I went the other way, so all the other callers of etcpath() wouldn't
> have to change:
That
31 matches
Mail list logo
