In the past several RPMs have built successfully, however failed during a koji gpg key verification stage. An example of this is dbus on slc6. If this happens the error message that koji shows is:
```<class '_rpm.error'>: public key not available```
The above rpm verification process runs on on a kojihub server rather than the builder.
This specific issue was due to missing selinux policy preventing httpd to access the rpmdb. The following fix will prevent this issue from happening in the future: [https://gitlab.cern.ch/ai/it-puppet-module-koji/merge_requests/7](https://gitlab.cern.ch/ai/it-puppet-module-koji/merge_requests/7)
If you encounter similar issues in the future, you may wish to temporarily configure selinux to permissive mode to confirm that additional policy is potentially required.
## building manually slc6 python
Python in the past has not built successfully on scl6 via koji. The cause is not fully understood however is likely a combination of us running koji builders as root and only on cc7. Should python fail to build, the following steps can be taken:
1. add a 'build' user on a scl6 VM, that has sudo access (or the root password is known)
2. add a ``~/mock.cfg`` from ``build@lxsoftadm01:~/modules/config/slc6-x64_64$RECENT-KERNEL.cfg``
3. in ``~/mock.cfg`` change config_opts['dist'] to be 'el6_10' and config_opts['macros']['%dist'] to be '.el6_10'
4. copy the src rpm to ``~``
5. init mock with ``mock -r mock.cfg --init``
6. build the rpm with ``mock -r mock.cfg --no-clean --target x86_64 --rebuild python-$VERSIONsrc.rpm``
7. reset the failed build in koji ``koji call resetBuild python-$VERSION.$DISTTAG``. This command will change the state in koji for this build from 'failed' to 'cancelled'
8. recreate the build in koji ``koji call --python createEmptyBuild "'$PACKAGE'" "'$VERSION'" "'$DISTTAG'" None``. This will change the state in koji of this build from 'cancelled' to 'complete'
9. add the built RPMs to koji ``koji import *rpm``
10. tag the build correctly ``koji tag-build $DIST $PACKAGE-$VERSION-$DISTTAG``
11. continue with bsdownload process
## Revert publishing a test rpm
If you got a test rpm into the testing directories by mistake, no worries, this can be reverted. This can happen for example when a `nss` package cannot still be rebuilt because source RPMs are still not published, therefore this package cannot be published to testing **yet**.
Testing repositories will be under `/mnt/data2/dist/cern/centos/7.7.1908/updates-testing/x86_64/Packages` and `/mnt/data2/dist/cern/centos/7.7.1908/updates-testing/Source/SPackages`. Change version (`7.7.1908`) and repo (`updates-testing`) as needed.
1. Take a look at `bstest2fail`, it should help you revert all changes to a testing repo. If it doesn't work or you only want to revert some RPMs, read on:
1. Delete the corresponding RPM from those two directories
1. Define the REPOLIST, **including the repo for the repositories you removed**: `REPOLIST="cern-testing updates-testing"`
1. Regenrate the repo metadata: `/mnt/data2/home/build/bin/bsregenrepos -d cc7 -r "$REPOLIST"`
1. Rerun `bssync` if you had already run it before
1. Next time you start the procedure, the deleted packages will get into the usual pipeline
1. Be aware you might need to change the email body removing the package you just removed, before notifying users