When running update-eix-remote update on eix 0.14.1, the cache tarball it downloads appears to be using the wrong format. Reproducible: Always Steps to Reproduce: 1. update-eix-remote update 2. 3. Actual Results: Upgrade to eix 0.14.1, then update-eix && update-eix-remote update. update-eix-remote update will download the following file: http://dev.gentooexperimental.org/eix_cache/eix-caches.tbz2 Then it will provide 129 similar error messages. Error messages reduced down to the 129th message for brevity. They all look identical except for the overlay name. [129] "" (layman/zugaina) (cache: eix* /tmp/update-eix-remote.KVdHQn/1/_usr_portage_local_layman_zugaina.eix [*]) Reading 0% Cache file /tmp/update-eix-remote.KVdHQn/1/_usr_portage_local_layman_zugaina.eix uses obsolete format 27 (current is 28) Reading aborted Expected Results: [129] "" (layman/zugaina) (cache: eix* /tmp/update-eix-remote.sciBC7/1/_usr_portage_local_layman_zugaina.eix [*]) Reading 100% This appears to be less of a bug, and more of a problem with the cache tarball/database format on the overlays, but it's still something that needs to be addressed, since we can't keep ~x86 and ~x86_64/amd64 users from updating eix unless that version is masked. More intelligently, the cache tarball should, get fixed to have the correctly formatted stuff within it. Severity of major chosen, since it's impossible to update-eix-remote update without a proper cache tarball, making it impossible to query eix for anything in remote overlays. eix WILL still work for main portage tree, and installed overlays.
(In reply to comment #0) > When running update-eix-remote update on eix 0.14.1, the cache tarball it > downloads appears to be using the wrong format. > > Reproducible: Always > > Steps to Reproduce: > 1. update-eix-remote update > 2. > 3. > > Actual Results: > Upgrade to eix 0.14.1, then update-eix && update-eix-remote update. > update-eix-remote update will download the following file: > http://dev.gentooexperimental.org/eix_cache/eix-caches.tbz2 > > Then it will provide 129 similar error messages. Error messages reduced down > to the 129th message for brevity. They all look identical except for the > overlay name. > > [129] "" (layman/zugaina) (cache: eix* > /tmp/update-eix-remote.KVdHQn/1/_usr_portage_local_layman_zugaina.eix [*]) > Reading 0% > Cache file > /tmp/update-eix-remote.KVdHQn/1/_usr_portage_local_layman_zugaina.eix uses > obsolete format 27 (current is 28) > Reading aborted > > > > > Expected Results: > [129] "" (layman/zugaina) (cache: eix* > /tmp/update-eix-remote.sciBC7/1/_usr_portage_local_layman_zugaina.eix [*]) > Reading 100% > > This appears to be less of a bug, and more of a problem with the cache > tarball/database format on the overlays, but it's still something that needs to > be addressed, since we can't keep ~x86 and ~x86_64/amd64 users from updating > eix unless that version is masked. More intelligently, the cache tarball > should, get fixed to have the correctly formatted stuff within it. > > Severity of major chosen, since it's impossible to update-eix-remote update > without a proper cache tarball, making it impossible to query eix for anything > in remote overlays. eix WILL still work for main portage tree, and installed > overlays. > same for me also :-(
The remote format depends on the eix version on dev.gentooexperimental.org. As far as I understood, that server is more or less regularly upgraded to the newest testing version of eix, but perhaps only genstef did this (who is still on devaway). Once that server is upgraded to >=eix-0.14.0/1, the current format 28 will be produced.
I see this as a bug. While eix and eix-update only need to be able to handle the current format, eix-update-remote should be able to load and convert older formats. The eix database format changes quite often, and it is quite possible for overlays to be out of sync, just like they are now.
(In reply to comment #3) > and it is quite possible for overlays to be out of sync Once more: This concerns not arbitrary (user) overlays but _only_ the eix version on dev.gentooexperimental.org. When this is always kept up-to-date with the latest ~ARCH version of eix, there is no danger to get out of sync (except for a very small period when eix is in the portage tree but the server is not yet upgraded; only currently this period is longer, since apparently nobody is there to update dev.gentooexperimental.org). I will certainly not spend time to write code which is redundant after the next upgrade of dev.gentooexperimental.org.
(In reply to comment #4) > (In reply to comment #3) > I will certainly not spend time to write code which is redundant after the next > upgrade of dev.gentooexperimental.org. > A new cache was generated on dev.ge.org with: $ eix --version eix 0.14.2 (x86_64-pc-linux-gnu) I had to pull strings and I am working on getting myself access to do this myself. Hope that solves this bug. Please reopen if there is still a problem.
Same bug is now showing up in 0.13.5, however, 0.14.2 works just fine.
(In reply to comment #6) > Same bug is now showing up in 0.13.5 Older eix versions will always fail for most current data. I suggest to use the ~ARCH version of eix if use want to use update-eix-remote (this feature is really useful anyway only if you are interested in bleeding edge).
(In reply to comment #7) > (In reply to comment #6) > > Same bug is now showing up in 0.13.5 > > Older eix versions will always fail for most current data. > I suggest to use the ~ARCH version of eix if use want to use update-eix-remote > (this feature is really useful anyway only if you are interested in > bleeding edge). > Makes sense.
