NetBSD Problem Report #50098

From kre@munnari.OZ.AU  Wed Jul 29 10:49:43 2015
Return-Path: <kre@munnari.OZ.AU>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 66571A567D
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 29 Jul 2015 10:49:43 +0000 (UTC)
Message-Id: <201507291047.t6TAlvLl010265@perseus.noi.kre.to>
Date: Wed, 29 Jul 2015 17:47:57 +0700 (ICT)
From: kre@munnari.OZ.AU
To: gnats-bugs@gnats.NetBSD.org
Subject: Modified (erroneous) src file in NetBSD-7 X11 Mesalib source
X-Send-Pr-Version: 3.95

>Number:         50098
>Category:       xsrc
>Synopsis:       Modified (erroneous) src file in NetBSD-7 X11 Mesalib source
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 29 10:50:00 +0000 2015
>Last-Modified:  Tue Jan 10 15:20:00 +0000 2017
>Originator:     Robert Elz
>Release:        NetBSD 7.0_RC2 (also RC1)
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD perseus.noi.kre.to 6.99.17 NetBSD 6.99.17 (GENERIC) #1: Fri Feb 22 22:09:50 ICT 2013 kre@jade.coe.psu.ac.th:/usr/obj/current/i386/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
	I recently updated my netbsd 7 source tree from RC1 to RC2
	(actually from something during the RC1 period to RC2 as it
	existed a couple of days ago).

	While doing that, cvs told me that I had a locally modified
	file in my source tree ... which was very unlikely, especially
	as it was under xsrc (a place that is all black magic and demons
	to me, and to whence I never venture) and even more especially
	as it appears to be an output file from lex which would never
	normally be modified by hand (but which would naturally get
	modified every time lex is run with a different setup, say
	mine, vs some developer).

	M xsrc/external/mit/MesaLib/dist/src/glsl/glcpp/glcpp-lex.c

	My "modifications" (according to cvs diff) were mostly stuff
	like ...

1171c1183
< #line 258 "glcpp/glcpp-lex.l"
---
> #line 258 "/release/7/src/xsrc/external/mit/MesaLib/dist/src/glsl/glcpp/glcpp-lex.l"
1171c1183
< #line 258 "glcpp/glcpp-lex.l"
---
> #line 258 "/release/7/src/xsrc/external/mit/MesaLib/dist/src/glsl/glcpp/glcpp-lex.l"

	But I also see what look to be a bunch of portability type
	changes (_'s in front of variable names, a /*CONSTCOND*/ de-lint
	comment added, etc.)   Those may have appeared when I built RC2,
	I don't recall seein them before (but I also did not look all
	that closely).

	My guess is that the NetBSD 7 build system is missing a fix
	that I suspect has been made to -current (I do not see this
	issue there) which is causing lex output to be placed in the
	source directory, rather than the obj directory.  Building with
	a read-only source would probably spot this quite quickly.

>How-To-Repeat:
	By inspection.   lex output files should generally not be checked
	into the cvs repository.   Files in the source directories should
	not be modified by the build process.

>Fix:
	Find what the fix was to the build system (or find a fix if it
	is not fixed in current) and pull it up to NetBSD 7.

	cvs rm glcpp-lex.c  (or however that is really done).

>Audit-Trail:
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Re: xsrc/50098: Modified (erroneous) src file in NetBSD-7 X11 Mesalib
 source
Date: Tue, 10 Jan 2017 16:15:03 +0100

 [re-sent with PR number]

 I just ran into this problem a few days ago with a -current build. 
 Following the "build.sh & lex & dependall" thread on 
 <https://mail-index.netbsd.org/current-users/2006/04/>, I removed 
 xsrc/external/mit/MesaLib/dist/src/glsl/glcpp/glcpp-lex.{c,l} and 
 freshly checked out the two files. The build then completed successfully.

 Following 
 <https://mail-index.netbsd.org/current-users/2006/04/09/0005.html>, I 
 think this is a build system problem (rather than xsrc):

 Either you re-lex(1) the .c file during the build, or, if you absolutely 
 need to violate the "no products under revision control" mantra, you 
 need to make sure the product file is not being rebuilt.

 Cheerio,
 Hauke

 -- 
       The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email	        Institut für Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
       Respect for open standards              Ruf +49-6151-16-21344

Home	PR Database Search