Project

Profile

Help

Issue #8162

syncing a repo with an erratum without an updated date results in a bad date in published metadata

Added by jsherril@redhat.com 12 months ago. Updated 4 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Katello
Sprint:
Sprint 89
Quarter:

Description

  1. create a repo and remote pointing to https://fixtures.pulpproject.org/rpm-advisory-no-update-date/repodata/
  2. sync the remote, create a publication and distribution
  3. examine the repodata, look for the Bird erratum section of the updateinfo xml:
  <update from="errata@redhat.com" status="stable" type="security" version="1">
    <id>RHEA-2012:0056</id>
    <title>Bird_Erratum</title>
    <issued date="2013-01-27 16:08:08"/>
    <updated date="0693-02-18 07:00:00"/>

Note that the date is nonsense. this causes an issue for things trying to consumer this date, such as katello or another pulp server trying to sync


Related issues

Related to RPM Support - Issue #6133: pulp_rpm synchronization failure: day is out of range for monthCLOSED - WORKSFORME<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 84342df6 View on GitHub
Added by dalley 12 months ago

Migration to fix some bad updated_date data on advisories

[nocoverage]

closes: #8162 https://pulp.plan.io/issues/8162

History

#1 Updated by dalley 12 months ago

@Justin, do we know of any repositories in the wild where the updated_date field doesn't exist? Basically, is it valid or malformed repodata?

I did some testing and found that while there are deficiencies in Pulp that we can fix, they are not actually the cause of this problem. It looks like createrepo_c has problems with this. I wrote modified one of the createrepo_c test cases and printed the resulting XML and I found the exact same problem.

  <update from="from" status="status" type="type" version="version">
    <id>id</id>
    <title>title</title>
    <issued date="2021-01-28 00:59:17"/>
    <updated date="6449-03-17 07:00:00"/>
    <rights>rights</rights>
    <release>release</release>
    <pushcount>pushcount</pushcount>
    <severity>severity</severity>
    <summary>summary</summary>
    <description>description</description>
    <solution>solution</solution>
    <reboot_suggested>True</reboot_suggested>
    <references/>
    <pkglist/>
  </update>

You can see that even though they check whether it's a datetime type or None, they don't actually handle the case where it is None.

https://github.com/rpm-software-management/createrepo_c/blob/master/src/python/updaterecord-py.c#L401-L416

If it's valid metadata, the next step would be to file a BZ with createrepo_c.

#2 Updated by dalley 12 months ago

It looks like SUSE updateinfo is lacking this field, which makes it valid.

#3 Updated by dalley 12 months ago

  • Status changed from NEW to POST
  • Assignee set to dalley

#5 Updated by dalley 12 months ago

  • Triaged changed from No to Yes

#6 Updated by dalley 12 months ago

  • Sprint set to Sprint 89

#7 Updated by dalley 12 months ago

  • Status changed from POST to MODIFIED

#8 Updated by dalley 12 months ago

  • Sprint/Milestone set to 3.9.0

#9 Updated by pulpbot 12 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

#10 Updated by dalley 11 months ago

  • Related to Issue #6133: pulp_rpm synchronization failure: day is out of range for month added

Also available in: Atom PDF