From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8qPm-0008E0-2D for guix-patches@gnu.org; Thu, 11 May 2017 11:54:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8qPj-00013Q-Ex for guix-patches@gnu.org; Thu, 11 May 2017 11:54:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:36276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d8qPj-00013H-CO for guix-patches@gnu.org; Thu, 11 May 2017 11:54:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d8qPj-0004Md-5Y for guix-patches@gnu.org; Thu, 11 May 2017 11:54:03 -0400 Subject: bug#26716: Test nginx configuration Resent-To: guix-patches@gnu.org Resent-Message-ID: References: <20170430120453.35cf17f1@lepiller.eu> <87o9vddibs.fsf@dustycloud.org> <20170430193520.4a4129b3@lepiller.eu> <87lgqhd5zd.fsf@dustycloud.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur In-reply-to: <87lgqhd5zd.fsf@dustycloud.org> Date: Thu, 11 May 2017 17:53:46 +0200 Message-ID: <87tw4rs839.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Christopher Allan Webber Cc: 26716-done@debbugs.gnu.org Christopher Allan Webber writes: > Julien Lepiller writes: > >>> So is the goal here that it will raise an exception if it doesn't >>> exist, like so? >>> >>> ERROR: In procedure lstat: No such file or directory: >>> "/tmp/no-such-file" >>> >>> That does seem like useful information to spit out. >>> >>> Maybe add a comment before the lstat explaining the call? If I didn't >>> know that's why lstat was being used here I would have been confused. >> exactly, I added a comment. > > Great! > >>> Oh, that's interesting. So in my experience earlier, it was proably >>> *trying* to log some information, and failing I guess. >>> >>> It would be even nicer if they wrote to the same file by default, but >>> I guess this probably isn't easy to do without actually patching nginx >>> itself, which isn't likely worth it... is that right? >> I tried using the -g option to give it some configuration options >> (including error_log), but it doesn't seem to change that behaviour, so >> I think we'll have to fix nginx to use the same configuration file. >> >> Of course it would be better to fail at reconfigure when the generated >> configuration is not correct. That's what I'm trying to do with the >> first patch, but that's only one possible mistake. > > Cool... yes I agree it's only one possible mistake. :) > > Looks good. I assume you've tried testing building with it? Assuming > all builds and things also error out right now in the new and expected > ways when the configuration needs updating, I say push it! Closing it as it has been pushed. Thanks!