From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id BD1B1431FAE for ; Thu, 8 Mar 2012 13:40:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBW3uQQDZqcO for ; Thu, 8 Mar 2012 13:40:01 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by olra.theworths.org (Postfix) with ESMTP id 306E1431FB6 for ; Thu, 8 Mar 2012 13:40:01 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id A083DF970 for ; Thu, 8 Mar 2012 16:39:58 -0500 (EST) Message-ID: <4F592730.2040908@fifthhorseman.net> Date: Thu, 08 Mar 2012 16:40:00 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: notmuch Subject: Re: Parsing regression with gmime-2.6? References: <87d38w2e7h.fsf@zancas.localnet> <1331058417-13776-1-git-send-email-amdragon@mit.edu> <87wr6xmlml.fsf@zancas.localnet> <87vcme3kf6.fsf@pip.fifthhorseman.net> <874ntybwxv.fsf@servo.finestructure.net> In-Reply-To: <874ntybwxv.fsf@servo.finestructure.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: notmuch List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:40:01 -0000 On 03/08/2012 04:32 PM, Jameson Graef Rollins wrote: > I actually agree with this position. mbox files are not proper email > messages, so if gmime does not explicitly support parsing them then we > really can't expect it to parse them. i think the point here is that gmime used to support parsing them and now it doesn't. So if you've got a pre-existing notmuch index (built from when gmime *did* parse them) and you're now running notmuch linked against a gmime that *doesn't* parse them, then notmuch search will produce references to messages that notmuch show can't produce output for. While i appreciate wanting to be sure that we're working with well-formed files, I don't have a good answer for what the right thing to do is, if gmime upstream agrees with your assessment of the situation. yuck, --dkg