Hello Nia, On 16.07.22 11:51, nia wrote:
On Sat, Jul 16, 2022 at 09:49:04AM +0000, nia wrote:On Sat, Jul 16, 2022 at 07:55:25AM +0200, Matthias Petermann wrote:So hopefully my concern sounds a little more concrete now: Is it possible that _GLIBCXX_HAVE_ENOTRECOVERABLE is not defined in the scenario described in the boundary conditions, and what are the possible reasons for this? Could it be that due to the fact that my NetBSD 9.2 sandbox is running on a NetBSD 9.99.98 kernel, a decision is made at some point in a build (such as a dependent package?) that leads to this? The list of installed dependencies on the affected sandbox are:The problem is that your NetBSD 9 sandbox identifies as NetBSD 9.99 in uname, so the check to enable the fix for this problem fails. If you have a different NetBSD version in a chroot, you need to use pkgtools/libkver to fix the kernel version. If you're using pbulk, I have some tools to help with this.If you don't want to use libkver, it looks like it's possible to override OPSYS_VERSION in mk.conf - but this is very hacky.
thank you - I had hoped that it is something like that. libkver was still on my TODO list - to the topic I had already asked here in the past and got good answers. At that time my main concern was that pkgin complains if the version of the installation target does not match the version of the builder. This I "worked around" until now by ignoring the warning. I was not aware that the version also influences the internals of the build. I think I will finally rebuild my builder and try out your pbulk script.
Kind regards Matthias
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature