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 22102431FBD for ; Fri, 19 Oct 2012 19:21:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 bzpkI2awr55I for ; Fri, 19 Oct 2012 19:21:52 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id C11B4431FAE for ; Fri, 19 Oct 2012 19:21:52 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id n11so1232678vch.26 for ; Fri, 19 Oct 2012 19:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:in-reply-to:references:user-agent:date:message-id :mime-version:content-type; bh=IA8AT1hJRd8y3hQkhlfztVsXyqnQmZ8cInBQVaYVlIs=; b=znGLbSEngVozpDZS5t9xbe78X6WEpk0fB/3VptoRHodCmtPCee8Q6SnhgL/ZtCdfjJ 4nsLozopjDmDH/K5TcssG9HfRcqPT+kPqXWRevsR1R6CfJY1lo6re93PonHZ962+27L3 OqUCSquPyolihrrhMRdE91kZArHEdoMp/19v1eJNJN6C/L77q6v+zi4WLxCnHivq6pMD Uc9MoZRJlplQzngjy9V92kKLLgmg592j9dT7pxYv7uZeSu9Z21CVmtOtSVV+mDDjAkjl VxFj2fhyswJd68zsDuzOwwefeG/8d9BhvkaWB34FXiq4EGl4MaFnxfzrVANtk0uERDwH mN1Q== Received: by 10.220.157.75 with SMTP id a11mr4077253vcx.27.1350699712239; Fri, 19 Oct 2012 19:21:52 -0700 (PDT) Received: from smtp.gmail.com (p70-80.acedsl.com. [66.114.70.80]) by mx.google.com with ESMTPS id dq8sm2682429vdc.4.2012.10.19.19.21.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 19:21:51 -0700 (PDT) From: Ethan Glasser-Camp To: Peter Wang , notmuch@notmuchmail.org Subject: Re: [PATCH v2 3/3] test: conform to content length, encoding fields In-Reply-To: <1344428872-12374-4-git-send-email-novalazy@gmail.com> References: <1344428872-12374-1-git-send-email-novalazy@gmail.com> <1344428872-12374-4-git-send-email-novalazy@gmail.com> User-Agent: Notmuch/0.14+45~g6ea9330 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 19 Oct 2012 22:21:46 -0400 Message-ID: <877gql7uit.fsf@betacantrips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 02:21:54 -0000 Peter Wang writes: > Update tests to expect content-length and content-transfer-encoding > fields in show --format=json output, for leaf parts with omitted body > content. These three patches all look fine to me, except for the following problem. > diff --git a/test/json b/test/json > index ac8fa8e..8ce2e8a 100755 > --- a/test/json > +++ b/test/json > @@ -45,7 +45,7 @@ emacs_deliver_message \ > (insert \"Message-ID: <$id>\n\")" > output=$(notmuch show --format=json "id:$id") > filename=$(notmuch search --output=files "id:$id") > -test_expect_equal_json "$output" "[[[{\"id\": \"$id\", \"match\": true, \"excluded\": false, \"filename\": \"$filename\", \"timestamp\": 946728000, \"date_relative\": \"2000-01-01\", \"tags\": [\"inbox\"], \"headers\": {\"Subject\": \"$subject\", \"From\": \"Notmuch Test Suite \", \"To\": \"test_suite@notmuchmail.org\", \"Date\": \"Sat, 01 Jan 2000 12:00:00 +0000\"}, \"body\": [{\"id\": 1, \"content-type\": \"multipart/mixed\", \"content\": [{\"id\": 2, \"content-type\": \"text/plain\", \"content\": \"This is a test message with inline attachment with a filename\"}, {\"id\": 3, \"content-type\": \"application/octet-stream\", \"filename\": \"README\"}]}]}, []]]]" > +test_expect_equal_json "$output" "[[[{\"id\": \"$id\", \"match\": true, \"excluded\": false, \"filename\": \"$filename\", \"timestamp\": 946728000, \"date_relative\": \"2000-01-01\", \"tags\": [\"inbox\"], \"headers\": {\"Subject\": \"$subject\", \"From\": \"Notmuch Test Suite \", \"To\": \"test_suite@notmuchmail.org\", \"Date\": \"Sat, 01 Jan 2000 12:00:00 +0000\"}, \"body\": [{\"id\": 1, \"content-type\": \"multipart/mixed\", \"content\": [{\"id\": 2, \"content-type\": \"text/plain\", \"content\": \"This is a test message with inline attachment with a filename\"}, {\"id\": 3, \"content-type\": \"application/octet-stream\", \"content-length\": 12392, \"content-transfer-encoding\": \"base64\", \"filename\": \"README\"}]}]}, []]]]" This test fails for me. You're encoding the content-length of test/README. test/README certainly hasn't changed in the last six months so that seems like a reasonable thing to do... except then why is it 12392 on your machine, and 12380 on mine? I don't object to using test/README as a simple file to test with, but then you certainly shouldn't hard-code its length. You could pipe test/README through base64 and then through wc -c to get an accurate length, but for my machine a newline gets appended by base64 I think, and it gives me 12381. I'm tagging this patch moreinfo but you would have my +1 if you fix this. Ethan