Summary: | app-portage/etc-proposals with dev-lang/python-2.7[-berkdb] - raise error, "db type could not be determined" | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Mark <chaseguard> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | dolsen, tools-portage |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Deadline: | 2020-09-21 |
Description
Mark
2012-04-06 01:51:37 UTC
# eselect python list Available Python interpreters: [1] python2.7 * [2] python3.2 I've run into this or a similar error myself in the past (don't remember the exact error). I have installed the bsddb3 pkg as well. The solution for me was to delete etc-proposals user's config file so that anydbm would then not be given the previous db type to use. It seems that the db type is saved in the config. I looked in the conf file (/etc/etc-proposals) and see nothing that indicates the db type. I deleted the conf and got: etc-proposals Every configured frontend failed to start. I then unmerged etc-proposals, deleted the /var/state/etcproposals.state, and re-emerged. That gave me a successful launch. I closed that instance and relaunched only to get the same: # etc-proposals Traceback (most recent call last): File "/usr/sbin/etc-proposals", line 11, in <module> from etcproposals.etcproposals_lib import Config, EtcProposals File "/usr/lib64/python2.7/site-packages/etcproposals/etcproposals_lib.py", line 604, in <module> State = EtcProposalsState() File "/usr/lib64/python2.7/site-packages/etcproposals/etcproposals_lib.py", line 566, in __init__ shelve.Shelf.__init__(self, anydbm.open(STATEFILE, 'c')) File "/usr/lib64/python2.7/anydbm.py", line 82, in open raise error, "db type could not be determined" anydbm.error: db type could not be determined Seems to me, as the traceback says, the statefile is not telling the right stuff. Ok, it's taken a bit, but i've finally remembered all the hassles I had with bsddb3 and python 2.6. The problem is not etc-proposals as it does not specify a db type, but calls python's builtin anydbm(). In python 2.6 when i first encountered the problem it was still trying to import bsddb, but the new external pkg was now bsddb3. At first I just edited anydbm to import bsddb3, which worked. But later updates changed the way anydbm worked. It now uses whichdb(). It is that function which is failing to determine that it is beddb3. For that reason, This particular issue is an upstream issue with python and bsddb3. So far I have not been able to restore normal operation after unmerging bsddb3. although, I was able to long ago when still using python 2.6 So far the only way is for me to restore my working state file from before this recent testing to duplicate your problem. More checking it looks like gdbm's magic number has changed and python-2.7 isn't looking for the correct one. doing more testing... Yes, it is definitely a python issue. It seems that your python2.7 most is likely using gdbm and not bsddb3. For me it was, even with bsddb3 installed. The problem is python-2.7.2 is not checking for the correct magic numbers, which gdbm is now using a newer one, so, when python is opening the file, it does not know which db module it belongs to. This is fixed in the upcoming python-2.7.3. But I will look into changing etc-proposals into using the bsddb3 module directly. removed. |