This is a bump request for horde 4 and all of its applications. This is the new major release. Reproducible: Always
This will take a while as Horde now consists out of several dozens of PEAR packages.
Just for your information: I've created several ebuilds for horde. At least all that are necessary to install horde-webmail. You'll find them in my overlay (funroll-loops). So far horde installs fine and the initial configuration works too. I did not have the time to completely configure horde yet.
Today I had the time to configure horde. At least imp works fine. I did not really test the other components yet but I don't think there'll be any problems.
*** Bug 382113 has been marked as a duplicate of this bug. ***
Hi Daniel, I finally got some time to try your ebuilds, but I'm getting this error: Unknown channel "pear.horde.org" Parsing of package.xml from file "/var/tmp/portage/dev-php/Horde_Template-1.0.0/work/Horde_Template-1.0.0/package.xml" failed Cannot download non-local package "/var/tmp/portage/dev-php/Horde_Template-1.0.0/work/Horde_Template-1.0.0/package.xml" install failed Also, why is horde in dev-php now, instead of www-apps?
(In reply to comment #5) > Hi Daniel, > > I finally got some time to try your ebuilds, but I'm getting this error: > > Unknown channel "pear.horde.org" > Parsing of package.xml from file > "/var/tmp/portage/dev-php/Horde_Template-1.0.0/work/Horde_Template-1.0.0/package.xml" > failed > Cannot download non-local package > "/var/tmp/portage/dev-php/Horde_Template-1.0.0/work/Horde_Template-1.0.0/package.xml" > install failed > > Also, why is horde in dev-php now, instead of www-apps? running: pear channel-discover pear.horde.org fixes the issue. Should this be a part of the ebuild?
There is also no vhost use flag anymore. How do you install the new horde as a virtual host?
(In reply to comment #6) > [...] > running: > > pear channel-discover pear.horde.org > > fixes the issue. Should this be a part of the ebuild? This problem is within the in-portage-tree Horde_Template ebuild of which Alex (comment #1) is the maintainer. I were able to fix it by changing line 7: --- snip --- inherit php-pear-r1 --- snap --- to: --- snip --- PHP_PEAR_CHANNEL="pear.horde.org" PHP_PEAR_PN="Horde_Template" inherit php-pear-lib-r1 --- snip --- The change of the inherited eclass is necessary since only the library version contains code like this (line 35 ff.): --- snip --- # @FUNCTION: php-pear-lib-r1_pkg_setup # @DESCRIPTION: # Adds required PEAR channel if necessary php-pear-lib-r1_pkg_setup() { if [[ -n $PHP_PEAR_CHANNEL ]] ; then if [[ -f $PHP_PEAR_CHANNEL ]]; then pear channel-add $PHP_PEAR_CHANNEL else pear channel-discover $PHP_PEAR_CHANNEL pear channel-update $PHP_PEAR_CHANNEL fi fi } --- snap --- But I don't know if this is the correct eclass. So Alex could you please either change the ebuilds or change the php-pear-r1 eclass... or tell us how to circumvent this problem?
First off all, I have not yet had the chance to look at Daniel's ebuilds, so I cannot make comments about them. I'll comment on what I have planned. (In reply to comment #5) > Also, why is horde in dev-php now, instead of www-apps? Horde is now split into generic libraries (Horde-*) which are already in the official tree. These are in dev-php. The actual applications (horde framework, imp, etc) will (at least in the official ebuilds) be in www-apps. (In reply to comment #7) > There is also no vhost use flag anymore. How do you install the new horde as a > virtual host? I've talked to Jan of upstream about this. He thinks that there should be only one horde installation per PEAR installation (there is also a configuration setting in PEAR added by Horde-Role, specifying where that installation is, so that path is needed and has to be unique). Due to that, there will be no support for webapp-config/USE=vhosts. If you need a second horde installation, you'll have to manually create another PEAR setup as well (this is explained on the horde website) (In reply to comment #8) > > But I don't know if this is the correct eclass. So Alex could you please either > change the ebuilds or change the php-pear-r1 eclass... or tell us how to > circumvent this problem? I'll have to see the issue for myself before fixing anything there, sorry. I'll update this bug with any progress. Thanks.
There is a minor problem with dev-php/Horde_Db-1.0.5 ("Automated version bump" on Sept 17th): --- snip --- mv: cannot stat `horde-db-migrate': No such file or directory --- snap --- (which results in a failing emerge) The 1.0.1 version included "bin/horde-db-migrate", but version 1.0.5 includes "bin/horde-db-migrate-component". Thus, there is no need to move the script anymore... I guess. @Alex: Thanks, for maintaining the packages.
I'm still not quite sure about the installation guys. Please enlighten me if I'm missing anything. Installing horde manually using pear installation method (which is the official default method), I have no problems. Using this method, you are asked for a basedir for horde and it will generate the files for you there. Since you are not asked for any basedir with the portage version we are trying in this bug, what is the value for basedir? Where are the horde files installed with the ebuilds provided in this bug?
Hey Alex, what's your status on this bug? It has been quite a while now that horde 4 is out and we still don't have this on gentoo...
(In reply to comment #12) > Hey Alex, what's your status on this bug? It has been quite a while now that > horde 4 is out and we still don't have this on gentoo... My use case for horde is gone, so I'm not able to maintain it anymore. It's just too many packages with too little use for me now. The ~70 horde library packages I added to the tree will likely be removed again unless someone wants to take care of them (for instance via the proxy maintainer team [1]; or joining the project as a developer to maintain horde, in that case talk to me and we'll work things out). [1] http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
*** Bug 419781 has been marked as a duplicate of this bug. ***
*** Bug 462574 has been marked as a duplicate of this bug. ***
Hi guys, since nobody is doing this, I thought I'll give it a try. For now I created an overlay to work on at https://github.com/ChristianS99/horde-overlay Right now it contains two ebuilds: www-apps/horde-5.1.4 and dev-php/Horde_Role-1.0.1 Here at me I can emerge both, and also webapp-config is fine. But it isn't useable, because the Horde dependencies are missing. I just wanted to ask if someone can look at the ebuils, especially the webapp one, because i don't have much experience at writing ebuilds. Am I missing something important, or can anything be done better? The next step will be creating the ebuild for all the dependencies. Would be nice to get some feedback!
Christian, kudos for having a go at this. I guess a starting point would be to do the full install via pear as per upstream and examine all the output. The full distribution with all dependencies, I know, also potentially includes some pecl binaries, external things like imagemagick and gpg etc, and certain modules of php itself also, so your ebuilds will need a lot of DEPENDs and there will be quite a few flags for optional parts too I guess. But the pear output should show you all of this so it's just a matter of mapping it all onto existing ebuilds/flags, and the same process amongst your own packages. Where you may need to get more creative is in adapting the Horde_Role setup scripts for webapp-config usage, but I can't see this being super complicated: just talk to devs currently maintaining other webapps, I'm sure they will have some pointers. I doubt even vhosts support is a big issue once you've got the above worked out; the main part that may be a bit more complex is horde's unusual nature of some webapp packages being dependent upon others (and of course even the groupware and webmail "metapackages" to cap it off), but I don't think it's beyond webapp-config's capability to install one app inside another: this is basically what it used to do. Best of luck; I don't know much about packaging but I know a bit about horde itself, so feel free to ask if I can be of any help.
so, now i have made ebuilds for the non-apps with the help of a small script. seems to be fine so far. for the actual apps, only the Horde framework itself has an ebuild (yet). Feel free to test, whoever likes. But I have a problem, that, I think, comes from horde itself. Robin, maybe you can help, or I need to ask at horde directly: when i installed the horde framework and go to the weblocation I'm logged in as administrator, but when I go to Administration->Configuration, I only get a blank page. there you can set auth backend, database config etc. in the error logs i see this: Call to a member function getName() on a non-object in /usr/share/php/Horde/Core/Db/Migration.php on line 91 Seems for me like an horde error, it also happens, when i don't install it via my ebuilds, but through pear.
(In reply to Christian from comment #18) > when i installed the horde framework and go to the weblocation I'm logged in > as administrator, but when I go to Administration->Configuration, I only > get a blank page. there you can set auth backend, database config etc. in > the error logs i see this: > Call to a member function getName() on a non-object in > /usr/share/php/Horde/Core/Db/Migration.php on line 91 > > Seems for me like an horde error, it also happens, when i don't install it > via my ebuilds, but through pear. Looking at the code at that location, the problem looks to be that the package object instantiation fails for some package. Here's the code where it fails: ... . // Loop through installed PEAR packages. . $registry = $pear->getRegistry(); . foreach (glob($pear->get('data_dir') . '/*/migration') as $dir) { . $app = $registry->getPackage( . basename(dirname($dir)), 'pear.horde.org')->getName(); ... This bit of code searches for all package-names that fit the pattern /usr/share/php/data/<pkgname>/migration (That is, all subdirs of PEAR's data directory that themselves have a subdir called 'migration') So what appears to be going wrong is that for one of the dirs it thusly identifies, it can't find a corresponding package in PEAR's registry, or at least not under the horde channel (pear.horde.org). There are two causes that spring to mind: 1) Cruft from a previous install, such as a package that's no longer part of the horde distribution but didn't get uninstalled. 2) By unfortunate coincidence, an unrelated package that's not part of horde but happens to install a 'migration' dir that gets matched by the code above. You can establish the problematic dir by comparing the output of echo /usr/share/php/data/*/migration with the Horde portion of pear list-all (that should be it, though it's not showing any of the horde packages for me right now - no idea why!) It does seem like an upstream bug if it's possible for a non-valid path to be passed to this code, and the failed instantiation not to be picked up and dealt with. I'd need to delve a little deeper to advise a solution, though.
I think the problem is, when you install a pear/horde package via portage it doesn't register itself at pear. I have a few pear packages installed with portage, but they don't show up in pear list-all. that seems to be a portage problem. or better a portage/horde interaction problem. I have seen a pear command that registers a package to pear but doing no install. maybe this could be a way to go? I'll give it a try. But this could give problems with vhosts: eg. a vhost were you install horde and imp and anoither were you have horde and kronolith. Both horde installations would show horde, imp and kronolith, when horde get's is information from the pear registry. BTW: I got it working with a custom pear install, that was a mistake at my place
(In reply to Christian from comment #20) > I think the problem is, when you install a pear/horde package via portage it > doesn't register itself at pear. I have a few pear packages installed with > portage, but they don't show up in pear list-all. that seems to be a portage > problem. or better a portage/horde interaction problem. I have seen a pear > command that registers a package to pear but doing no install. maybe this > could be a way to go? I'll give it a try. > But this could give problems with vhosts: eg. a vhost were you install horde > and imp and anoither were you have horde and kronolith. Both horde > installations would show horde, imp and kronolith, when horde get's is > information from the pear registry. > > BTW: I got it working with a custom pear install, that was a mistake at my > place Hmm, seems different for me. The pear packages I've got installed via portage are shown by pear list-all, but the horde ones installed via pear aren't (although the registry still lists the channel, and upgrades for horde packages). It could be that "native" pear installs and portage-arbitrated ones interfere with one another's registration in some manner. I've probably upgraded a package in portage more recently than my last upgrade of horde-pear, so the ball is in portage's court, as it were. I think the input needed here is from maintainers of pear, and/or of existing in-tree pear packages, to maybe help you identify some missing step from your ebuilds. Re the vhosts issue, I reckon this also goes to the issue of "pear run-scripts horde/horde_role" being rolled into the installation and configuration steps per-vhost in webapp-config. All the subordinate packages down from horde_role are, I think, pretty basic in terms of installation; it's just that all the others slot inside hte base horde install, and (normally) the configuration done with horde_role's scripts is read by them. So when webapp-config installs them to (or upgrades them within) a given vhost, it just needs to keep track of the rootdir for the install (which may not be the rootdir of the vhost; it can be specified as an argument to webapp-config). Horde's scripts also need to know which database config to use, and that is stored within the install. I looked a little more at the migration code that errored on you above, and I see that what it does is 1. Look among the packages installed in your local horde install root for migration dirs; then 2. Look among the central (pear) packages for any that aren't installed locally, and add them onto the same list to notify the administrator what needs to be migrated. Maybe a question worth asking the horde guys is why migrations of packages that aren't included in your local install should be of interest within the local (webapp) administrator context, as (I'd think) these should be outside the administrator's power to deal with. If they exist, and are critical to operation, should horde run at all? Then again they have their own ideas about vhosting, so you definitely need to look at that with a view to how you'd reconcile it with webapp-config.
about the pear packages: have you used pear directly once? maybe the registered pear packages come from there. maybe you could install a new pear package you don't have with portage and check if it is know by pear then. I had the experience that pear doesn't now about it.
I've used pear directly for everything to do with horde, at least since first install of H5 (no choice). I have some installed via portage, but these could be due to other webapp dependencies. Let me just check one thing here: am I right in thinking that list-all should show me all *available* packages, not just those installed? I see some packages with two version-numbers next to them (which are the same, eg with Auth_SASL it's 1.0.6 for both). So I assume the second number, where it appears, denotes the version installed? I dunno whats going on, something is very broken I fear :S I tried emerging PEAR-PHP_Beautifier (definitely never installed before by pear or portage); it was in list-all before and after, and in neither case did it show two version-numbers in the readout. Make of this what you will...
(In reply to Robin Bankhead from comment #23) > Let me just check one thing here: am I right in thinking that list-all > should show me all *available* packages, not just those installed? I see > some packages with two version-numbers next to them (which are the same, eg > with Auth_SASL it's 1.0.6 for both). So I assume the second number, where > it appears, denotes the version installed? I dunno whats going on, > something is very broken I fear :S You're right of course. when i said list-all, I meant list. Today I have a little time to work on it again, and will try registering the packages at pear with "pear install --register-only" and see how this works.
this was removed
