eix-update with git produces empty database

[hartwork]

Hi!

I turned /usr/portage/ from rsync to Git like this:

# cat /etc/portage/repos.conf 
[gentoo]
sync-type = git
sync-uri = https://github.com/gentoo/gentoo.git
auto-sync = yes

# emaint sync --auto
[..]

Now I would expect eix-update to re-build a healthy index but it reports to not find any e-builds (which there are plenty) as I read the output:

# eix-update 
Reading Portage settings...
Building database (/var/cache/eix/portage.eix)...
[0] "gentoo" /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 163|163 (100) EMPTY!
Applying masks...
Calculating hash tables...
Writing database file /var/cache/eix/portage.eix...
Database contains 0 packages in 163 categories.

Is my setup not supported? Could it be? Are there workarounds that I could try?
Many thanks in advance,

Sebastian

[vaeth]

If you use a git repository which does not contain metadata, you must create them locally, using egencache.

[hartwork]

Thanks for the pointer to egencache. I am unsure how to best improve the situation so the the next person will not have to find this ticket or open a duplicate. Any ideas?

[vaeth]

Let's leave the ticket open. It is about the 5th time already I gave a similar answer...

[dxli]

@hartwork

thanks for the tip. I just moved to git repo and got this issue

For the eix-update EMPTY issue, the command which fixed my issue is

egencache --repo=gentoo --update

# eix-update 
Reading Portage settings ..
Building database (/var/cache/eix/portage.eix) ..
[0] 'gentoo' /usr/portage/ (cache: metadata-md5-or-flat)
     Reading category 163|163 (100%) Finished         
Applying masks ..
Calculating hash tables ..
Writing database file /var/cache/eix/portage.eix ..
Database contains 18915 packages in 163 categories.

[shiznix]

So does the egencache command now need to be run every time the git repo is synced?

[mercuriete]

I hit the same issue.
Thanks you very much.

[drunkard]

Here's my script /etc/portage/postsync.d/eix-update:

#!/bin/bash

if [ -e /etc/portage/make.conf ]; then
. /etc/portage/make.conf
if [ ! -d $PORTDIR/metadata/md5-cache -o -d $PORTDIR/.git ]; then
echo "updating metadata cache ..."
egencache --repo=gentoo --update
fi
fi

/usr/bin/eix-update

But the first egencache --repo=gentoo --update is very very long ...

[mercuriete]

hi guys. for someones that hit this issue...

this repo -> https://github.com/gentoo-mirror/gentoo.git

this is a git repo that actually have metadata.

i will fix the problem with this repos.conf

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = git
sync-uri = https://github.com/gentoo-mirror/gentoo.git
auto-sync = yes

Cheers!
😄

[vaeth]

One does not really want to keep the history of metadata in a git repository: It's an enormous waste of disk space.

I have now created a set of /etc/portage/repo.postsync.d/* files which take care about downloading the cache and/or calling egencache to generate the metadata (and also download some other data like news and GLSAs which are not provided in the gentoo repository). Details are highly configurable, and some emphasis is put on security.

You can install it as the package app-portage/portage-postsyncd-mv from the mv overlay (available over layman).

[lisyarus]

Hello from 2021, just upgraded to using git for main gentoo overlay & faced the same problem. Maybe there should be at least some warning message somewhere at eix when moving to a git repo?

[ajakk]

Nobody should be using sync-uri = https://github.com/gentoo/gentoo.git. Instead point sync-uri at https://github.com/gentoo-mirror/gentoo, which contains the metadata cache.

[konsolebox]

Nobody should be using sync-uri = https://github.com/gentoo/gentoo.git. Instead point sync-uri at https://github.com/gentoo-mirror/gentoo, which contains the metadata cache.

Unless you are developing against ::gentoo as well. Don't even dare suggest absurd workarounds like creating another worktree or even worse create a duplicate version of repos.conf/gentoo.conf just for this. You test your ebuilds against the actual repo clean, no possibly conflicting duplicates and no unnecessarily confusing stuff.