Description of problem: Updated gallery2 from 2.3-1 to 2.3-7 gallery2 now broken. First ran into the Smarty error which was a missing symlink. After working around that, gallery2 seems to work and you can add an album but when you go to add pictures to the album an error comes back that it can not find the "ItemAddGalleryRemote.inc" module. This use to be in "gallery2-remote" in 2.2 which was obsoleted by gallery-2.3. It was present in 2.3-1 here (on another system): # locate ItemAddGalleryRemote.inc /usr/share/gallery2/modules/remote/ItemAddGalleryRemote.inc # rpm -qf /usr/share/gallery2/modules/remote/ItemAddGalleryRemote.inc gallery2-remote-2.3-1.fc10.noarch The file is not present in 2.3-7. I've also tried 2.3-11 from Koji, since that fixes the Smarty problems, and it's not present in 2.3-11 either. Version-Release number of selected component (if applicable): Good: 2.3-1 Bad: 2.3-7 - 2.3-11 How reproducible: 100% for us. Gallery2 is now totally unusable for us. We can no longer add photos to our albums and no clue how to disable this or work around it. Steps to Reproduce: 1. Add a new album. 2. Got to add items to album. 3. Note error. Actual results: Errors on screen complaining that it can't find ItemAddGalleryRemote.inc Expected results: Selections for adding items. Additional info:
Awesome. I had to remove all the Java jars for legal reasons, since it was discovered that they were pre-built and the process of building them from SVN source was, to make a very long story short, so extremely non-trivial as to be unworkable. I was assured by upstream that removing them and their associated subpackages would remove functionality but leave the bones of Gallery2 in a usable state. It looks like they were wrong. I had tested this, but not through the upload phase. I should definitely have tested more thoroughly. You have my apologies. I'll take this up with upstream. Gallery3 won't have these sort of legal issues, or so I'm told, but it's in late Alpha.
Problem turns out to be that I had this module and a couple of the others (like slideshow applet) "installed" and "activated". Merely removing them apparently does not "deactivate" them and thus the breakage. Once I rebuilt the entire rpm from the -full (yeah, sticking back the .jar files) with all the deleted directories back in place I was able to go back and deactivate and uninstall the impacted modules and, now, I presume I can fall back to the stripped down package without it catching fire and burning on me.
Good to hear. I'll add this info to my upstream query. There needs to be a way to do this that doesn't involve re-adding the legally problematic bits.
I've culled all references to the affected modules, and my search of my gallery files and DB for references turns up nothing, and it still isn't working.
Made contact with upstream. Workaround: "FYI, you can work around this problem by dropping any rows from g2_FactoryMap where g_implModuleId='uploadapplet' (or any other module which you've dealt with this way) and then deleting g2data/cache/module/_all/0/0/* and g2data/cache/module/uploadapplet" Do this for uploadapplet, slideshowapplet and remote.
gallery2-2.3-12.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gallery2-2.3-12.fc10
gallery2-2.3-12.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gallery2'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5545
Updated to gallery2-2.3-12.fc10 but still needed to manually delete from the database. Can postinstall do this?
No. We don't assume database availability for DB-backed apps, and so never touch the database.
Makes sense. This bug is fixed for me.
gallery2-2.3-12.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.