#1639 sigkey always empty in ``rpm.sign`` notifications
Closed: Invalid 4 years ago by pingou. Opened 4 years ago by pingou.

The Fedora infrastructure is no longer able to publish notifications about package being signed. Since we moved the notifications system from fedmsg to fedora-messaging we original thought this was related. However, with more investigation we found out that the payload that is passed to the plugin seems to always have the sigkey field unspecified (or to be precise, it is an empty string).

We're reaching out to see if you could help us figure out if this is a bug in koji or in our plugin or in something else that we are missing.

You can find the reasoning and debugging information that led us to open this ticket in: https://pagure.io/fedora-infrastructure/issue/8158#comment-595038

Thanks in advance for your help :)


@pingou I've asked @breilly to take a look. In the meantime, I'm not aware of any changes recently in Koji related to this. Was the sigkey field an empty string before or is that new behavior?

Metadata Update from @dgregor:
- Custom field Size adjusted to None

4 years ago

Metadata Update from @dgregor:
- Issue priority set to: High (was: Normal)

4 years ago

Was the sigkey field an empty string before or is that new behavior?

Looking at the comment in the fedmsg plugin it seems it was empty sometime but not all the time (basically, for each rpm signed it was sending two notifications, one of which had an empty sigkey field which we were filtering out and thus only sending one notification per rpm).

@pingou
Right. koji treats unsigned rpm as signed by <emptystr>
But it looks fedmsg-koji-plugin doesn't filter off such kind of event

protonmsg plugin for fedmsg does have that cut-out

BTW, the two notifications are for different rpms(one for src.rpm, another for noarch.rpm)

@julian8628 so does this appear to be a bug in Koji?

@dgregor I haven't got a clue yet.
I tested newest fedmsg-koji-plugin on my local with koji1.18. It worked as expected

@pingou
Is there any changes of fedmsg-koji-plugin on stage against pagure master branch?
And what koji-hub version is on stage?

We run koji-1.18.0-3.el7.noarch in stage and the fedmsg/fedora-messaging plugin is in sync w/ what is on pagure.io :(

@julian8628 I know you spent some time on this and contacted us for some help to debug it.
Did you manage to find something? Could we help you debug some more?

@julian8628 I'll ping @kevin when he wakes up as I fear the logs are gone now :(

I can try and gather what you need, but it's not clear to me what you want... what log?

@kevin The httpd log in /var/log/httpd/error_log
I'm not sure if the old log still exists, so maybe you could try to sign some build firstly.

@kevin The httpd log in /var/log/httpd/error_log
I'm not sure if the old log still exists, so maybe you could try to sign some build firstly.

I have pasted the error_log from koji in staging, but i am not sure if there was asigned build there.

https://paste.fedoraproject.org/paste/VOVkoDK5aPuz4hNXfuHMjA

There's no signing action today. Could you please try a tag/untag operation against an unsigned build according to https://pagure.io/fedora-infrastructure/issue/8158#comment-597010, and then send the log again?
It's better to enable debug for hub by adding KojiDebug = On in /etc/koji-hub/hub.conf and service httpd reload before doing that

So we found a bug in our fedmsg-koji-plugin that lead to the messages not being sent.
We've fixed it and the messages are showing again.

I'm going to close this ticket as Invalid, sorry for the time lost but many thanks for your help! :)

One thing that would have helped us debug this is having a way in koji to configure python's logging module. As we log the error message we would have seen them in the logs immediately instead of having to spend quite some time trying to figure things out until we ended up adding the print statements that gave us the clue.
Should I open a new ticket for this RFE?

Metadata Update from @pingou:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

4 years ago

@pingou - yes, please (it will be buried here otherwise)

Login to comment on this ticket.

Metadata