Re: 'state_not_recoverable' is not a member of 'std::errc' on clang build (was: clang-13.0.1nb1 build from pkgsrc 2022Q2 fails on NetBSD-9.2_STABLE (2022-07-01))

[Matthias Petermann <mp%petermann-it.de@localhost>]

Hi Nia,

On 16.07.22 20:29, Matthias Petermann wrote:
> 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

I just rebuilt my build sandbox. For now I need to stay in my default 
scheme and just tried to apply the libkver handling according to your 
script which was very helpful. Anyway - I got stuck with an issue for 
which I don't see exactly how this is solved in the script (probably I 
just did not understand it well enough).

What I basically did:

 1. Create sandbox
 2. Install pkgsrc to sandbox
 2. Enter sandbox via chroot
 3. Bootstrap pbulk within the sandbox
 4. Build and install libkver within the sandbox (pkg_info shows the 
package after this step)
 5. Run pbulk/bulkbuild:
    # env LD_PRELOAD=/usr/pkg/lib/libkver.so 
LIBKVER_OSRELEASE=9.2_STABLE /usr/pbulk/bin/bulkbuild

During step 5, it seems that the libkver pkg gets removed and ultimately 
the library cannot be loaded.

Is there any specific measure that you took in your script to prevent that?

Kind regards
Matthias

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature