pkg/41965: wm/afterstep fails to install MANY files (NetBSD 4.0/i386)

[kre%munnari.OZ.AU@localhost]

>Number:         41965
>Category:       pkg
>Synopsis:       wm/afterstep fails to install MANY files (NetBSD 4.0/i386)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 01 03:10:00 +0000 2009
>Originator:     Robert Elz
>Release:        NetBSD 4.0  pkgsrc -current
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE 
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
        wm/afterstep (afterstep-2.1.2nb8) generates many errors from the
        file-check phase of building a binary package, that occurs when
        PKG_DEVELOPER is set (along with the warnings that also customarily
        accompany that when files the PLIST says should exist have not been
        installed).

        I also noticed during this compile an attempt to connect to the X
        server weas rejects (nothing running inside the pkg_comp sandbox
        has authorisation to connect to any X servers - doing so would always
        be a mistake, this is building binary packages, whatever X server
        may happen to exist on the build machine, and its environment, has
        almost no relationship to what might be expected where the package
        is actually installed, nor what might actually be running when the
        package is used later after installation.    Whether the failed
        attempt to connect to the X server relates to the other problems I have
        no idea.

>How-To-Repeat:
        I use pkg_comp with NetBSD 4.0 release sets installed, and libkver
        to simulate a fairly pure NetBSD 4.0 release environment.   I use
        pkgsrc modular xord rather than the x* sets.

        With that envoronment, I see ....

=> Checking file-check results for afterstep-2.1.2nb8
ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkg:
ERROR:         /usr/pkg/share/afterstep/doc/html/data/animate.html
ERROR:         /usr/pkg/share/afterstep/doc/html/data/autoexec.html
ERROR:         /usr/pkg/share/afterstep/doc/html/data/background.jpg
ERROR:         /usr/pkg/share/afterstep/doc/html/data/backgrounds/Cell.html
ERROR:         /usr/pkg/share/afterstep/doc/html/data/backgrounds/Cell.png
ERROR:         /usr/pkg/share/afterstep/doc/html/data/backgrounds/Cell_Colored.h

        and about another 1800 similar lines (all afterstep/doc/html/data/*
        I think, but I did not examine ever line...)

        Of course there was also (earlier) ...

pkg_create: can't stat `/usr/pkg/share/afterstep/doc/html/data/animate.html'

        and

pkg_admin: afterstep-2.1.2nb8: File 
`/usr/pkg/share/afterstep/doc/html/data/animate.html' is in +CONTENTS but not 
on filesystem!

        warnings (for all the same files, it appears) during the install
        phase, and then when the db is being built.

        The only references to "animate.html" that I can find in the build
        log are those 3 lines (ie: I see nothing saying that any attempt
        to build it, or to install it, failed).

        afterstep-2.1.2nb7 built OK for me (I do not recall if that one
        attempted to contact the X server during the buyild), and I believe
        the only change from nb7 to nb8 was the revbump caused by the
        jpeg library change (and I doubt very much that anything related to
        jpeg is relevant here) - but afterstep last needed to be rebuilt
        (for me) back in November 2008.

        This suggests that the problem has been caused by some other changes
        to the build environment in the interim.   There are two possibilities
        (since NetBSD 4.0 release certainly has not changed).   Either some
        other package has altered in a way that is incompatible with the way
        the afterstep build process uses it (which would be my guess), or
        perhaps for this build I did not have something installed that
        happened to be installed by accident last time (that is, a missing
        build dependency perhaps) - I am now being more rigorous in
        starting each build in a fairly clean environment than I was a
        year ago.

        I have the complete build log (700Kb approx) if anyone really
        needs to see it (and I should be able to generate it again if
        I happen to lose this one - it is just a file in /tmp ...)

>Fix: