the following message when trying to update
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
any workaround?
+1 same issue, ongoing several hours
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
Same here!
Same here as well.
Try some other mirror?
Already tried widehat with the same result as with download
+1
[FONT=courier new]Retrieving repository ‘openSUSE-Tumbleweed OSS’ metadata ----------------------------------------/]
File ‘./repodata/a8542a7b35e96dad2d79bacc5f1d307ddace9cff19317893cf1269eb0238d9d2-appdata-icons.tar.gz’
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.
[/FONT]
–rncbc
got away by replacing:
http://download.opensuse.org/tumbleweed/repo/oss/
by one of the mirrors (picked at random):
http://mirror.23media.de/opensuse/tumbleweed/repo/oss/
–rncbc
Thanks!
List of mirrors: https://mirrors.opensuse.org/
A reply from Dimstar at the opensuse-factory@o.o 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.
cheers
Dominique
So, using some mirror only works around the issue if that mirror is outsdated.
And here’s Dimstar’s next reply
Good news:
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)
Background:
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.
Cheers,
Dominique
thanks goes to those involved,
all is now back in order, 7May2018