Summary: | emerge sync failed at "Performing Global Updates": KeyError: 'dev-python/setuptools-65.0.0' | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Drunkard Zhang <gongfan193> |
Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | syu.os |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=918597 https://bugs.gentoo.org/show_bug.cgi?id=587088 https://bugs.gentoo.org/show_bug.cgi?id=889300 https://bugs.gentoo.org/show_bug.cgi?id=919419 https://github.com/gentoo/portage/pull/1043 https://github.com/gentoo/portage/pull/1214 https://bugs.gentoo.org/show_bug.cgi?id=920828 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 919862 | ||
Bug Blocks: |
Description
Drunkard Zhang
2023-12-16 04:31:20 UTC
I imagine 'emaint all -f' will fix this, but this shouldn't be happening to begin with: 1) We should catch the error and give some nicer output; 2) We shouldn't have a dead entry in the index anyway... I guess the question for 2) is whether the previous fixes in e.g. portage-3.0.57 would prevent such a bad entry being created in the first place. We should also add a lock around the global updates bit so that it's not possible to have multiple instances trying to do it at the same time (which could trigger a KeyError like this). We can use a global vardb lock here too since we don't want the installed packages mutating either. I've just noticed that aux_update can interact badly with signed gpkg and FEATURES=pkgdir-index-trusted, leaving a stale entry in $PKGDIR/Packages and triggering a KeyError later. The issue is that aux_update for a signed gpkg will delete the gpkg file without updating internal state including but not limited to $PKGDIR/Packages: https://gitweb.gentoo.org/proj/portage.git/commit/?id=a7bbb4fc4d38f770fc943f3b856c5de56e315fe4 We have some code in the binarytree.inject method that we can reuse to fixup the state. Specifically, the part where it calls cpv_remove, and also _inject_file deletes a stale package index entry from pkgindex.packages before pkgindex is re-written by _pkgindex_write. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=d31f0fee089eb0883c7b48faabee4c47d80cbdf8 commit d31f0fee089eb0883c7b48faabee4c47d80cbdf8 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2023-12-24 18:40:57 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2023-12-24 18:57:49 +0000 bindbapi: Update state for package remove in aux_update When removing a signed gpkg in aux_update, update internal state including $PKGDIR/Packages (important especially for FEATURES=pkgdir-index-trusted). Bug: https://bugs.gentoo.org/920095 Fixes: a7bbb4fc4d38 ("Fix move_ent with signed binpkg") Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/dbapi/bintree.py | 61 +++++++++++++++++++++---- lib/portage/tests/update/test_move_slot_ent.py | 19 +++++--- lib/portage/tests/update/test_update_dbentry.py | 13 ++++-- 3 files changed, 73 insertions(+), 20 deletions(-) (In reply to Zac Medico from comment #3) > We should also add a lock around the global updates bit so that it's not > possible to have multiple instances trying to do it at the same time (which > could trigger a KeyError like this). We can use a global vardb lock here too > since we don't want the installed packages mutating either. Done in: commit 7100dfb769b9d98eb40a92c37d154cb4bc83292f Author: Zac Medico <zmedico@gentoo.org> Date: Tue Dec 26 14:24:59 2023 -0800 _global_updates: Acquire global vardbapi lock Also use bindbapi.writable attribute in case the PKGDIR is missing for some reason. Bug: https://bugs.gentoo.org/587088 Signed-off-by: Zac Medico <zmedico@gentoo.org> The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0a1f19cdd7a598070b7eb08b3954e677aa4868ad commit 0a1f19cdd7a598070b7eb08b3954e677aa4868ad Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-27 21:27:55 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-27 21:28:01 +0000 sys-apps/portage: add 3.0.59 Closes: https://bugs.gentoo.org/587088 Closes: https://bugs.gentoo.org/822033 Closes: https://bugs.gentoo.org/915494 Closes: https://bugs.gentoo.org/916135 Closes: https://bugs.gentoo.org/917120 Closes: https://bugs.gentoo.org/919862 Closes: https://bugs.gentoo.org/920095 Closes: https://bugs.gentoo.org/920258 Closes: https://bugs.gentoo.org/920537 Closes: https://bugs.gentoo.org/920654 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.59.ebuild | 246 +++++++++++++++++++++++++++++++++ 2 files changed, 247 insertions(+) (In reply to Sam James from comment #1) > I imagine 'emaint all -f' will fix this, but this shouldn't be happening to > begin with: > 1) We should catch the error and give some nicer output; > 2) We shouldn't have a dead entry in the index anyway... I've filed bug 920828 for 1). |