"Roundcube Webmail 1.1-beta available": http://roundcube.net/news/2014/11/10/roundcube-webmail-1.1-beta-available/ Reproducible: Always
Meanwhile roundcube 1.1 has left beta stage and has been released: http://roundcube.net/news/2015/02/08/new-stable-version-1.1-released/
It should be noted that Roundcube 1.1.0 has increased it's PHP requirement to >=5.3.7.
*** Bug 539924 has been marked as a duplicate of this bug. ***
Created attachment 399016 [details, diff] roundcube-1.1.0.ebuild.diff As the current php 5.3 series in portage is 5.3.29, there shouldn't be any problems with the requirement of >=5.3.7. I've modified the eBuild for 1.1.0, attaching the diff. That one is working for me. The only difference is, that I've removed the removal of the bundled PEAR packages, because they seem not be presend in the 1.1.0 tar.
*** Bug 544604 has been marked as a duplicate of this bug. ***
any updates on this? I was just considering upgrading ;)
(In reply to Thomas Raschbacher from comment #6) > any updates on this? I was just considering upgrading ;) The patch from comment #4 works (for 1.1.1, too).
I just upgrade via Conrad Kostecki's patch to 1.1.1 and it seems to be working. Two things I noticed, but probably can just go in separate bugs for future tweaking. I'm going to spam them here so I don't forget about them. 1.) During webapp-config upgrade: =========================================================== * Upgrading /roundcube-1.0.5 to /roundcube-1.1.1 * Installed by root on 2015-02-11 13:17:40 * Config files owned by 0:0 ... *snip* ... * Creating required directories * Linking in required files * This can take several minutes for larger apps * Files and directories installed /bin/sh: ./bin/update.sh: Permission denied =========================================================== Not sure why that update script had permission denied, I was running as root via sudo. Perhaps wrong working directory for the relative path? Further, ${ROUNDCUBE_ROOT}/bin/update.sh isn't a sh script, it's PHP (although it does have a "#!/usr/bin/env php" line). 2.) There's some new optional 3rd-party PHP dependency tracking & management package: http://trac.roundcube.net/wiki/Howto_Upgrade#Updatingto1.1.0 It probably doesn't matter since portage has the dependencies, but the referenced composer.json-dist file (which seems to be installed by our current ebuilds) does have requirements that may be helpful.
The update.sh script is indeed no Shell- but a PHP-script. And it is missing the executable permissions, which is why you get "permission denied". Run chmod +x.
I'm not sure where's it's being called from via webapp-config. I don't see any mention to update.sh outside of the pkg_postinst() ewarn lines. Anybody with more webapp-config knowledge know where this might be being triggered from?
With the vhosts USE flag disabled, roundcube should be installed in the web server document root (/var/www/localhost/htdocs). This ebuild does not solve bug #524192 . With the proposed ebuild and -vhosts, I am not able to install roundcube. Does anybody know a workaround ?
1.1.2 has been released: https://bugs.gentoo.org/show_bug.cgi?id=532844 The security-related fixes in particular are: XSS vulnerability in _mbox argument security improvement in contact photo handling potential info disclosure from temp directory
Created attachment 408352 [details] roundcube-1.1.2.ebuild Ebuild for 1.1.2. Runs the post install to link to /var/www/localhost/htdocs if USE=-vhosts set.
roundcube 1.1.3 is released
(In reply to Roland Hopferwieser from comment #13) > Created attachment 408352 [details] > roundcube-1.1.2.ebuild > > Ebuild for 1.1.2. > > Runs the post install to link to /var/www/localhost/htdocs if USE=-vhosts > set. This ebuild also works for roundcube 1.1.3.
When is this ebuild going to be added to the portage tree?
*push* What is the status on this? Don't we have a maintainer for roundcube anymore? If so, it should be removed from portage... Otherwise, roundcube 1.1. was released in february 2015 and we now have december and are still on 1.0., so please add this ebuild to the tree, or at least say where the problem is of not adding it so far...
(In reply to Stefan Triller from comment #17) > *push* > > What is the status on this? Don't we have a maintainer for roundcube > anymore? If so, it should be removed from portage... > > Otherwise, roundcube 1.1. was released in february 2015 and we now have > december and are still on 1.0., so please add this ebuild to the tree, or at > least say where the problem is of not adding it so far... I was just looking at this myself. Although I'm not a fan of PHP, I now use Roundcube for my email and am a fan of it. If the web-apps team isn't opposed, I'm willing to assume maintainership.
Done in my repo: https://github.com/titanofold/titanofold-gentoo-x86/commit/bed443febe021b7d1e526431878c6f2df1dc7a5e You can use Layman to enable Portage access to my repo. Instructions are here: https://github.com/titanofold/titanofold-gentoo-x86 Try it out and let me know. (I haven't yet tried it on my server, but it installs fine on my local machine.)
Done. And, I'm sorry, I forgot to thank Conrad Kostecki and Roland Hopferwieser for their work in the commit. commit c20f39cdcba8d3f75fcd7d6c09e80d2ee0655e40 Author: Aaron W. Swenson <titanofold@gentoo.org> Date: Wed Dec 9 07:44:37 2015 -0500 mail-client/roundcube: Version bump, security, and bug fixes Added two use flags controlling optional dependencies to support the enigma and and sieverules plugins. Added REQUIRED_USE as one of postgres, mysql, or sqlite must be enabled. Rouncube requires a database to operate. As the ebuild uses this now, removed the default enable on the mysql USE flag. Added POST-UPGRADE.txt which is just a shortened version of the UPGRADE text from upstream. Dropped arm and ppc64 keywords as one dependency, dev-php/PEAR-Net_LDAP2, currently lacks matching keywords for those architectures. Bug: 541172, 545096, 524192, 564476, 565204, 53284 Package-Manager: portage-2.2.20.1
