An error occurred during repository initialization. ‘repo-oss’: [repo-oss|http://download.opensuse.org:80/tumbleweed/repo/oss/]
Valid metadata not found at specified URL History: - ABORT request: Aborting requested by user - Can’t provide ./repodata/a8542a7b35e96dad2d79bacc5f1d307ddace9cff19317893cf1269eb0238d9d2-appdata-icons.tar.gz
File ‘./repodata/a8542a7b35e96dad2d79bacc5f1d307ddace9cff19317893cf1269eb0238d9d2-appdata-icons.tar.gz’ not found on medium ‘http://download.opensuse.org/tumbleweed/repo/oss/’
Repository ‘openSUSE-Tumbleweed-Oss’ is invalid.
[repo-oss|http://download.opensuse.org/tumbleweed/repo/oss/] Valid metadata not found at specified URL
[FONT=courier new]Retrieving repository ‘openSUSE-Tumbleweed OSS’ metadata ----------------------------------------/]
not found on medium ‘http://download.opensuse.org/tumbleweed/repo/oss/’
**Abort, retry, ignore? [a/r/i/…? shows all options] (a): **
Retrieving repository ‘openSUSE-Tumbleweed OSS’ metadata …[error]
Repository ‘openSUSE-Tumbleweed OSS’ is invalid.
[tumbleweed-oss|http://download.opensuse.org/tumbleweed/repo/oss/] Valid metadata not found at specified URL
Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository ‘openSUSE-Tumbleweed OSS’ because of the above error.
A reply from Dimstar at the firstname.lastname@example.org ML where the issue described was reported as well:
Hi All - we’re currently looking into this issue. That file did existat one point (which is why it is totally correclty registered in the
repo metadata) but got ‘lost’ on the server(s) - this is not a mirror
issue, but comes from the central infra directly. Hope to be able to
get you more information about this issue soon.
So, using some mirror only works around the issue if that mirror is outsdated.
together with Ludwig Nussel the issue has been analyzed, identified and
fixed - the repo should thus be working again (some openQA tests
already confirmed it being ok again)
The script in use, that allows us to retain obsolete files once a new
snapshot comes out (mainly used to keep the old RPMs around for
immediate downgrades) was getting confused because the AppStream icon
tarball had a name switch in one of the snapshots (so FOO->BAR->FOO).
This is something that CAN happen (mainly happens when two packages
provide the same application/icons - and the data flips between the two
packages). The script thus knew that after the name changed to BAR, it
could drop FOO, but missed the fact that FOO re-appeared later on in
the FTP tree.
This was further enhanced in the code to ensure the remover won’t drop
stuff that is supposed to exist in the target tree, even though it was
marked earlier for removal.