From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 08AA16DE172E for ; Wed, 15 Feb 2017 10:59:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=0.006, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1Os1oF5qQda for ; Wed, 15 Feb 2017 10:59:36 -0800 (PST) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 3F85E6DE16D2 for ; Wed, 15 Feb 2017 10:59:36 -0800 (PST) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1ce4n2-0000ZF-Gi; Wed, 15 Feb 2017 13:58:56 -0500 Received: (nullmailer pid 21696 invoked by uid 1000); Wed, 15 Feb 2017 18:59:31 -0000 From: David Bremner To: Daniel Kahn Gillmor , notmuch@notmuchmail.org Subject: Re: [PATCH 2/2] test: use gpgconf --create-socketdir if available In-Reply-To: <87efyzl3n8.fsf@alice.fifthhorseman.net> References: <20170214214239.9330-1-david@tethera.net> <20170214214239.9330-3-david@tethera.net> <87efyzl3n8.fsf@alice.fifthhorseman.net> Date: Wed, 15 Feb 2017 13:59:31 -0500 Message-ID: <8737ffjn58.fsf@rocinante.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 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: Wed, 15 Feb 2017 18:59:37 -0000 Daniel Kahn Gillmor writes: > I'd love to not see this kind of workaround cruft pile up, because it > tends to cause problems in the future. is there a way that we can mark > this sort of thing for fairly prompt removal once it's fixed upstream? Maybe once a gnupg bug is filed, write to this list with the suggestion that we back out the workaround when the bug is fixed upstream (although we have to think about how long to support gnupg 2.1.18. Thanks debian!). We can then tag that message as a bug in nmbug. d