X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=aQEbVWFUciSEZhHPEHkA1jN6UJTJ1 jbe3V8qeYIX0bU=; b=A5wOLu9jLgiCgPhXpgPwz5L6u4mNrOmXeVWw6Z19xrp+P JPCNB6dRfmtukBUaeFa7sYCVXnO65I65JE7h+5EUw7axZR+wQRGzBFiOaYJ8NMA+ fLTyf/j8CVQk0JvVLuOu09A+TmZaeOVPH5HJEFwi6Vw3JHRiGnjrc7Cf4z7iXlFF ZPE2dIN1DqH61tcRzak2FkI3A+hO3KI04pk+H1QYUuh8YF/Hf0BK7G/uNsL3xP6R uT8BA3DK0rGv4183J00OqWN3nWFCqJtWe8b59rp7GkI4x9TB8Xt+uz0oUIgH3b+/ HZDleGO2Ui473UDMeWg8epygxaLJTT13rrENybSGA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddujedgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhffkffgfgggjtgfgse htkeertddtfeejnecuhfhrohhmpefiihhrvhhinhcujfgvrhhruceoghhhvghrrhhlsehf rghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepgeduhffhleelleffgeejtd ffvdelgeevhfefieegkeefhfdvjeektdegleeiueefnecukfhppedutdekrddvudehrddu leehrddvtdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepghhhvghrrhhlsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Subject: Re: [geda-user] gsymcheck 'make check' failure final analysis To: geda-user AT delorie DOT com References: <09a3adc8-401f-70fd-1ba4-c5cc850f62aa AT fastmail DOT com> <5a52e3b4-50a6-2b0e-7d7d-7eb144c5619f AT epilitimus DOT com> <1d8bac3a-9787-dd41-9269-ab8d3d681754 AT epilitimus DOT com> <54c87596-c5ef-cfba-d74d-2fa6411b555f AT fastmail DOT com> <796bed87-7c91-fe93-fbfa-7090c731be36 AT epilitimus DOT com> From: "Girvin Herr (gherrl AT fastmail DOT com) [via geda-user AT delorie DOT com]" Message-ID: Date: Sun, 27 Dec 2020 13:09:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 12/27/20 10:12 AM, Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com] wrote: > Roland Lutz wrote: >>> Ideally there should be a way to prevent non-source tree config files >>> from being loaded during a test run as there is no way to know what >>> is in them which may cause the test to fail. >> I agree.  It's pretty low on my priority list, though, since it would >> become obsolete once the new configuration mechanism is in place. > Oh? Please do tell :) > > Best solution I came up with was a new environment variable > (GEDA_NOUSERRC?) that would block loading user rc files. But if there is > going to be new and exciting things upcoming soon... > > A couple of lines in libgeda/src/g_rc.c, gsymcheck/tests/Makefile.am, > and possibly runtests.sh. > > Glenn Greetings, I was about to move this thread out of the ANNOUNCE thread to a more appropriate subject when I noticed you beat me to it. Thanks. Hijacking the ANNOUNCE thread was my oops. Sorry. I have been giving some thought about this problem overnight and I have decided this is not so much a bug in gEDA as it is a problem with my package build process. As observed, this failure only happens when the ~/.gEDA/gafrc file exists. Most people probably build the package as root, where this file is non-existent (if they are smart, they are not running gEDA programs as root), so they will not see this problem. However, my package build process has two stages. First, I build in my user account, which I do use for gEDA projects and it does have the ~/.gEDA/gafrc file. Then, when I am satisfied that that build stage is safe and correct, I go to stage 2, where, as root, I build the final package and install it. For some time, I have been concerned about security when building in my home account, so I have been giving some thought to creating a limited user account that does not have network access apps and use it for the stage 1 builds. I started the transition a few days ago, before this gEDA make check problem surfaced, but I have not completed it yet. So, this coming week, I will escalate that task and complete that transistion and try the gEDA-gaf make check in that account and see if that solves the problem. I will report the results here when I determine the results. IMHO, this is not a bug in gEDA and it may not be a good idea to incorporate test-specific code in gEDA, just to keep this "problem" silent. An example would be Volkswagen a few years ago was caught putting factory test code in their engine computers which disabled the emissions functions. This turned sour when the EPA discovered this code was running on their vehicles on the highway and polluting the air. As a result, VW got a stiff fine and their reputation is still not back to what it was before this incident. Thanks to everyone who helped me with this problem and take care. Girvin