Addendum: I had been operating under the assumption that the keyring being disabled was intentional, and therefore attempted to disable the relevant tests: https://github.com/frozencemetery/krb5.fedora/blob/master/krb5.spec#L392-L397

This has recently stopped working.  While I would prefer full keyring enablement, fixing the copr_username macro is also needed.

(In reply to Robbie Harwood from comment #0)
> krb5 uses the kernel keyring, which comes up during the %check of our
> builds.  This works in koji, but when people (e.g., IPA, samba) try to
> rebuild krb5 in copr, it fails with:

Copr uses the `--new-chroot` mock feature (systemd-nspawn, using container
namespaces), while koji uses `--old-chroot`.  There's the difference
probably, and I think that keyrings are not yet resolved in namespaces
(bug 1138601).

(In reply to Robbie Harwood from comment #1)
> Addendum: I had been operating under the assumption that the keyring being
> disabled was intentional, and therefore attempted to disable the relevant
> tests:
> https://github.com/frozencemetery/krb5.fedora/blob/master/krb5.spec#L392-L397

Cite:
| # ugh.  COPR doesn't expose the keyring, so try to cope.
| %if 0%{?copr_username:1}
| %global keyctl :
| %else
| %global keyctl keyctl
| %endif

> This has recently stopped working.  While I would prefer full keyring
> enablement, fixing the copr_username macro is also needed.

I didn't know there was such macro defined by copr TBH.  You can work-around
by something like `if %(keyctl list @u &>/dev/null ; echo $?)` till we take a
look at this POV.

copr_username per email here: https://lists.fedorahosted.org/pipermail/copr-devel/2015-May/001198.html

I'm not finding any documentation on this, though.

Yes, no documentation, and the %copr_* macros silently disappeared and
nobody noticed.  It is hard to tell when we lost the support,
most probably in commit 3a5cd2bc754adbcfa6d56b1aae736a9e5d48fbfc.  That
commit started the era where builder doesn't get build instructions from
builder, but from frontend (by doing separate API request).

Another hack idea is to
(a) build some RPM package providing the macros in your copr, and add the
package to the minimal buildroot package set in chroot configuration, or
(b) add --with=copr_build option in chroot configuration, and adjust spec
file to that option.

I have to be honest, I did before - and I probably will consider (b) to be
clear bad habit in packaging workflow, same as adding build conditions on
some buildsystem specific macros (e.g. %copr_<something).  Some backup of
this idea:
- koji (Fedora or other instance) may anytime start using containers, and
  you'd have to face entirely the same issues there
- containers will be fixed in future so keyctl will magically start working
  even on copr builders
Both of those cases would prove that having conditionals on copr-specific
macros is bad choice.  Some feature check (be that `if %(keyctl list @u
&>/dev/null ; echo $?)`, or some keyring-dedicated macro provided by
redhat-rpm-config or so in future) sounds much better than checking for
particular buildsystem.

See the mock

(In reply to Pavel Raiskup from comment #4)
> See the mock

This is leftover, sorry.  I tried to propose some mock-specific
macros like '%mock_used 1', or '%mock_<feature> 1' and it was rejected.
I can not find this RFE now.

Alright, I'll modify the spec to take that approach, thanks,

I entirely forgot about this.  We restored the copr_* macros upon your request:
https://pagure.io/copr/copr/blob/a98b7b5370bcb5790bf0cd4c2fb353e9e1d440bd/f/rpmbuild/mock.cfg.j2#_18-19

Commit 460eae630ef0848ca3f29e620ea53d1c74eafdaa.
https://pagure.io/copr/copr/issue/1037

On top of that, you now may configure the isolation, and switch
from 'nspawn' to 'simple'.