Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163866 - xemacs MH-E: mh-compose-insertion doesn't ask for MIME type
Summary: xemacs MH-E: mh-compose-insertion doesn't ask for MIME type
Alias: None
Product: Fedora
Classification: Fedora
Component: file
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Radek Vokal
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-21 17:47 UTC by Horst H. von Brand
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 4.14-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-22 07:56:22 UTC

Attachments (Terms of Use)

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):

How reproducible:

Steps to Reproduce:
1. Create a draft message using MH-E
2. C-c C-m C-i, give file name etc
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  
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  
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 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   
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   
$ 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>  
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 Vokal 2005-07-22 07:56:22 UTC

Note You need to log in before you can comment on or make changes to this bug.