#7637 updates debuginfo repos not available for ppc64le
Closed: Fixed 4 years ago by syeghiay. Opened 5 years ago by sharkcz.

  • Describe the issue
    Mirrormanager doesn't return any repo for updates (and updates-testing) debuginfos for the F-28 ppc64le. After checking with "curl", debuginfo repos exists for all arches, except ppc64le.
curl 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-debug-f28&arch=ppc64le'
...
# repo=updates-released-debug-f28&arch=aarch64
# repo=updates-released-debug-f28&arch=armhfp
# repo=updates-released-debug-f28&arch=i386
# repo=updates-released-debug-f28&arch=ppc64
# repo=updates-released-debug-f28&arch=s390x
# repo=updates-released-debug-f28&arch=x86_64
...
  • When do you need this? (YYYY/MM/DD)
    ASAP

  • When is this no longer needed or useful? (YYYY/MM/DD)
    N/A

  • If we cannot complete your request, what is the impact?
    Bad user experience on F-28 ppc64le.

CC: @adrian


I cannot close it, but it is fixed now. That was the last debug repository still pointing to the 'other' debug directory (for updates-released at least). With F28 mirrormanager was pointing to many wrong debug directories as there were partially duplicate repodata directories.

Thanks, it works as expected now.

Metadata Update from @sharkcz:
- Issue close_status updated to: Fixed

5 years ago

note that I'm seeing the same issue currently with aarch64.. and same as original issue, I see:

# repo=updates-released-debug-f28&arch=aarch64

Metadata Update from @sharkcz:
- Issue status updated to: Open (was: Closed)

5 years ago

seems updates-tetsing debuginfo repo for ppc64le isn't available (again?)

curl 'https://mirrors.fedoraproject.org/metalink?repo=updates-testing-debug-f28&arch=ppc64le'

returns an empty list while there is one for ppc64

@rclark : The one you mention (repo=updates-released-debug-f28&arch=aarch64) works for me, so not sure what is happening there.

@sharkcz : I also fixed updates-testing now. updates-released from your original report still looks correct. The fix for updates-testing should be visible in one (maybe two) hour(s).

@rclark : Any additional information you could share about the exact URL that results in the error you see?

@rclark : Any additional information you could share about the exact URL that results in the error you see?

metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide-debug&arch=$basearch

or

wget "https://mirrors.fedoraproject.org/metalink?repo=rawhide-debug&arch=aarch64"

@sharkcz : I also fixed updates-testing now. updates-released from your original report still looks correct. The fix for updates-testing should be visible in one (maybe two) hour(s).

it's working now, thanks

@rclark : Any additional information you could share about the exact URL that results in the error you see?

metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide-debug&arch=$basearch

or
wget "https://mirrors.fedoraproject.org/metalink?repo=rawhide-debug&arch=aarch64"

Ah, rawhide-debug. I also fixed it in the database. Fixes should be live in about 30 or 90 minutes.

Ah, rawhide-debug. I also fixed it in the database. Fixes should be live in about 30 or 90 minutes.

thx, seems to be working now

@adrian do you think this was caused by move-devel-to-release on f28?

@kevin which one? The rawhide-debug or the updates-debug? As you mention f28 I guess the updates-*-debug problem.

The main problem as far as I understand it right now is, that with F28 there were multiple debug repositories available, which have now been cleaned up. If I remember it correctly there was one initially at 'architecture/debug/tree/repodata'. It had a repomd.xml file but was actually empty.
Later when F28 was released the debug packages started to appear at 'architecture/debug/repodata'. As mirrormanager uses repodata/repomd.xml to detect a repository the repository was already created and pointing to the wrong repository. As that repository was not existing the new and actually populated repository was ignored. This was happening with F28 the first time and I had to do cleanups everywhere in the database. Somebody deleted the wrong repositories (I think @puiterwijk) and I also reported it here:

https://pagure.io/releng/issue/7501

Looking at the solution of #7501 I think it was not clear what I was trying to report. The whole debug repository layout was a great mess from MirrorManager's point of view during F28 and I hope it is fixed for F29.

The reason why ppc64le was not fixed could be that my cleanup SQL commands did not handle ppc64 and ppc64le correctly. Those are the only two architectures which start with the same string, so maybe some scripting error during the cleanup.

It was definitely not move-devel-to-release as it does not change any 'updates*' repositories (unless the script is totally broken).

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

5 years ago

Metadata Update from @sharkcz:
- Issue status updated to: Open (was: Closed)

5 years ago

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

5 years ago

Metadata Update from @sharkcz:
- Issue status updated to: Open (was: Closed)

5 years ago

This has been fixed. Closing.

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

4 years ago

Login to comment on this ticket.

Metadata