gourmet crashes if metakit-based recipe database (used in versions prior to 0.10) is present

I apparently can't set importance, but obviously there is no reason to even bother to ship the package until this is fixed.

does this still happen with the updated package from bug 269936?

Yes, it still happens. (This shouldn't be surprising, as that is an unrelated dependency bug that I also filed. But thanks for checking in on it; maybe now someone will pay attention to the fact that you're shipping a package that DOES NOT WORK AT ALL IN THE SLIGHTEST TINIEST BIT BY ANY CONCEIVABLE DEFINITION OF THE WORD 'WORK'. ahem. :)

Luis, I suggest you get your so called facts straight. As you should be aware, the package works just fine for me, OK?

This looks like an encoding problem. Luis, what is your language environment? Does "LANG=C LC_ALL=C gourmet" from the command line work?

Nope, still crashes.

(FWIW, this happens both with and without an old data file from another machine.)

Oh, and for the record:

music@musicbox:~$ echo $LANG
en_US.UTF-8
music@musicbox:~$ echo $LC_ALL

Maybe the unset $LC_ALL is part of the problem? This box has been upgraded repeatedly; it is possible that this got buggered somewhere along the way.

(but LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 gourmet fails too.)

please md5sum /usr/share/gourmet/importers/rezkonv_importer.py and attach it here if you get a result different than aad60c7b25f9bad437fc8d4af57200f6

$ cat -n /usr/share/gourmet/importers/rezkonv_importer.py|grep 41
    41 self.ing_or_matcher = re.compile("^[-= ]*[Oo][dD]?[eE]?[Rr][-= ]*$",re.IGNORECASE)

$ head -n2 /usr/share/gourmet/importers/rezkonv_importer.py
# -*- coding: utf-8 -*-
import mealmaster_importer, plaintext_importer, re

looks correctly encoded as per http://www.python.org/dev/peps/pep-0263/

IOW, the reason you are seeing this problem is opaque. Your best bet is probably to find somebody who can reproduce this.

looks exactly like http://sourceforge.net/tracker/index.php?func=detail&aid=1589496&group_id=108118&atid=649652

In plain English: gourmet uses the sqlite backend since version 0.10. I'll bet anyone that Luis is upgrading a previous install pre0.10 which was still using metakit.

@Thomas Hinkle: Does the importer work for such old versions? Do we have some kind of quick fix other than "rm ~/.gourmet/recipes.mk"? <evilgrin>

@Luis: You can probably use gourmet for now only by doing "mv ~/.gourmet/recipes.mk ~/.gourmet/recipes.mk.bak" I'm not sure if you will be able to easily merge later on.

Rolf, the update code may well be broken. It is code that was tested when it was created, but I don't know that I've run tests for more recent versions.

You can also use the --gourmet-directory commandline switch to test whether this is the issue by pointing at a new directory, which gives you the equivalent of a fresh install

$ gourmet --gourmet-directory=/tmp/foo/

+--[ http://grecipe-manager.sourceforge.net/installation_instructions.html ]
|
| # Metakit
| * This is the old database backend for gourmet. New versions will need to compile this in
| if they want to provide upgrade support for old versions of Gourmet.
|
+--

Given the fact that the last metakit version of gourmet is about three years old and the apparently sorry state of metakit in general, my motivation to support the switching over from metakit-based recipe collections to the new sqlite format borders on 0.

gourmet should be failing more gracefully and output a more meaningful message to the user. I acknowledge that loosing access to a possibly large collection of recipes this way will be tough for those affected. But I trust their numbers will be very small. Maybe there is one among them to provide a patch

Indeed correct. Grr, this blows, but not Ubuntu's fault, obviously.

(sadly what this really means is that the recipes will just end up in a proprietary web app instead. !@#@!#. dammit. This was the one Linux app the fiancee actually /likes/...)

Luis -- I doubt that the many are going to be driven to a proprietary web app after trying to upgrade and losing recipes... nearly everyone who has filed a bug related to data loss has had their data rescued personally, by hand, by me -- this is something that matters quite a bit to me. Users upgrading will of course be people who installed the previous versions from SF, not people who are using the new package, and those users will already have metakit installed.

Thomas, on the money. This is of course more handwaving.

The solution should be rather straight-forward and require only a few minutes' work: export to mealmaster from the old version and import that into the new, then some clean-up. Exporting to that proprietary web app is likely going to take longer unless it understands mealmaster as well.

Thomas, I'll leave this bug open as a reminder to have a more meaningful error message when a recipes.mk file is present, OK?

Has there been any progress on this bug?

We're well past the point of diminishing returns on this bug. If anyone who was ever affected by this bug is still using gourmet, two LTS release cycles later, it's certainly because they've migrated their data by hand.

So I'm closing this as wontfix, which I believe reflects the real status here.

I'm closing this as "Won't Fix" for upstream Gourmet, too. Sorry for any inconvenience caused -- I hope everybody was able to carry over their recipes to the new versions in the past 5 years since this issue was reported.
Given that we're still quite understaffed, I can't really spend time on acquainting myself with a rather outdated dependency when most people probably have found another way of working around this anyway, and when there are still some 230 open issues in our Github tracker, many of which affect our current users. So I'll be instead removing any metakit remnants in our code shortly.