Bug 163866

Summary:	xemacs MH-E: mh-compose-insertion doesn't ask for MIME type
Product:	[Fedora] Fedora	Reporter:	Horst H. von Brand <vonbrand>
Component:	file	Assignee:	Radek Vokál <rvokal>
Status:	CLOSED RAWHIDE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	extras-qa, scop
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	4.14-2	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-07-22 07:56:22 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Horst H. von Brand 2005-07-21 17:47:51 UTC

Description of problem:
mh-compose-insertion always gives MIME type of audio/x-mod

Version-Release number of selected component (if applicable):
xemacs-21.4.17-4

How reproducible:
Always

Steps to Reproduce:
1. Create a draft message using MH-E
2. C-c C-m C-i, give file name etc
3.
  
Actual results:
Attachment is audio/x-mod

Expected results:
Should ask for MIME type

Additional info:

Comment 1 Ville Skyttä 2005-07-21 18:41:06 UTC

Hm, I'm not a mh-e user, and I could not reproduce this in brief tests, so you  
may need to walk me through here... (oh, and mh-e is in the xemacs-sumo  
package). 
  
Anyway, first, do you have the "file" package installed?  If yes, what does  
"file -i -b FILENAME" where FILENAME is the file you're trying to attach  
output? 
 
If the "file" command is not available, you should be asked for the content 
type, otherwise it should be determined based on file's output. 
 
By the way, there's a new xemacs-sumo heading towards the repository as soon 
as the Extras build system is available again, but according to upstream 
changelogs, mh-e hasn't changed.

Comment 2 Horst H. von Brand 2005-07-21 20:03:17 UTC

Might it be breakage in nmh? I've got nmh-1.1-8.fc4 and xemacs-sumo-20050505-6 here.

file-4.14-1

$ file 4802.1.txt
4802.1.txt: ISO-8859 text

Gives audio/x-mod

$ file J-Planificacion2005-Vinculacion.doc
J-Planificacion2005-Vinculacion.doc: Microsoft Office Document

Also guesses audio/x-mod

I've also tried with PostScript and PDF files, which file(1) identifies fine.

Comment 3 Ville Skyttä 2005-07-21 20:23:10 UTC

I don't know about nmh either.  
  
But just to verify, could you run the file(1) tests    
using the -i and -b arguments to it, for example "file -i -b   
J-Planificacion2005-Vinculacion.doc" (see comment 1)?  That's how mh-e invokes   
file(1).  
   
BTW, here's how I'm trying to reproduce the problem (and failing), is this the 
correct way? 
   
$ rpm -q nmh xemacs-sumo xemacs file   
nmh-1.1-8.fc4   
xemacs-sumo-20050715-1   
xemacs-21.4.17-4   
file-4.13-4   
$ file -i -b pcsc-wrapper-bt-full.txt   
text/plain; charset=iso-8859-1   
$ xemacs   
M-x mh-letter-mode  
C-c C-m C-i  
[...add description etc, no media type asked...]  
  
The result is this in the MH-Letter buffer:  
<#part type="text/plain" filename="~/pcsc-wrapper-bt-full.txt"  
disposition=attachment description=asd>  
<#/part>  
  
All other file types appear to get the correct MIME types too.

Comment 4 Ville Skyttä 2005-07-21 20:33:08 UTC

Okay, I upgraded to file-4.14-1 on a FC4 box, and "file -i -b foo" returns 
audio/x-mod for everything.  Reassigning...

Comment 5 Radek Vokál 2005-07-22 07:56:22 UTC

Fixed