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:	<xms:i_joXwf67lnFq7jWX3Gvx5uogWw4dCdscTTAIMXjoS2fprkiDD3Ezg>
	<xme:i_joXyPbzNdy-etfy45PrwFUAE6z6AqYhEZ58weGFAvffvF_2ZmAmlUkMVG4rC1iS
	iIa-xvH65We1XFxcw>
X-ME-Proxy-Cause:	gggruggvucftvghtrhhoucdtuddrgedujedrvddujedgudeglecutefuodetggdotefrod
	ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
	necuuegrihhlohhuthemuceftddtnecunecujfgurheprhfuvfhfhffkffgfgggjtgfgse
	htkeertddtfeejnecuhfhrohhmpefiihhrvhhinhcujfgvrhhruceoghhhvghrrhhlsehf
	rghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepgeduhffhleelleffgeejtd
	ffvdelgeevhfefieegkeefhfdvjeektdegleeiueefnecukfhppedutdekrddvudehrddu
	leehrddvtdehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
	homhepghhhvghrrhhlsehfrghsthhmrghilhdrtghomh
X-ME-Proxy:	<xmx:i_joXxgYv0TuPe-61YeZZ67nqCC_WMubksphWOWqGtNhN-iv3D_gWQ>
	<xmx:i_joX18-BkC01JhVswLo7jZkdK3gCRUvq1vCHJI_Sqt92SMg4q8xqg>
	<xmx:i_joX8usifxUQzrLxjkgXCagAwn1K9rd1vI-WLYd6FWNuwLEpMPWBQ>
	<xmx:jPjoX67-aw2I4ysMCjfYKcUEs9ljbYxp-0GKOrBQTpz6eCfqsBNW5cH4Gc4>
Subject:	Re: [geda-user] gsymcheck 'make check' failure final analysis
To:	geda-user AT delorie DOT com
References:	<alpine DOT DEB DOT 2 DOT 21 DOT 2012222348500 DOT 521 AT nimbus>
	<09a3adc8-401f-70fd-1ba4-c5cc850f62aa AT fastmail DOT com>
	<5a52e3b4-50a6-2b0e-7d7d-7eb144c5619f AT epilitimus DOT com>
	<ebab350e-1ca4-505f-2155-a376ca8350ac AT fastmail DOT com>
	<1d8bac3a-9787-dd41-9269-ab8d3d681754 AT epilitimus DOT com>
	<54c87596-c5ef-cfba-d74d-2fa6411b555f AT fastmail DOT com>
	<dc4e8a13-d29e-8c22-7957-77acacd2aba9 AT epilitimus DOT com>
	<796bed87-7c91-fe93-fbfa-7090c731be36 AT epilitimus DOT com>
	<alpine DOT DEB DOT 2 DOT 22 DOT 394 DOT 2012271434420 DOT 2232 AT yoga>
	<c037a620-99de-8b31-88ac-ed0b24f4f8a3 AT epilitimus DOT com>
From:	"Girvin Herr (gherrl AT fastmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<e8a3e15b-b7ff-d46d-b4ee-0b1aec553983@fastmail.com>
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:	<c037a620-99de-8b31-88ac-ed0b24f4f8a3@epilitimus.com>
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

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

- Raw text -