abrt version: 1.1.14 architecture: x86_64 cmdline: /usr/bin/python /usr/bin/gourmet component: gourmet executable: /usr/bin/gourmet kernel: 2.6.35.6-48.fc14.x86_64 package: gourmet-0.15.6-3.fc14 reason: db.py:2017:items:TypeError: an integer is required release: Fedora release 14 (Laughlin) time: 1291491719 uid: 500 backtrace ----- db.py:2017:items:TypeError: an integer is required Traceback (most recent call last): File "/usr/bin/gourmet", line 35, in <module> gourmet.GourmetRecipeManager.startGUI() File "/usr/lib/python2.7/site-packages/gourmet/GourmetRecipeManager.py", line 715, in startGUI r=RecGui(splash_label=splash.label) File "/usr/lib/python2.7/site-packages/gourmet/GourmetRecipeManager.py", line 918, in __init__ GourmetApplication.__init__(self, splash_label=splash_label) File "/usr/lib/python2.7/site-packages/gourmet/GourmetRecipeManager.py", line 116, in __init__ self.setup_shopping() File "/usr/lib/python2.7/site-packages/gourmet/GourmetRecipeManager.py", line 228, in setup_shopping self.sl = shopgui.ShopGui() File "/usr/lib/python2.7/site-packages/gourmet/shopgui.py", line 633, in __init__ self.data,self.pantry=self.grabIngsFromRecs([]) File "/usr/lib/python2.7/site-packages/gourmet/shopgui.py", line 542, in grabIngsFromRecs return self.organize_list(self.lst) File "/usr/lib/python2.7/site-packages/gourmet/shopgui.py", line 545, in organize_list self.sh = recipeManager.DatabaseShopper(lst, self.rd) File "/usr/lib/python2.7/site-packages/gourmet/recipeManager.py", line 25, in __init__ shopping.Shopper.__init__(self,lst) File "/usr/lib/python2.7/site-packages/gourmet/shopping.py", line 23, in __init__ self.init_pantry() File "/usr/lib/python2.7/site-packages/gourmet/recipeManager.py", line 55, in init_pantry if len(self.pantry.items())==0: File "/usr/lib/python2.7/site-packages/gourmet/backends/db.py", line 2017, in items val = getattr(i,self.vp) TypeError: an integer is required Local variables in innermost frame: How to reproduce ----- 1.Upgrade to the testing version 2.Same thing as previously 3.
Created attachment 464776 [details] File: backtrace
Package: gourmet-0.15.6-3.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1.Upgrade to the testing version 2.Same thing as previously 3. Comment ----- I ran the new update so now have [egner@quadbox ~]$ rpm -q gourmet gourmet-0.15.6-4.fc14.noarch but the abrt still reports crash as 0.15.6-3?
This is with an existing gourmet database? We are tracking down corner cases as we hit them and pushing patches upstream. To help us narrow your specific problem down. Can you backup your .gourmet directory to another location and let gourmet create a new database from scratch and see things work in that case. I want to make really sure your problem is restricted to just interacting with an older database already on disk from a previous gourmet version. Also would you be willing to post your database somewhere for me to grab and test with? In the case of older database related problems it can be really difficult to fully understand what is going on without a database that is causing a problem. -jef
(In reply to comment #3) > This is with an existing gourmet database? We are tracking down corner cases as > we hit them and pushing patches upstream. > > > To help us narrow your specific problem down. Can you backup your .gourmet > directory to another location and let gourmet create a new database from > scratch and see things work in that case. I want to make really sure your > problem is restricted to just interacting with an older database already on > disk from a previous gourmet version. > > > Also would you be willing to post your database somewhere for me to grab and > test with? In the case of older database related problems it can be really > difficult to fully understand what is going on without a database that is > causing a problem. > > -jef Hi Jef, moved .gourmet db to my desktop and allowed gourmet to recreate. opened fine and I was able to create a recipe and view edit, print etc. My database, which I would like to open, is available at http://www.egner.co.za/junk/egner_gourmet.zip if you would like to have a look. Let me know if you would like me to test anything else. Cheers Sean
This crash was caused by incorrectly typed data being returned when querying the DB table 'pantry'. The column 'pantry' in that table is defined as 'bool' but the values in that column are like 'I01\n.' (replace '\n' with a newline). These values are 'python pickles'. A solution is to update the records in that table, to replace the 'I01\n.' with '1'. Do this with : sqlite3 ~/.gourmet/recipes.db sqlite> update pantry set pantry=1; ^D (<- That's a CTRL+D, to exit sqlite3) After applying the fix above, I was able to successfully start gourmet with the upgraded database. However, I noticed that the 'Shopping list' shows some strange looking data, more 'python pickles'! I'm thinking that this DB was created back before gourmet moved to using a sqlite backend and an earlier DB upgrade ( from the old DB format to the sqlite DB) did not properly 'unpickle' the 'pantry' and 'shopping category' values. Reporter: Do you remember with which version of gourmet/fedora this database was initially created? What is the most recent version with which you were able to open this DB?
(In reply to comment #5) > This crash was caused by incorrectly typed data being returned when querying > the DB table 'pantry'. The column 'pantry' in that table is defined as 'bool' > but the values in that column are like 'I01\n.' (replace '\n' with a newline). > These values are 'python pickles'. > > A solution is to update the records in that table, to replace the 'I01\n.' with > '1'. Do this with : > sqlite3 ~/.gourmet/recipes.db > sqlite> update pantry set pantry=1; > ^D (<- That's a CTRL+D, to exit sqlite3) > > After applying the fix above, I was able to successfully start gourmet with the > upgraded database. However, I noticed that the 'Shopping list' shows some > strange looking data, more 'python pickles'! > > I'm thinking that this DB was created back before gourmet moved to using a > sqlite backend and an earlier DB upgrade ( from the old DB format to the sqlite > DB) did not properly 'unpickle' the 'pantry' and 'shopping category' values. > > Reporter: Do you remember with which version of gourmet/fedora this database > was initially created? What is the most recent version with which you were > able to open this DB? Hi Jef, Applied your fix and it worked. I have been using gourmet for ages and as it was working under fedora 13 when last it worked. And I regularly run "yum update". Unfortunately I didn't pay attention to exact version numbers. Pity the db doesn't "stamp" itself with the details. I had assumed that the issue was caused by python 2.7 in fedora 14... I see the shopping list and nutritional information are still a problem. I assume this is because of the reasons you explained above. I do remember the "pickles" appeared in the shopping and ingredients list but cannot remember when this happened. Would I have to manually go and fix the 'pickles'. Sean
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping