Re: Failure to build "current" emacs from pkgsrc on current

[Greg Troxel <gdt%lexort.com@localhost>]

Riccardo Mottola <riccardo.mottola%libero.it@localhost> writes:

> Hi Greg,
>
> Greg Troxel wrote:
>>
>> Yes, but it can hit an error and exit without finishing.
>>
>> So I would run it again and see if it reports that there's nothing to
>> do.
>
> I did re-run it and it breaks out in the same place!

That in general isn't a good way to use pkg_rr.  Without -k, it will
stop on error.  Then, my approach is to either 1) fix the package so it
doesn't error, 2) use -X to exclude rebuilding it, or 3) add -k.

The only real reasons not to use -k are:
  - fear of things going badly if many things fail (not really an issue)
  - wanting to fix things along the way, e.g. getting ready for a branch
  - not wanting to rebuild things multiple times after something
    succeeds later (if you use ccache, it's not that big a deal)

So until pkg_rr has finished all the way and you are aware of what if
anything didn't work, things may be in an inconsistent state.

>> On netbsd-7 amd64, 2018Q3:
>>
>>> nm -u /usr/pkg/lib/libgdk-3.so|egrep glx
>> U epoxy_glx_version
>> U epoxy_has_glx_extension
>
> $ nm -u /usr/pkg/lib/libgdk-3.so|egrep glx
>                  U epoxy_glx_version
>                  U epoxy_has_glx
>                  U epoxy_has_glx_extension

That explains the error, and now to explain the symbol's presence...

>>                                   that looks like you got an
>> in-progress addition and the usual python
>> default vs 36/37 pkg_chk issue.  not really concerning.
>
> Ok, I'll hope it will go away when pkg_rolling-replace finishes.

Well, they won't.  With python, there is a default version, usually 27,
and  more and more things are using 36 or 37.  What's needed is a way to
report that foo/py-bar needs rebuilding for PYPREFIX 27 and 36, and so
far between how pkg_chk behaves and how pkg_rr behaves that doesn't work
well. python packages for the default python version get replaced ok.
And this almost certainly is not related to your epoxy problem.

>> 2) to make sure you have no old headers that don't belong, in
>> /usr/include, /usr/X11R*/include, or /usr/pkg/include.  Use find with
>> ctime to find .h files not written during update, and pkg_admin check to
>> look at file checksums vs installed, and then find /usr/pkg -atime +7 to
>> find files not read by pkg_admin check and investigate.
>
> something that did not upgrade during system update? hmm here I don't
> follow you exactly what to find though.

System updating adds the new version of files, for files that are in the
new version.  There is an obsolete mechanism that "postinstall fix"
invokes that will remove some old files.

However, I have found over the years (I have been running NetBSD since
0.8) that sometimes depending on the upgrade sequence there are header
files that are not part of the current install and are left over
somehow, and I have found this to cause problems.  So when things go
badly, I tend to look at all the .h files and be sure that they are only
the set that should be installed, and clean up cruft.  After an install,
the ctime of each is modified, so find with -ctime can find files that
haven't been modified in years.  Old libraries should be ok, but old .h
files are possibly trouble (we support old ABI, but not API).