Hi Kodiak, I personally don't recall any recent changes with regards to the DRPM handling. I tested DRPMs download for https://dl.fedoraproject.org/pub/epel/7/x86_64/ <https://dl.fedoraproject.org/pub/epel/7/x86_64/drpms/> on the 2.18.1 and on 2.16.3, no failures in both cases. I didn't sync the whole repo and used '--skip rpm' to sync drpms only. Now I'm trying to sync the whole repo including RPMs, just in case it makes a difference, it will take a while (I assume you use immediate download policy since I expect error that you see to happen upon download of a package).
For further investigation it would be helpful if you could create an upstream issue and provide steps to reproduce it + share your importer config. https://pulp.plan.io/projects/pulp_rpm/issues/new Thank you, Tanya On Fri, Feb 22, 2019 at 3:27 PM Kodiak Firesmith <[email protected]> wrote: > Thanks Tatiana, > The upstream state of > https://dl.fedoraproject.org/pub/epel/7/x86_64/drpms/ has changed and now > instead of 1 drpm available in EPEL7, I'm seeing 30+ packages. They all > seem to fail with the same gpg_key_id_filter_failure. Perhaps Pulp 2.16.3 > just doesn't handle DRPMs well. Anyone know off-hand if any enhancements > to the RPM importers related to DRPMs have happened between my version and > current? Would be a good excuse to make time to upgrade. > > Thanks! > - Kodiak > > On Wed, Feb 20, 2019 at 12:00 PM Tatiana Tereshchenko <[email protected]> > wrote: > >> Hi Kodiak, >> >> I took a look at the code and I agree that it's a surprising and weird >> error for your case, I didn't spot anything suspicious. >> Can you please file an issue and post there your importer config and the >> task report (the one you mentioned in the e-mail) and if you use >> pulp-admin, please do put -vvv after pulp-admin so more details would be >> visible from API calls. >> If you have anything relevant in the logs, please attach it to the issue, >> sometimes in logs there is more information than in the task report. >> >> https://pulp.plan.io/projects/pulp_rpm/issues/new >> >> Thank you, >> Tanya >> >> >> >> On Tue, Feb 19, 2019 at 9:10 PM Kodiak Firesmith <[email protected]> >> wrote: >> >>> 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... >>> >>> 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: >>> >>> Operations: sync >>> Resources: EPEL7 (repository) >>> State: Running >>> Start Time: 2019-02-19T19:45:17Z >>> Finish Time: Incomplete >>> Result: Incomplete >>> Task Id: 4afc0219-0cc7-4828-b851-626ec89de9a3 >>> Worker Name: [email protected] >>> Progress Report: >>> Yum Importer: >>> Comps: >>> State: FINISHED >>> Content: >>> Details: >>> Drpm Done: 1 >>> Drpm Total: 1 >>> Rpm Done: 0 >>> Rpm Total: 0 >>> Error Details: >>> Error Code: gpg_key_id_filter_failure >>> Name: >>> drpms/perl-DBIx-QueryLog-0.41-1.el7_0.42-1.el7.noarch.drpm >>> >>> I dug into the docs a bit more and was hoping this recipe would help but >>> alas, no it does not. >>> https://docs.pulpproject.org/plugins/pulp_rpm/user-guide/recipes.html#sync-a-repo-with-gpg-key-id-filtering >>> >>> 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' >>> >>> I'm pretty close at this point to chalking it up to our enterprise proxy >>> appliance (BlueCoat), which sometimes mangles things. >>> >>> - Kodiak >>> >>> On Wed, Nov 21, 2018 at 7:54 AM Kodiak Firesmith <[email protected]> >>> wrote: >>> >>>> Hi Folks, >>>> 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: >>>> >>>> Progress Report: >>>> Yum Importer: >>>> Comps: >>>> State: FINISHED >>>> Content: >>>> Details: >>>> Drpm Done: 0 >>>> Drpm Total: 0 >>>> Rpm Done: 1 >>>> Rpm Total: 1 >>>> Error Details: >>>> Error Code: gpg_key_id_filter_failure >>>> Name: perl-gettext-1.05-28.el7.x86_64.rpm >>>> Items Left: 0 >>>> Items Total: 1 >>>> Size Left: 0 >>>> Size Total: 22028 >>>> State: FINISHED >>>> >>>> The CDN path is " >>>> https://cdn.redhat.com/content/dist/rhel/workstation/7/7Workstation/x86_64/os";, >>>> and I'm guessing this should be widely and universally repeatable. >>>> >>>> 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. >>>> >>>> I think we essentially have two problems related to this: >>>> - Repo sync jobs traceback when this is encountered - it would >>>> probably be better to catch the error than to just trace out. >>>> - 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. >>>> >>>> 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. >>>> >>>> Thanks! >>>> >>> _______________________________________________ >>> Pulp-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-list >> >>
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
