On Tue, Apr 26, 2011 at 04:40:48PM +0700, bearwere wrote:
> File path mismatch:
> /var/satellite/redhat/1/0ef/xalan-j2-javadoc/2.7.0-6jpp.1/i386/0ef89afa8c0dda990655983243a8eaf6/xalan-j2-javadoc-2.7.0-6jpp.1.i386.rpm
> (evr: 0:2.7.0-6jpp.1 vs. 2.7.0-6jpp.1)
> File path mismatch:
> /var/satellite/redhat/1/549/axis/1.2.1-2jpp.6/i386/5498cf48b2b87ef10b23359dd17a1959/axis-1.2.1-2jpp.6.i386.rpm
> (evr: 0:1.2.1-2jpp.6 vs. 1.2.1-2jpp.6)
> File path mismatch:
> /var/satellite/redhat/1/2a7/jakarta-commons-lang-javadoc/2.1-5jpp.1/i386/2a7a1e09296290a143be8dc1e1a48e51/jakarta-commons-lang-javadoc-2.1-5jpp.1.i386.rpm
> (evr: 0:2.1-5jpp.1 vs. 2.1-5jpp.1)
> File path mismatch:
> /var/satellite/redhat/1/e28/wpa_supplicant/0.5.10-9.el5/i386/e2839ad90ea8c4a7fc0db6bae8b79a03/wpa_supplicant-0.5.10-9.el5.i386.rpm
> (evr: 1:0.5.10-9.el5 vs. 0.5.10-9.el5)
> File path mismatch:
> /var/satellite/redhat/1/a4a/bsf/2.3.0-11jpp.1/i386/a4ad7f3438ad450c0b77744b9ef7fe21/bsf-2.3.0-11jpp.1.i386.rpm
> (evr: 0:2.3.0-11jpp.1 vs. 2.3.0-11jpp.1)
> File path mismatch:
> /var/satellite/redhat/1/160/arpwatch/2.1a13-22.el5/i386/1608454c01e8be14924c26efd5d8a860/arpwatch-2.1a13-22.el5.i386.rpm
> (evr: 14:2.1a13-22.el5 vs. 2.1a13-22.el5)
> File path mismatch:
> /var/satellite/redhat/1/9e1/kdelibs-apidocs/3.5.4-25.el5.centos.1/i386/9e10d4c1ba5770f61a9a415d302663f7/kdelibs-apidocs-3.5.4-25.el5.centos.1.i386.rpm
> (evr: 6:3.5.4-25.el5.centos.1 vs. 3.5.4-25.el5.centos.1)
Michael,
the issue reported by spacewalk-data-fsck is about missing epoch in
that path segment.
I did some checks and found out that when you rhnpush or
spacewalk-repo-sync packages, the epoch is not in the path. When
you satellite-sync (a channel dump), the epoch is there.
Since spacewalk-data-fsck expects the epoch to be there, it seems like
rhnpush and spacewalk-repo-sync are wrong here and would need to be
fixed to include the epoch.
It seems like
diff --git a/backend/server/rhnPackageUpload.py
b/backend/server/rhnPackageUpload.py
index c099b1d..fb93e89 100644
--- a/backend/server/rhnPackageUpload.py
+++ b/backend/server/rhnPackageUpload.py
@@ -115,7 +115,7 @@ def relative_path_from_nevra(nevra, org_id,
package_type=None, checksum_type=Non
is_source = 0
log_debug(4, nevra, is_source)
return get_package_path(nevra, org_id=org_id, source=is_source,
- prepend=CFG.PREPENDED_DIR, omit_epoch=1, package_type=package_type,
+ prepend=CFG.PREPENDED_DIR, omit_epoch=None, package_type=package_type,
checksum_type=checksum_type, checksum=checksum)
# bug #161989 - get the relative path from the nevra, but omit the package name
could be used to address the problem but I'd like to get your
opinion about potential side-effects of such a change.
Thanks,
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
