<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">You ever have a problem so weird that you google the error message and only find one hit on the internet for that error message, and it's an unanswered question?  And then upon further inspection, you discovered that you yourself were the one to ask that question last year and then totally forget about the problem?  Yea...<div><br></div><div>So I hit this again and googled "Error Code: gpg_key_id_filter_failure", to discover this mail list thread.  Currently it's happening for me on EPEL 7:</div><div><br></div><div><div>Operations:       sync</div><div>Resources:        EPEL7 (repository)</div><div>State:            Running</div><div>Start Time:       2019-02-19T19:45:17Z</div><div>Finish Time:      Incomplete</div><div>Result:           Incomplete</div><div>Task Id:          4afc0219-0cc7-4828-b851-626ec89de9a3</div><div>Worker Name:      <a href="mailto:reserved_resource_worker-2@pulpserver.college.edu">reserved_resource_worker-2@pulpserver.college.edu</a></div><div>Progress Report:  </div><div>  Yum Importer: </div><div>    Comps:            </div><div>      State: FINISHED</div><div>    Content:          </div><div>      Details:       </div><div>        Drpm Done:  1</div><div>        Drpm Total: 1</div><div>        Rpm Done:   0</div><div>        Rpm Total:  0</div><div>      Error Details: </div><div>        Error Code: gpg_key_id_filter_failure</div><div>        Name:       drpms/perl-DBIx-QueryLog-0.41-1.el7_0.42-1.el7.noarch.drpm</div></div><div><br></div><div>I dug into the docs a bit more and was hoping this recipe would help but alas, no it does not.  <a href="https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html#sync-a-repo-with-gpg-key-id-filtering">https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html#sync-a-repo-with-gpg-key-id-filtering</a></div><div><br></div><div>So I have no idea what is going on.  I've tried changing mirrors to no avail.  The key of the RPM in question seems OK via 'rpm -K perl-DBIx-QueryLog-0.41-1.el7_0.42-1.el7.noarch.drpm'  </div><div><br></div><div>I'm pretty close at this point to chalking it up to our enterprise proxy appliance (BlueCoat), which sometimes mangles things.  </div><div><br></div><div> - Kodiak</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 21, 2018 at 7:54 AM Kodiak Firesmith <<a href="mailto:kfiresmith@gmail.com">kfiresmith@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Folks,</div><div>So we're not setting anything related to GPG key IDs for YUM repodata, yet for a single package on a single upstream Red Hat CDN channel, we're getting tracebacks each time a sync is run that seem to be rooted in this error:</div><div><br></div><div>Progress Report:<br>  Yum Importer:<br>    Comps:<br>      State: FINISHED<br>    Content:<br>      Details:<br>        Drpm Done:  0<br>        Drpm Total: 0<br>        Rpm Done:   1<br>        Rpm Total:  1<br>      Error Details:<br>        Error Code: gpg_key_id_filter_failure<br>        Name:       perl-gettext-1.05-28.el7.x86_64.rpm<br>      Items Left:    0<br>      Items Total:   1<br>      Size Left:     0<br>      Size Total:    22028<br>      State:         FINISHED<br></div><div><br></div><div>The CDN path is "<a href="https://cdn.redhat.com/content/dist/rhel/workstation/7/7Workstation/x86_64/os" target="_blank">https://cdn.redhat.com/content/dist/rhel/workstation/7/7Workstation/x86_64/os</a>", and I'm guessing this should be widely and universally repeatable.  <br></div><div><br></div><div>I can file a story about this on the bug list but I'm not sure I'll be able to adequately describe the problem since I don't really understand the inner workings of this feature.  <br></div><div><br></div><div>I think we essentially have two problems related to this:</div><div> - Repo sync jobs traceback when this is encountered - it would probably be better to catch the error than to just trace out.</div><div> - Something is funky with a single package on a single Red Hat CDN channel and should probably be remedied by the folks who manage CDN.</div><div><br></div><div>Currently running 2.16.3 - apologies if the traceback has been fixed in current release - I couldn't find this exact issue in the bug tracker so I wasn't sure if it had been seen before.<br></div><div><br></div><div>Thanks!<br></div></div></div></div>
</blockquote></div>