Created attachment 524396 [details] errors log fragment The solution to bug 644896 is not quite complete. As it is, when logging is enabled with the following in the config file: $config['log_dir'] = 'logs/'; the 'errors' log file gets flooded with "include(): Failed opening '/var/www/localhost/htdocs/roundcube/vendor/composer/../pear/net_sieve/Sieve.php' ...." messages when the managesieve plugin is used (see attached errors file). This plugin still seems to work as expected, but the flood of messages in the log file is not good for various reasons.
Created attachment 524398 [details, diff] patch to complete the removal of the pear libraries This patch can be applied by putting in: /etc/portage/patches/mail-client/roundcube-1.3.4
Created attachment 524400 [details] An ebuild with changes to apply roundcube-1.3.4-pear-removal.patch
Confirmed. Oddly enough, Sieve.php is the only file for which the error happens, even without applying the proposed patch.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a08aac2e6dcf35ebdabcc3bc42ed24dd064a1f1 commit 8a08aac2e6dcf35ebdabcc3bc42ed24dd064a1f1 Author: Aaron W. Swenson <titanofold@gentoo.org> AuthorDate: 2018-08-06 12:24:28 +0000 Commit: Aaron W. Swenson <titanofold@gentoo.org> CommitDate: 2018-08-06 12:24:28 +0000 mail-client/roundcube: Bump to 1.3.7 Bump to 1.3.7 which addresses EFAIL (https://github.com/roundcube/roundcubemail/issues/6289). (Bug 662716) Add an elog statement that gives the location of the post-upgrade instructions in case the Roundcube update gets buried among many others. (Bug 462250) Make dev-php/PEAR-Net_Socket an optional module, and remove redundant dependencies. (Bug 650792) Remove references to PEAR modules. (Bug 650910) Update POST-INSTALL as step 7 is no longer required since we’re using the complete tarball. (Bug 650912) Bug: https://bugs.gentoo.org/462250 Bug: https://bugs.gentoo.org/650792 Bug: https://bugs.gentoo.org/650910 Bug: https://bugs.gentoo.org/650912 Closes: https://bugs.gentoo.org/662716 Package-Manager: Portage-2.3.40, Repoman-2.3.9 mail-client/roundcube/Manifest | 1 + mail-client/roundcube/files/POST-UPGRADE.txt | 2 - .../roundcube-1.3.7-pear-removed-installed.json | 226 +++++++++++++++++++++ mail-client/roundcube/metadata.xml | 3 + mail-client/roundcube/roundcube-1.3.7.ebuild | 96 +++++++++ 5 files changed, 326 insertions(+), 2 deletions(-)
Rather than using a patch, I've elected to just overwrite the installed.json with our stripped down version since it's a bout a third of the size of the patch file.
By the way, I'm still seeing these errors in my logs even with the stripped down vendor/composer/installed.json. ("grep sieve vendor/composer/installed.json" returns no matches.) @acmodor are you sure removing those lines from installed.json is all that's needed to fix the logging issues?
(In reply to Philippe Chaintreuil from comment #6) > By the way, I'm still seeing these errors in my logs even with the stripped > down vendor/composer/installed.json. ("grep sieve > vendor/composer/installed.json" returns no matches.) @acmodor are you sure > removing those lines from installed.json is all that's needed to fix the > logging issues? It appears you trying to apply the patch manually to your already installed instance of roundcube and, as such, you will need to also edit and remove the sieve related content from the following files: vendor/composer/autoload_classmap.php vendor/composer/autoload_static.php Sorry for not mentioning that earlier. I overlooked them because they are generated from vendor/composer/installed.json when roundcube is emerged.
(In reply to acmondor from comment #7) > (In reply to Philippe Chaintreuil from comment #6) > > By the way, I'm still seeing these errors in my logs even with the stripped > > down vendor/composer/installed.json. ("grep sieve > > vendor/composer/installed.json" returns no matches.) @acmodor are you sure > > removing those lines from installed.json is all that's needed to fix the > > logging issues? > > It appears you trying to apply the patch manually to your already installed > instance of roundcube and, as such, you will need to also edit and remove > the sieve related content from the following files: > > vendor/composer/autoload_classmap.php > vendor/composer/autoload_static.php > > Sorry for not mentioning that earlier. I overlooked them because they are > generated from vendor/composer/installed.json when roundcube is emerged. Oops, the above statement regarding the two files being generated during the emerge is not correct. I was quite sure that was the case for roundcube-1.3.4, but I cannot confirm that since the ebuild is no longer available. Either way, it is definitely not like that now for roundcube-1.3.6.
> [...] they are generated from vendor/composer/installed.json when roundcube is emerged. What exactly does that? Something in the ebuild? I did already have 1.3.7 installed, but I've run "emerge -av1 roundcube" and "webapp-config -h example.com -d secure/roundcube -U roundcube 1.3.7" and the problem persists. I do notice that I get some errors out of webapp-config -- not sure if those are relevant to this or not. ================================================================= * Do you really want to upgrade to the same package? * Waiting for 8 seconds... * Press Ctrl-c if you are uncertain. * Upgrading /roundcube-1.3.7 to /roundcube-1.3.7 * Installed by root on 2018-08-19 11:15:07 * Config files owned by 0:0 !time vendor/composer/installed.json !empty plugins/managesieve !empty plugins/password !empty vendor/composer !empty plugins !empty config !empty vendor !empty logs !empty temp --- /var/www/example.com/htdocs/secure/roundcube * Creating required directories * Linking in required files * This can take several minutes for larger apps * roundcube-1.3.7 does not install any files from /usr/share/webapps/roundcube/1.3.7/hostroot/; skipping * Files and directories installed /bin/sh: line 1: printf: --: invalid option printf: usage: printf [-v var] format [arguments] /bin/sh: line 1: printf: --: invalid option printf: usage: printf [-v var] format [arguments] ================================================================= I also cannot remember if I've ever done step 5. I would have presumed I did when it first showed up in 2015, but I wouldn't stake a million bucks on it. So if it's related to that, let me know. ================================================================= 5. If you previously installed plugins through composer, update dependencies by running: php composer.phar self-update php composer.phar update --no-dev =================================================================
Here's 1.3.4 in the GitHub history: https://github.com/gentoo/gentoo/tree/7e1732491e7d943eaeecb4c84485ae57dfab3d5b/mail-client/roundcube
(In reply to Philippe Chaintreuil from comment #10) > Here's 1.3.4 in the GitHub history: > https://github.com/gentoo/gentoo/tree/ > 7e1732491e7d943eaeecb4c84485ae57dfab3d5b/mail-client/roundcube I diff'd the 1.3.4 and 1.3.6 ebuilds and roundcube source and can't see anything that would suggest the 1.3.4 ebuild auto-magically generated those two files, so I'm at a loss as to how they were updated. I must have edited them manually and forgot to include them in the patch. Sorry for the confusion I caused.
I wasn't seeing these issues, but composer had reinstalled the vendor/pear junk for me. It looks like we need a good deal more work here to entirely force composer to use system resources because it's too dumb to look there first. Or, we can go the easy way and drop the PEAR dependencies in the ebuild.
What's the status of this? I just upgraded to 1.3.8 and it's back. But I'll admit, I didn't run either of the "php composer.phar" commands.
I've never used this plugin before, but enabling it for mail-client/roundcube-1.3.8 also triggers this error.
Just figured I'd mention, since the 1.4.0 ebuild switched to using the complete dist install, this bug shouldn't exist in the newer ebuilds (>=1.4.0).
(In reply to Philippe Chaintreuil from comment #15) > Just figured I'd mention, since the 1.4.0 ebuild switched to using the > complete dist install, this bug shouldn't exist in the newer ebuilds > (>=1.4.0). I just migrated from 1.3.8 to 1.4.2 and can confirm that this bug is no longer relevant.
