no import plugins available in UI; all imports fail

And re-reading the old bug, I apologize for the cheap shot. But the problem is still there (and still biting me :/

Hmm -- looking at my list, I see a typo where the gourmet import/export plugin is listed as "export and export", but I believe that plugin will provide import and export anyway. Other than that, the only import plugins listed are website importers and plaintext guided import -- are you seeing others?

What plugins exactly are you seeing listed?

By the way, there's a *much worse bug* in 0.14.0 as shipped in intrepid that I thought I'd reported (I know I e-mailed the package maintainer directly). That bug will wipe out all ingredients on upgrade from 0.13.x databases.

I don't know what it will take to get the ubuntu package updated, but if ubuntu is going to package the unstable branch of Gourmet, it would be nice if the packaging updated frequently so that users don't get killed by these kinds of bugs.

The much worse bug I was referring to is #291353 -- for some reason I didn't see it when I clicked "list all bugs" for Gourmet. Perhaps I'm missing something in the launchpad interface?

Thomas: it lists HTML export, Gourmet XML export, PDF export, and mealmaster export. All I've tried to actually import so far is gourmet XML and mealmaster.

Huh, so... now at least gourmet import is working when I enable the gourmet export, as you suggested. Well, 'working'- instead of giving a 'no plugin found' error it gives a whole bunch of lines like:
IMPORTING TEXT TIME cooktime: "6 minutes"

and then:
<converter(GXML2 Importer, started)> Done!
emit ('completed',)
emit ('done',)
thread_done cb
Traceback (most recent call last):
  File "/usr/share/gourmet/threadManager.py", line 300, in thread_done
    threadbox.pb.set_text(txt + ' ('+_('Done')+')')
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
TypeError: follow_up() takes no arguments (1 given)
<converter(GXML2 Importer, started)> done
Check queue

and then no recipes show up in the UI.

Ah! They don't show up until after a restart, but all the data does appear to be there. Thanks for the pointers, Thomas.

Anyway... this is a bit of a mess, so I'd be happy to test an 0.14.2 package for similar issues if someone wants to publish it. Agreed completely that if Ubuntu is going to ship the first release of an unstable branch there is some responsibility to keep updating it.

(Oh, and maybe under the circumstances this should be retitled 'export plugins should be renamed import/export'? And really, assuming the performance overhead is low, the import plugins should probably be enabled by default so that it is maximally easy for people to get their data into the app when they first start using it.)

Is this still a problem in Ubuntu 9.10? I see the importers there (but haven't tried them).

This bug was fixed in the package gourmet - 0.15.2-0ubuntu1

---------------
gourmet (0.15.2-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #431806, Closes: #530841). Also fixes the
    following bugs:
    - LP: #315836
    - LP: #295982
    - LP: #316445 (the GUI has been changed so this no longer applies)
  * Drop forcing of python2.5
  * debian/control: Recommends python-gnome2-extras for printing
  * drop debian/patches/05-add_manpage.patch, which is now included upstream
  * Fix some lintian warnings:
    - add debian/README.source
    - debian/control: bump Standards-Version to 3.8.3
    - debian/compat: bump to 5
  * debian/control: Depends on python-poppler (needed for printing)
  * debian/patches/01_fix_raise_str.patch: don't raise str exception
    in src/lib/plugin_gui.py
  * debian/patches/02_fix_nutrition_index_out_of_range.patch: don't
    add entries beyond the width of the field in databaseGrabber.py
  * debian/patches/03_dont_remove_nonexistent_plugin.patch: don't
    remove an inactive plugin in plugin_loader.py and don't deactivate
    a plugin from a non-existent database
 -- Jamie Strandboge <email address hidden> Tue, 29 Dec 2009 09:12:49 -0600