rhel/centos8 builder can ignore failing gpg
INFO: Signing /var/lib/mock/f32-build-yix6-6-6/result/kojitest-dummyrpm-jfqmi-1.1-11.noarch.rpm, /var/lib/mock/f32-build-yix6-6-6/result/kojitest-dummyrpm-jfqmi-1.1-11.src.rpm INFO: Executing rpmsign --addsign /var/lib/mock/f32-build-yix6-6-6/result/kojitest-dummyrpm-jfqmi-1.1-11.noarch.rpm /var/lib/mock/f32-build-yix6-6-6/result/kojitest-dummyrpm-jfqmi-1.1-11.src.rpm -D '%_gpg_name Koji Admin' -D '%_gpg_path /etc/mock/gnupg-sign' gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device error: gpg exec failed (2) gpg: signing failed: Inappropriate ioctl for device gpg: signing failed: Inappropriate ioctl for device error: gpg exec failed (2)
easiest way is to not fail on this, which looks to be same problem as https://github.com/keybase/keybase-issues/issues/2798 (not verified)
@praiskup I think, it should be fixed in mock's sign plugin? You probably have the same problem in some environments?
Metadata Update from @tkopecek: - Custom field Size adjusted to None
If you mean the fact we ignore the failure, this should help: https://github.com/rpm-software-management/mock/pull/657
If you mean the fact that there's no tty, I don't know. The sign.py plugin is used for many other tasks than just signing, and if anywhere - either the gpg should be fixed to not require tty, or rpmsign should probably run the gpg command in "batch" mode (if exists). Ideas?
+1 for not ignoring the error I now see that you're spawning it with shell=True which allows users to put export GPG_TTY=$(tty); rpm-sign into config_opts['plugin_conf']['sign_opts']['cmd']
shell=True
export GPG_TTY=$(tty); rpm-sign
config_opts['plugin_conf']['sign_opts']['cmd']
Closing on koji side.
Metadata Update from @tkopecek: - Issue untagged with: bug - Issue set to the milestone: None (was: 1.23.1)
Metadata Update from @tkopecek: - Issue close_status updated to: Dropped - Issue status updated to: Closed (was: Open)
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji/issues/2570
Please continue any further discussion there.