X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-CMAE-Analysis:	v=2.4 cv=VNoYI/DX c=1 sm=1 tr=0 ts=5fe7ff73
	a=+cj0cO56Fp8x7EdhTra87A==:117 a=hKQBUPAeLAnzEkKuvc6TRw==:17
	a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=IkcTkHD0fZMA:10 a=zTNgK-yGK50A:10
	a=a1KZgU7cAAAA:8 a=Mj1Xp5F7AAAA:8 a=ggXPeuQOm-v9BnMyeKEA:9 a=QEXdDO2ut3YA:10
	a=ng0hpkU2jXKPaRTLMVYJ:22 a=OCttjWrK5_uSHO_3Hkg-:22 a=pHzHmUro8NiASowvMSCR:22
	a=Ew2E2A-JSTLzCXPT_086:22
X-SECURESERVER-ACCT:	glimrick AT epilitimus DOT com
Subject:	[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>
From:	"Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<796bed87-7c91-fe93-fbfa-7090c731be36@epilitimus.com>
Date:	Sat, 26 Dec 2020 19:28:46 -0800
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Firefox/60.0 SeaMonkey/2.53.3
MIME-Version:	1.0
In-Reply-To:	<dc4e8a13-d29e-8c22-7957-77acacd2aba9@epilitimus.com>
X-AntiAbuse:	This header was added to track abuse, please include it with any abuse report
X-AntiAbuse:	Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net
X-AntiAbuse:	Original Domain - delorie.com
X-AntiAbuse:	Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse:	Sender Address Domain - epilitimus.com
X-Get-Message-Sender-Via:	a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender:	a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com
X-Source:
X-Source-Args:
X-Source-Dir:
X-CMAE-Envelope:	MS4xfJ/DcaawaYh5xsfGi3Wr6WVllHQYI63/RpuEvIZvMCK652AnnKYjjBjBpqlFxjsDSAeC1PXzTCiPbmlcJ6/C5pU7/R1ZvjGlTvYe7eMgrZMqADlUY+pk
	Z2k/KJM9kQ8MBRyQp5CjLNQ6SyjMevL1mYItKa8VBY/Q4J/iyBuloxuw9CcUWtd7QxQoNjwAXgD71Nyg2qUYOqp8Gf5IWU7AsIo1ozVZbxORt3vaxUB0YSUp
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

Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com] wrote:
> As far as I can track it with my very limited scheme knowledge:
> 1. build-path does still exist.
> 2. In order to use it system-gafrc has to be somehow loaded. It loads
> geda.scm which is where build-path is defined.
>
> Hope that helps.
>
> Glenn
>
>
My final analysis on this error progression:
1. The test framework uses the in source tree copy of
system-gsymcehckrc, as it should.
2. It accomplishes this by setting the GEDADATARC environment variable,
again reasonable.
3. A side effect of this is that no other system rc files are loaded,
including system-gafrc.
4. g_rc_parse_handler (called indirectly by gsymcheck) loads user rc
files from ~/.gEDA. There does not appear to be a way to prevent this.
5. Because system-gafrc is *not* loaded during a test run, none of the
geda specific functions (like build-path) defined/loaded there are
available.
6. If a user gafrc file exists and uses geda specific functions it will
fail to load (or if it fails for any other reason), an error massage
will be output causing the test to fail, even though gsymcheck runs as
expected.
7. This will only occur during an upgrade build where the user already
has a gafrc file. It will not occur during an original install.
8. This bug only affects gsymcheck because none of the other 'make
check' runs attempt to load rc files. At least as far as I can tell.

Possible solution:
In gsymcheck/tests/runtest.sh add errors about failed rc loads, and
possibly related stack traces, to the lines removed from the output.
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.

Glenn

- Raw text -