Subject: misc/20279: X11R6.3 i386 "make release" fails
To: None <gnats-bugs@gnats.netbsd.org>
From: None <kre@munnari.OZ.AU>
List: netbsd-bugs
Date: 02/10/2003 15:29:10
>Number:         20279
>Category:       misc
>Synopsis:       X11R6.3 i386 "make release" fails
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 10 00:30:02 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Robert Elz
>Release:        NetBSD 1.6N  -- sources of 2003-02-09
>Organization:
	Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 1.6L NetBSD 1.6L (JADE) #12: Fri Jan 10 10:03:59 ICT 2003 kre@fuchsia.cs.mu.OZ.AU:/usr/obj/sys/JADE i386
	(not the environment of the system where the problem was detected,
	just the one that the send-pr is being done from...)
Architecture: i386
Machine: i386

>Description:
	If one attempts to build an i386 X11 release with USE_XF86_4=no
	the snapshot fails.   That's because the list of files to include
	in xbase.tgz includes cat1/scanpci.0 which does not exist for
	X11R6.3 (It does in Xfree 4).

	This has actually been (nominally) broken for quite a while now.
	It only recently revealed itself as a problem (sometime in the
	past month) when tar/pax was changed to exit with an error when
	a file it was asked to include didn't exist (previously it just
	failed to include the file in the archive - maybe printed a
	warning, and exited with status 0).

>How-To-Repeat:
	test `uname -m` = i386 || cd /to/some/i386/processor
	cd .../xsrc
	make USE_XF86_4=no release	# with other options as appropriate
	echo $?

>Fix:
	Move scanpci.0 from xbase to xbase4 in src/distrib/sets/lists
	(note that the executable scanpci should not move, it exists
	in both releases).   (It is currently in xbase/md.i386 - there
	is no current xbase4/md.i386 so where to put it, I will leave
	for someone else).

	An alternative may be to create scanpci.man for X11R6.3 but
	that seems to be a much more intrusive change.

	Another possibility would be to have pax return to exit(0) if
	the only problem is a file failing to exist, but somehow, I don't
	see that happening...
>Release-Note:
>Audit-Trail:
>Unformatted: