On Apr 12, 2023, at 23:52, Alexander Leidinger <alexan...@leidinger.net> wrote:
> Quoting Mark Millard <mark...@yahoo.com> (from Wed, 12 Apr 2023 22:28:13 > -0700): > >> A fair number of errors are of the form: the build >> installing a previously built package for use in the >> builder but later the builder can not find some file >> from the package's installation. > > As a data point, last year I had such issues with one particular package. It > was consistent no matter how often I was updating the ports tree. Poudriere > always failed on port X which was depending on port Y (don't remember the > names). The problem was, that port Y was build successfully but an extract of > it was not having a file it was supposed to have. IIRC I fixed the issue by > building the port Y manually, as re-building port Y with poudriere didn't > change the outcome. > > So it seems this may not be specific to the most recent ZFS version, but > could be an older issue. It may be the case that the more recent ZFS version > amplifies the problem. It can also be that it is related to a specific use > case in poudriere. In my procedure I'm building the same versions of the same ports that I'd built in the pre-ZFS-import context, just in my jail for experiments instead of in the jail for normal use. (So I still have the original package files available.) I am working a distinct media that started as a copy of my good context. In other words, I was reporting differences with the known-status as shown by prior builds of the same /usr/ports/ tree. The difference is just my progressing FreeBSD's version. I'm even using the exact same machine to do the builds, but with distinct media. (My good environment's FreeBSD still predates the zfs import.) > I remember a recent mail which talks about poudriere failing to copy files in > resource-limited environments, see > https://lists.freebsd.org/archives/dev-commits-src-all/2023-April/025153.html > While the issue you are trying to pin-point may not be related to this > discussion, I mention it because it smells to me like we could be in a > situation where a similar combination of unrelated to each other FreeBSD > features could form a combination which triggers the issue at hand. My procedure eliminates this alternative. === Mark Millard marklmi at yahoo.com
