Hi! Please find attached gallery-3.0.1.ebuild. This is an upgrade of gallery-ebuild to version 3.0. This will also clear bug 339911. I have tested the installation on a x86 platform. But, since the gallery installation is a relatively straight forard installation, the ebuild should therefore work also on other platforms. Uwe
Created attachment 261026 [details] gallery-3.0.1.ebuild
Created attachment 261028 [details] metadata.xml - update
Testted on amd64, php 5.3.5-r1, works great ! I have made some simple changes in the ebuild: KEYWORDS="~x86 ~amd64" IUSE="unzip" for simpler install on amd64
My Test was with vhost enabled, so i report also that vhost useflag is working ;-)
(In reply to comment #3) > Testted on amd64, php 5.3.5-r1, > works great ! > > I have made some simple changes in the ebuild: > KEYWORDS="~x86 ~amd64" > IUSE="unzip" > > for simpler install on amd64 > Thank you for your comments. I do not understand why you request IUSE="unzip". unzip is necessary for the unpack process, only. Therefore I am at the opinion unzip nedds to be in the DEPEND-variable. I will update the ebuild accordingly.
Created attachment 264191 [details] KEYWORD ~amd64 added; DEPEND unzip improved; RDEPEND www-server/apache-2 added
please bump, latest version in the portage tree is broken with PHP 5.3.
(In reply to comment #7) > please bump, latest version in the portage tree is broken with PHP 5.3. Just to note, the only version currently in the tree (2.3.1) works fine with PHP 5.3.
(In reply to comment #7) > please bump, latest version in the portage tree is broken with PHP 5.3. Sorry, but your comment is not clear to me. You are reporting a problem with the proposed new ebuild gallery-3.0.1 or with the version in the portage-tree (gallery-2.3.1)? Please provide more information to identify the problem, e.g. your PHP-version, your USE-flags, a screenshot... Thanks
(In reply to comment #9) > (In reply to comment #7) > > please bump, latest version in the portage tree is broken with PHP 5.3. > > Sorry, but your comment is not clear to me. You are reporting a problem with > the proposed new ebuild gallery-3.0.1 or with the version in the portage-tree > (gallery-2.3.1)? > > Please provide more information to identify the problem, e.g. your PHP-version, > your USE-flags, a screenshot... > > Thanks The current gallery-2.3.1 is broken because of issues with PHP 5.3 i.e. same errors as exhibited here http://gallery.menalto.com/node/95186 Please provide version bump to gallery 3.x Though... it would be nice to get 2.3.1 fixed in the tree as well.....
further down in ... http://gallery.menalto.com/node/95186 "Searching deeper and depending on the experience of others the conclusion is that gallery2 is not compliant with the standards of php 5.3.2. Disabling error_reporting = E_All | E_STRICT allows gallery2 to be installed while gallery3 functions correctly with this level of error reporting enabled."
(In reply to comment #11) > further down in ... http://gallery.menalto.com/node/95186 > > > "Searching deeper and depending on the experience of others the conclusion is > that gallery2 is not compliant with the standards of php 5.3.2. Disabling > error_reporting = E_All | E_STRICT allows gallery2 to be installed while > gallery3 functions correctly with this level of error reporting enabled." Oh, in regards to 2.3.1 working with PHP 5.3 it does... if it was installed while PHP 5.2 was on the system. The upgrade of PHP 5.3 doesn't appear to break the 2.3.1 build... However... ON a FRESH install of gallery with PHP 5.3 installed as a dependent PHP version... Then... it doesn't work.
Hi, I could not understand the problem with gallery-2.3.1 therefore I started to investigate it from the scratch. I used an actual gentoo installation on an old computer. The "emerge gallery" worked well after setting of some necessary USE-Flags. But the start of gallery on the webserver ("http://localhost/gallery") created many error messages like: Strict Standards: Non-static method ... The problem is not gallery-2.3.1 related. It is a php5 issue. Gallery-2.3.1 does not work with the "error_reporting = E_All | E_STRICT" as reported by Ira already. To get gallery-2.3.1 running I done the following: edit file /etc/php/apache2-php5.3/php.ini and change the line "error_reporting = E_All | E_STRICT" to "error_reporting = E_All". After the restart of the apache (/etc/init.d/apache restart) gallery-2.3.1 was working.
Created attachment 275723 [details] gallery-3.0.2.ebuild - Upgrade to new version Upgrade ebuild to version 3.0.2
Please bump to either 3.0.1 or... 3.0.2 which is now out. Thanks, Ira http://gallery.menalto.com/ (In reply to comment #14) > Created attachment 275723 [details] > gallery-3.0.2.ebuild - Upgrade to new version > > Upgrade ebuild to version 3.0.2 Any luck on getting this into a regular portage tree?
Not sure how ebuilds are maintained in portage... Is there someone who has an 'ownership' of gallery related ebuilds in the Gentoo community? If yes, then who? What can we do to help this person (or these people) to push for getting gallery 3 in the portage tree? I'd be more than happy to help. (To my limited ability.)
php-5.2 is masked, so this portage needs a php-5.3 friendly version of gallery please. We need a maintainers attention.
(In reply to comment #17) I am using gallery-3.0.2 with php-5.3 without problems.
(In reply to comment #16) I am also interested to see gallery 3 in the portage tree. But I do not know how this can be done. Is there any Manintainer?
The import from gallery 2.0.3 to gallery 3.0.2 didn't work for me. So I'm not completing my upgrade until I figure that out. It might work well for others though. (I don't have time to dive in and try to solve whatever is going on... it appears to get part way through importing my 10k pictures and just hangs)
(In reply to comment #20) The error description appears to me to be a Gallery problem and not a Gentoo problem. Did you upgrade as described in section "1.4 Upgrading" of the following website? http://codex.gallery2.org/Gallery3:User_guide:Gallery3:Installing_and_upgrading#Advanced_Installation
(In reply to comment #21) > (In reply to comment #20) > > The error description appears to me to be a Gallery problem and not a Gentoo > problem. > > > Did you upgrade as described in section "1.4 Upgrading" of the following > website? > > http://codex.gallery2.org/Gallery3:User_guide:Gallery3:Installing_and_upgrading#Advanced_Installation Yes, I tried the Gallery 2 import module (http://codex.gallery2.org/Gallery3:Modules:g2_import), but it didn't finish the import. Yes, this is mostly likely a gallery issue, not a gentoo issue. It should only serve as a warning... I'm all in favor of getting gallery 3 into the portage tree.
FWIW, upgrade from G2 to G3 worked fine in my non-portage-managed G3 install. Only problem is that it's lossy. :/
After performing the upgrade embed.php (from gallery 2) is no longer present, so I was not able to use the plugin to import Gallery2 albums. There should be a note in the ebuild for users to make a copy of their gallery 2 before calling: webapp-config -U -h localhost -d /gallery gallery 3.0.2
Hello Gentoo Dev's, please put the ebuild to the portage tree, or where is the showstopper ? It's since a long time in bugs .... Thank you
Do not CC random devs to the bugs please. It looks like the package is not maintained. Last bump by devs was done in 2k10. If you really care for the package you can talk with proxy-maint@gentoo.org about maintaining it yourself. Read more here: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
*** Bug 339911 has been marked as a duplicate of this bug. ***
Created attachment 303355 [details] Updated ebuild of gallery 3 I have Updted the ebuild to make more checks on required php functions ...
Created attachment 303407 [details] gallery-3.0.2-r1.ebuild -Added the delivered .htaccess -Added some checks for required php use flags Enjoy ;-)
In my overlay I made up a gallery3 package, with EAPI 4 dependencies and some other cleanups. Why gallery3 instead of gallery? Well, this is a mostly rewritten app, not providing the same features as gallery2, with a specific database, a folder called gallery3 by upstream, ... and we cannot easily use SLOTs here because of webapp eclass. Also this ensured my gallery2 install would not be touched by an automatic upgrade so I could migrate :) Well long story short I will probably move it to main tree as a separate package(in the meantime it's in my overlay, "layman -a voyageur"). @radhermit, what do you think?
Created attachment 303419 [details] gallery3 with EAPI4 and some cleanups
(In reply to comment #30) > Why gallery3 instead of gallery? Well, this is a mostly rewritten app, not > providing the same features as gallery2, with a specific database, a folder > called gallery3 by upstream, ... Gallery 1 is also wery specific. And G3 relace both G2 & G1 > and we cannot easily use SLOTs here because of > webapp eclass. Also this ensured my gallery2 install would not be touched by an > automatic upgrade so I could migrate :) What wrong with webapp.eclass? I have USE=vhosts and no autoupgrade, it simple set WEBAPP_NO_AUTO_INSTALL=yes (you can set it in the ebuild), and I have to run webapp-config by hand. Also, even if you autoupdate you can import from G2 because of different files/paths. > Well long story short I will probably move it to main tree as a separate > package(in the meantime it's in my overlay, "layman -a voyageur"). @radhermit, > what do you think? I prefer SLOT, and, maybe some warnings & news about upgrade.
I prefer also the slotted version. Please do not make a separate Package, many big webhosting sites operates different versions of gallery in different directorys. ==> This solution makes gentoo to one of the cooles choices for webhosting. I have gallery in both versions online at the same time without problems. vhost is the way to go ... So i wil post a slotted ebuild with EAPI4 ... Thank's Daniel
Created attachment 303459 [details] files/postinstall-en.txt Changed the info to postinstall-en.txt
Created attachment 303461 [details] gallery-3.0.2-r1.ebuild with EAPI4 and postinstall-en.txt slotted Version Here my updated ebuild for gallery - slotted version - vhost like the admins know from all other web packges - postinstall-en.txt which is diplayed when webapp-config is called .. - some minor changes to useflag handling
Are the last 2 files sufficient to bump this package?
(In reply to comment #30) > In my overlay I made up a gallery3 package, with EAPI 4 dependencies and > some other cleanups. > > Why gallery3 instead of gallery? Well, this is a mostly rewritten app, not > providing the same features as gallery2, with a specific database, a folder > called gallery3 by upstream, ... and we cannot easily use SLOTs here because > of webapp eclass. Also this ensured my gallery2 install would not be touched > by an automatic upgrade so I could migrate :) > > Well long story short I will probably move it to main tree as a separate > package(in the meantime it's in my overlay, "layman -a voyageur"). > @radhermit, what do you think? I generally agree with comments 32 and 33, so no please don't add a separate package to the tree. I'll try to clean up the latest ebuild posted to this bug and push it to the tree within a day or two.
The files/postinstall-en.txt and gallery-3.0.2-r1.ebuild are all (2 files). Many thank's for updating this package to the tree ..
(In reply to comment #37) > (In reply to comment #30) > > In my overlay I made up a gallery3 package, with EAPI 4 dependencies and > > some other cleanups. > > > > Why gallery3 instead of gallery? Well, this is a mostly rewritten app, not > > providing the same features as gallery2, with a specific database, a folder > > called gallery3 by upstream, ... and we cannot easily use SLOTs here because > > of webapp eclass. Also this ensured my gallery2 install would not be touched > > by an automatic upgrade so I could migrate :) > > > > Well long story short I will probably move it to main tree as a separate > > package(in the meantime it's in my overlay, "layman -a voyageur"). > > @radhermit, what do you think? > > I generally agree with comments 32 and 33, so no please don't add a separate > package to the tree. I'll try to clean up the latest ebuild posted to this > bug and push it to the tree within a day or two. Tim, thanks for taking care of this package. Daniel expressed his interest in proxy-maintain it. Feel free to adjust metadata accordingly ( and add proxy-maintainers as herd ) if you want to
The bump and the stabilization will continue in bug 411727. Close this as wontfix
