recover-broken-vdb output is an empty directory

[waptaff]

Running recover-broken-vdb-find-broken.sh on a system returns 125 broken packages.

When running recover-broken-vdb afterwards, a directory is created but it is empty. Output shows nothing unusual:

# recover-broken-vdb

>> Writing to output directory: /tmp/.private/root/tmp6yqttijf
>>> Written to output directory: /tmp/.private/root/tmp6yqttijf

Is that a normal situation? I expected the creation of a drop-in replacement for /var/db/pkg. Neither Gentoo news item nor this repo's README cover that empty directory case.

[thesamesam]

Hey, thanks for the report!

Could you:

1. try again with >= 0.0.6 (ideally 0.0.7)?

This fixed a few cases where recover-broken-vdb-find-broken.sh was excessive and would find cases which recover-broken-vdb would choose to skip because they're harmless.

In 0.0.7, I also fixed the blank directory creation and included a message to indicate that this meant nothing should be fixed. But I am surprised that the scanner script found 125 packages, so I'm wondering if it's a certain type of package I've not tested with?

The two people who reported the original false positive/mismatch issue had 1 or 2 packages, not 100s!

2. share the output of both recover-broken-vdb-find-broken.sh and recover-broken-vdb --verbose?

Feel free to email the latter part to me: sam@gentoo.org if you consider it private.

[waptaff]

With version 0.0.7, recover-broken-vdb-find-broken.sh finds no broken package.
With version 0.0.6, recover-broken-vdb-find-broken.sh finds no broken package.

So I suspect there is no need to run recover-broken-vdb after all.

For reference, here is the output from 0.0.5's version of recover-broken-vdb-find-broken.sh:
broken_vdb_packages.txt

Might be a good idea to bump ≥ 0.0.6 to stable then?

[thesamesam]

Brilliant, thank you for your feedback! I've done that as gentoo/gentoo@ad1584c. I was hesitant and waiting a few hours because I'd changed the logic a fair bit, but I think it's better in this case to avoid concerning people when everything is good.

Would you mind sharing: cat /var/db/pkg/sys-apps/sed-4.8/{NEEDED,NEEDED.ELF.2,REQUIRES} just to double check here?

[waptaff]

Here you go:

# cat /var/db/pkg/sys-apps/sed-4.8/{NEEDED,NEEDED.ELF.2,REQUIRES}
/bin/sed libacl.so.1,libselinux.so.1,libc.so.6
X86_64;/bin/sed;;;libacl.so.1,libselinux.so.1,libc.so.6;x86_64
x86_64: libacl.so.1 libc.so.6 libselinux.so.1

[thesamesam]

Excellent, thank you! You're all good:

$ cat /var/db/pkg/sys-apps/sed-4.8/{NEEDED,NEEDED.ELF.2,REQUIRES}
/bin/sed libacl.so.1,libc.so.6
X86_64;/bin/sed;;;libacl.so.1,libc.so.6;x86_64
x86_64: libacl.so.1 libc.so.6

Thanks for the report + responsiveness! Let me know if you need anything else.

[waptaff]

Thanks for the support and quick answers; quite happy I don't have to repair + emerge @world just to be on the safe side :)

Please close this ticket at your leisure.

[hlein]

@waptaff can you do us a favor please - give us your version of file(1) and what it outputs for sed, like:

$ file --version
file-5.40
magic file from /usr/share/misc/magic
seccomp support included
$ file /bin/sed
/bin/sed: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped

We've found that output differs by version (and architecture?), possibly enough for the current logic to make the wrong decisions.