Created attachment 3318 [details] notes on installing php-5.3.6 and horde 4 on SME 8B6 Horde Groupware Webmail Edition 4.0 is released now. Just wanted to start off by sharing some ideas on packaging horde 4 rpms, so not to duplicate any other effort. It requires php 5.2.0 or higher, so that is a requirement first. I'll attach rather than copy and past my notes on initial testing of installing php-5.3.6 rpm's and installing horde 4 by the manual method they document as it is only really useful for seeing what is required by horde 4 and what exactly gets installed, so we know what needs to be packaged. Does anyone know of anyone packaging horde 4 already for Fedora? Just some notes: -This guy has packaged it for OpenSuse: http://www.ralf-lang.de/tag/horde-4/ -A post about some warnings going from Horde 3 to 4 http://www.ralf-lang.de/2011/06/01/migrating-horde-3-to-horde-4-top-6-ways-to-mess-up/
closing, won't fix
closing, won't fix for SME9, installed on sme10
+1
bump, I come to check if there are any changes here? I have also seen this : https://forums.contribs.org/index.php?topic=50969 around
(In reply to John H. Bennett III from comment #80) > Then you must be using Remi's files, because the files I use don't have > php-horde prefixed on them. If those are the files you want to use, then I > won't be much help. I started out using Remi's files, but something didn't > work. What, I don't remember. I do know that using Remi's Pear-1.9.5 broke > the install as some of the paths were changed. I do not know if we well understood each other, the 'BuildRequires' is just for the build phase and it comes from epel, not remi. It is different that 'Requires' which is here to install the rpm on the computer (BuildRequires is just here for the mock chroot) > > -does it is possible to go back to the old version once horde5 is installed > > ???? > > The only way back is to remove all of the horde5 files, reinstall the horde3 > rpm's, and restore the MySQL DB from before the upgrade, as the db schema > changes a lot from 3 to 5. well quite impossible, we ought to put a big warning on the howto, but when a guy will use H5, hared to go back to H3 > > -How trade if someone has installed some rpms of remi (I believe that we can > > have some noises) ???? I answer myself, maybe we can put a Requires : php < 5.4 > It could be very possible to use the files from epel, with potentially > little work. Last I looked, I believe Horde_Role would need to be changed > to set the data directory, or SME Server adapted to look for horde at > whatever location is set in the epel version. if it is possible, this could reduce our maintenance work > All horde5 updates are new tarballs. cool
(In reply to Stephane de Labrusse from comment #79) > after some quick tests on my buildserver, I can build > > horde-5.2.7 if I add > -BuildRequires: php-horde-Horde-Role > -mock configuration epel-6-x86_64 (it should be the same with i386) > ingo > -BuildRequires: php-horde-Horde-Role > -mock configuration epel-6-x86_64 (it should be the same with i386) > > -php-pear-* > -mock configuration epel-6-x86_64 (it should be the same with i386) > > -Horde_* > -mock configuration epel-6-x86_64 (it should be the same with i386) > > -all smeserver-* e-smith-* > -mock configuration smeserver-9-i386-base > Then you must be using Remi's files, because the files I use don't have php-horde prefixed on them. If those are the files you want to use, then I won't be much help. I started out using Remi's files, but something didn't work. What, I don't remember. I do know that using Remi's Pear-1.9.5 broke the install as some of the paths were changed. > I'm concerned by different topics, maybe you have the answers > > -does it is possible to go back to the old version once horde5 is installed > ???? The only way back is to remove all of the horde5 files, reinstall the horde3 rpm's, and restore the MySQL DB from before the upgrade, as the db schema changes a lot from 3 to 5. > > -How trade if someone has installed some rpms of remi (I believe that we can > have some noises) ???? > > -I can see that some rpms called php-pear-* can be found in epel but of > course with an inferior version than those proposed in the bundle. I > imagine it is important to keep them ???? Of course less we have rpms to > maintain more it is fun :) > It could be very possible to use the files from epel, with potentially little work. Last I looked, I believe Horde_Role would need to be changed to set the data directory, or SME Server adapted to look for horde at whatever location is set in the epel version. > > after that I have a question to daniel, > > -How I can set in the spec file (or somewhere else) the mock configuration > of a rpm (for example epel-6-x86_64) ???? > > Concerning the maintenance of rpms on buildsrv, either you import a new > tarball to cvs, or a patch if you just want to modify some tiny things. For > example in the case of horde, theoretically, once the spec and the first > tar.gz are imported, the only modification will concern the horde.tar.gz. All horde5 updates are new tarballs.
after some quick tests on my buildserver, I can build horde-5.2.7 if I add -BuildRequires: php-horde-Horde-Role -mock configuration epel-6-x86_64 (it should be the same with i386) ingo -BuildRequires: php-horde-Horde-Role -mock configuration epel-6-x86_64 (it should be the same with i386) -php-pear-* -mock configuration epel-6-x86_64 (it should be the same with i386) -Horde_* -mock configuration epel-6-x86_64 (it should be the same with i386) -all smeserver-* e-smith-* -mock configuration smeserver-9-i386-base I'm concerned by different topics, maybe you have the answers -does it is possible to go back to the old version once horde5 is installed ???? -How trade if someone has installed some rpms of remi (I believe that we can have some noises) ???? -I can see that some rpms called php-pear-* can be found in epel but of course with an inferior version than those proposed in the bundle. I imagine it is important to keep them ???? Of course less we have rpms to maintain more it is fun :) after that I have a question to daniel, -How I can set in the spec file (or somewhere else) the mock configuration of a rpm (for example epel-6-x86_64) ???? Concerning the maintenance of rpms on buildsrv, either you import a new tarball to cvs, or a patch if you just want to modify some tiny things. For example in the case of horde, theoretically, once the spec and the first tar.gz are imported, the only modification will concern the horde.tar.gz.
Just some of the initial packages were created using pear make-srpm-spec to get most of the spec file created. On my local system, I still use mezzanine to create rpm's. In the instances where the pear package is already installed, I have to uninstall the previous version to build the updated package. From what others have said how the build system works in a chroot environment, then I was convinced that there wouldn't be any issue with getting them built on that system. My other concern was how to maintain them. I typically look for updates either after I have loaded a new test server, once a month, or if there is a major release. Since the packages are now individual, some fixes don't need to wait for the major component releases. I do have MOCK set up on a SME 9 Server, but I don't remember how to use it, I could look at the how to and see if I could get things working and build a package over and over and see if there are any issues. It might be better to wait on you since we know the mock environment better than I.
(In reply to John H. Bennett III from comment #76) > I don't know how to do that. I read below that you build rpms with pear and you have some doubts on how the buildsys can handle that. Possibly we can try with the mock configuration to epel6...i will have a go on my local build server thoughts ????
(In reply to Stephane de Labrusse from comment #75) > Hi john > > I wonder if you want to push your work to the sme9contribs Tree. I don't know how to do that.
Hi john I wonder if you want to push your work to the sme9contribs Tree.
For anyone following this, I have regained access to my contribs directory, and have updated the horde files to the latest versions, current as of this comment. Should be available once the mirrors sync.
Set target milestone.
set importance to normal. Set package.
(In reply to Rudi from comment #70) Rudi, I have raised a new bug 8765 to address your issue.
(In reply to Mats Schuh from comment #69) > Rudi, can you post the content of > /home/e-smith/files/users/ws-rosimaier/.vacation.msg ? > > The German word "Von:" in the first line of the vacation message generated > through userpanel will be ignored (and the default server domain will be > used instead). Try to replace "Von:" with the English word "From:" - IIRC > everything before the first blank line in the vacation message goes to the > mail header, whereas everything below goes to the body of the mail, and > "From" is the mail header keyword you probably want to set. > > Not sure if this issue is Horde 5 related, though...perhaps you should raise > a separate bug, if the problem persists. Hi Mats, that did the job! Changing to FROM worked fine. I suggest to edit the Explanation above the Vacation Form!? If that text whould explain everything this kind of "Bug Reports" whould not happen! :-)
Rudi, can you post the content of /home/e-smith/files/users/ws-rosimaier/.vacation.msg ? The German word "Von:" in the first line of the vacation message generated through userpanel will be ignored (and the default server domain will be used instead). Try to replace "Von:" with the English word "From:" - IIRC everything before the first blank line in the vacation message goes to the mail header, whereas everything below goes to the body of the mail, and "From" is the mail header keyword you probably want to set. Not sure if this issue is Horde 5 related, though...perhaps you should raise a separate bug, if the problem persists.
I have found another problem .. SME Server 9 all updates installed , I upgraded Horde to 5.2.1 as described somehere below in this Bugreport; Now there also is installed userpanels and to it "Abwesenheitsnotiz" i guess it is called "Vaccationmessage" or something similar. The server is named "www.alleskunst.at" the Domain kidzwear.at is hosted on this server and has a user named "ws-rosimaier" with a pseudonym called "rosi.maier@kidzwear.at" Now i did change the User Basic Settings inside Webmail 5.2.1 so the Emailsettings of this User is "rosi.maier@kidzwear.at" After this i did Enter the User-manager Panel with the Users Login Data and changed the Vacccation message to: ---------------------------- Von: Rosmarie Maier Agentur Kidzwear <rosi.maier@kidzwear.at> Subject: Abwesenheitsnotiz Hallo, Ich bin wieder am Montag, 15.9.2014 im Büro. In wichtigen Angelegenheiten wenden Sie sich bitte an meine Kollegin Karin Pscheidt, office@kidzwear.at Vielen Dank! Mit freundlichen Grüßen, Rosmarie Maier ---------------------------- Now when i send an eMail to rosi.maier@kidzwear.at i get the Vaccations message correct BUT it comes from the sender "ws-rosimaier@alleskunst.at" which should not be that way and this is a bug because it and was not so on the old installations of - SME, Horde and Vaccation Panel - i had in the past 12 years. Is this a useable description? please post questions and you can try sending testmails to rosi.maier@kidzwear.at to see yourself .. best Rudi
added some bug in reference : 8529 8528 8523 8522
Thanks john, that solves my issue I suggest that you do a db command to activate it easily. In the meanwhile I found a bug on chrome and firefox (validated on the two both) that when you try to use the 'mobile (smartphone/tablet)' display, my web browser detect a 'redirect loop' and i cannot reach the webmail page. I tried with and without the new setting you suggested.
(In reply to Stephane de Labrusse from comment #64) > (In reply to Charlie Brady from comment #63) > > You don't need a real dnsname if you are on a local network, and using the > > SME server for name resolution. > > > Indeed but I use My smeserver in server_only mode, and all my network is > managed from an openwrt router, which is able to trade with dns name (sme, > leo, vanessa....) that I manually set in its Panel to an uniq IP. > > From my point of view it is more simple to remember rather an ip. > > > > I don't know the pros and cons of using cookie v non-cookie sessions, but I > > don't think you should demand that bare hostnames work in URLs. > > Like You Charlie I don't have ideas on pros and cons, but I hope that we > could have something workable for those who use their sme in server_only. If > you have to use an ip, it is not confortable. > > > The 'U' in URL is not true when you use unqualified hostnames. > > "https://sme9dev64/webmail/" could be a different resource to different > > hosts, even on the same local network, depending on their DNS configuration. > > I don't understand what you are meaning charlie, how I could have a same dns > name for several ip since the dns name is set manually in the hostname Panel > in my router with an uniq IP. > > Excepted if My dns server could be filled by a dhcp server Then you could be > right. > > I'm not sure that I have a good network practice but it is like that I > manage it :) To fix this, you will need to create a custom template of /etc/e-smith/templates/home/httpd/html/horde/config/conf.php/100ConfHordePHP and change $conf['session']['use_only_cookies'] = true; to $conf['session']['use_only_cookies'] = false; I don't know how this works on horde3, as we have the same true setting for cookies. If conf.php changes, then you would need to update your templates if it was appropriate. I don't know if it's worth it to make this a DB setting or now. Since this is currently in contrib status, I guess I could.
(In reply to Charlie Brady from comment #63) > You don't need a real dnsname if you are on a local network, and using the > SME server for name resolution. Indeed but I use My smeserver in server_only mode, and all my network is managed from an openwrt router, which is able to trade with dns name (sme, leo, vanessa....) that I manually set in its Panel to an uniq IP. From my point of view it is more simple to remember rather an ip. > I don't know the pros and cons of using cookie v non-cookie sessions, but I > don't think you should demand that bare hostnames work in URLs. Like You Charlie I don't have ideas on pros and cons, but I hope that we could have something workable for those who use their sme in server_only. If you have to use an ip, it is not confortable. > The 'U' in URL is not true when you use unqualified hostnames. > "https://sme9dev64/webmail/" could be a different resource to different > hosts, even on the same local network, depending on their DNS configuration. I don't understand what you are meaning charlie, how I could have a same dns name for several ip since the dns name is set manually in the hostname Panel in my router with an uniq IP. Excepted if My dns server could be filled by a dhcp server Then you could be right. I'm not sure that I have a good network practice but it is like that I manage it :)
(In reply to Stephane de Labrusse from comment #62) > A fatal error has occurred > Session cookies will not work without a FQDN and with a non-empty cookie > domain. Either use a fully qualified domain name like > "http://www.example.com" instead of "http://example" only, or set the cookie > domain in the Horde configuration to an empty value, or enable non-cookie > (url-based) sessions in the Horde configuration. > Details have been logged for the administrator. > -------------------------- > > Not sure if it is wanted, but all my environment doesn't have real dnsname > to reach them, since I'm on a local network. You don't need a real dnsname if you are on a local network, and using the SME server for name resolution. I don't know the pros and cons of using cookie v non-cookie sessions, but I don't think you should demand that bare hostnames work in URLs. The 'U' in URL is not true when you use unqualified hostnames. "https://sme9dev64/webmail/" could be a different resource to different hosts, even on the same local network, depending on their DNS configuration.
Hi john I have tested your horde5 and I found this when I want to perform a login from https://sme9dev64/webmail/ ------------ A fatal error has occurred Session cookies will not work without a FQDN and with a non-empty cookie domain. Either use a fully qualified domain name like "http://www.example.com" instead of "http://example" only, or set the cookie domain in the Horde configuration to an empty value, or enable non-cookie (url-based) sessions in the Horde configuration. Details have been logged for the administrator. -------------------------- Not sure if it is wanted, but all my environment doesn't have real dnsname to reach them, since I'm on a local network. Of course if I use the IP I don't Have this error message. Moreover it was workable with the horde3 version, so it could be nice if we can avoid to use IP
(In reply to Greg Swallow from comment #59) > I've been following the progress in EPEL and I think all the horde rpms we > need are in epel and epel-testing now. Not saying the ones John has made > are inferior just that it will save hours and hours of time if we let the > EPEL maintainers keep them up to date. (Is it 80+ rpms?) Assuming that is, > we can use them and modify our smeserver-horde etc rpms to match the > directories they use. Doesn't matter to me. It hasn't been that hard to keep up, but there have been a lot a changes/updates going on. Horde 5.2 has been released, and I've updated the work I've been doing. Anyone that wants to get a look, here's how. ssh to SME Server cd /root wget http://mirror.contribs.org/contribs/jbennett/horde/horde52-rpms.zip #wget http://mirror.contribs.org/contribs/jbennett/horde5/horde52-srpms.zip # Above is optional unzip horde52-rpms.zip cd horde52 sh Install-horde52.sh signal-event post-upgrade ; signal-event reboot If other RPM's are used and file locations are changed, then there might be quite a bit of work, at least on the smeserver specific rpms. I haven't looked at that, I just tried to maintain what was already there, to hopefully minimize the potential upgrade headache. I'll post an item in the forums so that people can at least get a look at it on a test server if they want to give it a test run.
I do not test the work of john (one thing on my todo list) but indeed it is really great idea to have a new horde in sme9.x and it is also a good idea to let the work done by epel. For memory packages from epel are really easily importable in the buildsys and moreover it is already like that we do with some contribs (phpmyadmin for example)
I've been following the progress in EPEL and I think all the horde rpms we need are in epel and epel-testing now. Not saying the ones John has made are inferior just that it will save hours and hours of time if we let the EPEL maintainers keep them up to date. (Is it 80+ rpms?) Assuming that is, we can use them and modify our smeserver-horde etc rpms to match the directories they use.
No time to get into 9.0 but let's polish it for 9.1
(In reply to Rudi from comment #56) > Sorry, i did mean this package from John Bennett: > http://mirror.contribs.org/contribs/jbennett/horde51/horde51-rpms.zip > > Everything perfect! > I Suggest to take this into the Core Package of the RC .. and i think status > should be changed to fixed! > > In my opinion this is a serious issue .. the horde still in the releases is > like a dirty, rusty spot on this new SME you guys are building here! > > best > Rudi I also think that this works really well. However SME9.1 is more likely as it is a late change to introduce now. I expect 9.1 by summer.
Sorry, i did mean this package from John Bennett: http://mirror.contribs.org/contribs/jbennett/horde51/horde51-rpms.zip Everything perfect! I Suggest to take this into the Core Package of the RC .. and i think status should be changed to fixed! In my opinion this is a serious issue .. the horde still in the releases is like a dirty, rusty spot on this new SME you guys are building here! best Rudi
Hy everyone, i am running a install package from stehpan (horde 5.1) on serveral of my servers (SME8 and 9) since a few weeks and this works perfect for me and my customers!!
(In reply to Greg Swallow from comment #52) > Might be worth looking at using the horde rpms here > -http://rpms.famillecollet.com/enterprise/6/remi/x86_64/ > They are being actively maintained it seems. > > They are also slowly being submitted to EPEL, but it's been a year since > that process started, so I don't think that's worth waiting for. These are > tied to the php version they're built with, which is 5.4 in that repo. Not > sure if there is also the desire to upgrade php in SME 9.1... He seems to > keep the php version up to date too. That's where I took the initial versions from to build what I have today. Took a while for me to fully understand everything, but once Horde_Role was updated to reflect the correct directory we use, and php-channel-horde is installed, everything else falls in place. Building the RPM's isn't an issue now, but you do have work around what I stated in comment 40. Even with Remi's rpm's the same thing is true, unless we just suck in what he's done and not rebuild the rpm's from his sources. Either way, what I have is current as of last week, and in my contribs directory. There were some additional updates released this week that I haven't added.
(In reply to Greg Swallow from comment #52) > Might be worth looking at using the horde rpms here > -http://rpms.famillecollet.com/enterprise/6/remi/x86_64/ > They are being actively maintained it seems. > > They are also slowly being submitted to EPEL, but it's been a year since > that process started, so I don't think that's worth waiting for. These are > tied to the php version they're built with, which is 5.4 in that repo. Not > sure if there is also the desire to upgrade php in SME 9.1... He seems to > keep the php version up to date too. For a newer PHP can we use the RedHat Software Collection https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/ John, I've nearly finished 9.0 Beta4 so will have time to look at helping you get Horde 5 ready. I'm also now running SME 9 myself so have a good reason to get a modern webmail available.
Might be worth looking at using the horde rpms here -http://rpms.famillecollet.com/enterprise/6/remi/x86_64/ They are being actively maintained it seems. They are also slowly being submitted to EPEL, but it's been a year since that process started, so I don't think that's worth waiting for. These are tied to the php version they're built with, which is 5.4 in that repo. Not sure if there is also the desire to upgrade php in SME 9.1... He seems to keep the php version up to date too.
Beta 4 is being finalised so moving to RC1 for now, it may be Beta 5. A decision is needed on which Webmail to provide for 9.0
(In reply to John H. Bennett III from comment #49) > (In reply to Ian Wells from comment #47) > > I now have this running on one test VM. It looks good. > > > > It may be better to configure the CLI/PHP/MySQL shells OFF by default if > > possible. > > > > There are currently a lot of startup errors which I presume is due to the > > old horde templates. > > > > It looks modern and I'm quite happy with it. > > I don't think what you are seeing are startup errors. Those are the > messages from the horde tables being upgraded. I didn't pipe them to > /dev/null. It's probably possible to do that, but I want to see them as > there was an issue in the past where one of the updates broke something in > the table upgrades, and I wouldn't have seen it if the messages weren't > displayed. Maybe having them displayed while doing the development and > testing, and not displaying them on production systems. I'll look into > that as well. I found some time to look at this today. I did make the change to send the majority of the horde db migration output to /dev/null. You no longer see all the DB migration output, but on a new install with horde 3 already present, or no horde DB, you will see the following: Mar 24 10:43:35 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'imp_sentmail_seq' #011DROP TABLE `imp_sentmail_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:37 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'ingo_rules_seq' #011DROP TABLE `ingo_rules_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:38 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'ingo_shares_seq' #011DROP TABLE `ingo_shares_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:40 www HORDE: [horde] SQL QUERY FAILED: Table 'horde.rampage_types' doesn't exist #011SELECT type_id, type_name FROM `rampage_types` WHERE type_name IN #011 ('calendar','event') [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:41 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'turba_shares_seq' #011DROP TABLE `turba_shares_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:45 www HORDE: [horde] SQL QUERY FAILED: Table 'horde.rampage_types' doesn't exist #011SELECT type_id, type_name FROM `rampage_types` WHERE type_name IN #011 ('task') [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:46 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'mnemo_shares_seq' #011DROP TABLE `mnemo_shares_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:53 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'horde_groups_seq' #011DROP TABLE `horde_groups_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:54 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'horde_histories_seq' #011DROP TABLE `horde_histories_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:55 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'horde_perms_seq' #011DROP TABLE `horde_perms_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:57 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'horde_vfs_seq' #011DROP TABLE `horde_vfs_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:43:58 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'horde_muvfs_seq' #011DROP TABLE `horde_muvfs_seq` [pid 2318 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:44:00 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'kronolith_shares_seq' #011DROP TABLE `kronolith_shares_seq` [pid 2337 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:44:01 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'kronolith_resources_seq' #011DROP TABLE `kronolith_resources_seq` [pid 2337 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] Mar 24 10:44:05 www HORDE: [horde] SQL QUERY FAILED: Unknown table 'nag_shares_seq' #011DROP TABLE `nag_shares_seq` [pid 2337 on line 315 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"] This is because those seq tables aren't present, so they can't be dropped. On my system, I have some of those seq tables, so I don't get as much of the log noise. This is a one time event, that's just log noise. As I stated, it will occur on a new install or upgrade to 9. If we were to go this route, and someone had issues during the upgrade, then we may need to have them remove the > /dev/null in the sql/init files, in order to see the migration output. Since I hadn't upgraded an in use horde 3 MySQL database for a while, I did that again (sme9 (horde3) to sme9 (horde5), and was reminded of some more, one time events that are also log noise. If someone is using shares (address book, calendar, tasks, notes), you will receive log errors similar to the below. Mar 26 20:49:10 www HORDE: [horde] Share name f67965b40d06fdfcb0165a744f4ebf28 not found [pid 2184 on line 199 of "/usr/share/pear/Horde/Share/Base.php"] Mar 26 20:49:10 www HORDE: [horde] Share name one@thehome.com not found [pid 2184 on line 199 of "/usr/share/pear/Horde/Share/Base.php"] Mar 26 20:49:10 www HORDE: [horde] Share name two@thehome.com not found [pid 2184 on line 199 of "/usr/share/pear/Horde/Share/Base.php"] Mar 26 20:49:10 www HORDE: [horde] Share name f67965b40d06fdfcb0165a744f4ebf28 not found [pid 2184 on line 199 of "/usr/share/pear/Horde/Share/Base.php"] You will get the above for all of the shares you had set up. Those are all internal share names. Once the upgrade is completed, all of your various shares should still be in place. They are for me. Lastly, doing a backup of SME8.1 to usb, then restoring to 9, then upgrading to horde 5, yields the same info I have mentioned above. There was a bug in the activesync module that has been fixed, so I'm updating the files in my contribs directory.
(In reply to Ian Wells from comment #47) > I now have this running on one test VM. It looks good. > > It may be better to configure the CLI/PHP/MySQL shells OFF by default if > possible. > > There are currently a lot of startup errors which I presume is due to the > old horde templates. > > It looks modern and I'm quite happy with it. I don't think what you are seeing are startup errors. Those are the messages from the horde tables being upgraded. I didn't pipe them to /dev/null. It's probably possible to do that, but I want to see them as there was an issue in the past where one of the updates broke something in the table upgrades, and I wouldn't have seen it if the messages weren't displayed. Maybe having them displayed while doing the development and testing, and not displaying them on production systems. I'll look into that as well.
(In reply to John H. Bennett III from comment #46) > (In reply to Jonathan from comment #45) > > (In reply to John H. Bennett III from comment #44) > > > If the build system also exhibits the same behavior I see > > > on my local system, then yes, more needs to be understood in that area. If > > > it handles it fine, then no worries. As I said, we include PEAR-based RPM's > > > now in the base install. Are those built on the build system, or just > > > sucked in from somewhere and included? Who can look into, and answer, the > > > question on how the build system would react? > > > > The builds system builds in a chroot that is setup on every build, so I > > think uninstalling to rebuild is not a penalty on the buildsystem AFAIK. > > Would the only way to know be to take one of the SRPMS, and try to initiate > a build on the buildsystem, or a couple of builds? > > Give me until tomorrow to look/work on something. I had a look at things as > Charlie stated more work appears to be needed for the build system, and have > discovered how to build the rpm's without registering with the PEAR DB. > This may work for all the horde-related RPM's, and prevent the ability of > users upgrading the horde files via PEAR. We would also just use the > currently shipping PEAR rpm's. If things work, I'll detail as much as I can > about it, then the community can make a decision how how to proceed. I didn't get around to doing this today. Had too many family obligations. If we are serious about looking at this for 9.0, then I'll put more effort towards this. I hadn't been, because the design goal for 9 has always been to offer the same functionality that was on 8, but with RHEL6. I had planned on getting more serious after 9 was released. What I have currently works, I just don't know how it will work on the build system, and I've tried to give some detail as to what I'm seeing when I'm building the packages locally. I have some additional things to try based on some comments by Charlie. I could announce this as a contrib in the forums, and have more people begin testing and using if they want to, which should help in finding any bugs. Thoughts, please.
I now have this running on one test VM. It looks good. It may be better to configure the CLI/PHP/MySQL shells OFF by default if possible. There are currently a lot of startup errors which I presume is due to the old horde templates. It looks modern and I'm quite happy with it.
(In reply to Jonathan from comment #45) > (In reply to John H. Bennett III from comment #44) > > If the build system also exhibits the same behavior I see > > on my local system, then yes, more needs to be understood in that area. If > > it handles it fine, then no worries. As I said, we include PEAR-based RPM's > > now in the base install. Are those built on the build system, or just > > sucked in from somewhere and included? Who can look into, and answer, the > > question on how the build system would react? > > The builds system builds in a chroot that is setup on every build, so I > think uninstalling to rebuild is not a penalty on the buildsystem AFAIK. Would the only way to know be to take one of the SRPMS, and try to initiate a build on the buildsystem, or a couple of builds? Give me until tomorrow to look/work on something. I had a look at things as Charlie stated more work appears to be needed for the build system, and have discovered how to build the rpm's without registering with the PEAR DB. This may work for all the horde-related RPM's, and prevent the ability of users upgrading the horde files via PEAR. We would also just use the currently shipping PEAR rpm's. If things work, I'll detail as much as I can about it, then the community can make a decision how how to proceed.
(In reply to John H. Bennett III from comment #44) > If the build system also exhibits the same behavior I see > on my local system, then yes, more needs to be understood in that area. If > it handles it fine, then no worries. As I said, we include PEAR-based RPM's > now in the base install. Are those built on the build system, or just > sucked in from somewhere and included? Who can look into, and answer, the > question on how the build system would react? The builds system builds in a chroot that is setup on every build, so I think uninstalling to rebuild is not a penalty on the buildsystem AFAIK.
(In reply to Charlie Brady from comment #42) > (In reply to John H. Bennett III from comment #40) > > > Lastly, if we go this route, we would need to understand how the build > > system would handle building the RPM's. > > I think you are saying John that there is still a lot work to do before > horde 5 is ready to be released with SME9. > > I think if horde cannot be released with SME9 (because of EOL issue) then we > should seriously consider polishing the roundcubemail contrib. I don't think that's what I'm saying. The current files install fine, with no issues. I simply don't know how the build system handles building RPM's from PEAR files. If the build system also exhibits the same behavior I see on my local system, then yes, more needs to be understood in that area. If it handles it fine, then no worries. As I said, we include PEAR-based RPM's now in the base install. Are those built on the build system, or just sucked in from somewhere and included? Who can look into, and answer, the question on how the build system would react?
(In reply to Charlie Brady from comment #42) > I think if horde cannot be released with SME9 (because of EOL issue) then we > should seriously consider polishing the roundcubemail contrib. There are also other options listed in the wish list under webmail. I have yet to look at any of them, and keeping an open mind.
(In reply to John H. Bennett III from comment #40) > Lastly, if we go this route, we would need to understand how the build > system would handle building the RPM's. I think you are saying John that there is still a lot work to do before horde 5 is ready to be released with SME9. I think if horde cannot be released with SME9 (because of EOL issue) then we should seriously consider polishing the roundcubemail contrib.
I will also ask the board if Horde 3 is possible and release 9.1 with a new webmail. It all depends on timing.
(In reply to Ian Wells from comment #39) > IF we adopt Horde 5 then it is a blocker for leaving the Beta phase. > > If another webmail option is chosen then this would become a contrib at > normal priority again. (In reply to Ian Wells from comment #38) > SME 9 should not use the current horde 3 as it is EOL > (It should also be removed from SME 8, but that may be more difficult) > > The question is can and should Horde be used on SME 9 I say yes, I think it's ready. I've done all I can in testing in house. I think the big knock on horde 3 is it's inconsistent and older looking menus, iy is older, and we only offer webmail, filters, and contacts. Most want the full groupware features, and syncing capabilities. If we include it, it may extend the beta cycle a bit while people get used to the new look, feel, and functionality. Lastly, the RPM's are built for how I personally wanted things to function, so the majority may not agree with that, so additional changes may be warranted/ Either way the majority goes, I definitely plan to use it myself. We may need to also look at the release cycle I talked about in comment 36. There are no set release dates, if fixes are needed, the are fixed and packages released. We'd just have to manage the release cycle on our end. Horde 5.2 will bring some additional EAS functionality, and the ability to retrieve mail from multiple accounts. You can do that now with horde 3, which I am, but they removed their fetchmail code in horde 4. I had a bad upload yesterday, so I will be re-uploading the current files later today to my contribs directory. Lastly, if we go this route, we would need to understand how the build system would handle building the RPM's. When I build these RPM's locally, it does a pear install of the package, so before I can build a newer update, I have to remove that package via - pear uninstall -n horde/horde_package - then do a build. I verified this same behavior with some of the PEAR RPM's currently included in the base install.
IF we adopt Horde 5 then it is a blocker for leaving the Beta phase. If another webmail option is chosen then this would become a contrib at normal priority again.
SME 9 should not use the current horde 3 as it is EOL (It should also be removed from SME 8, but that may be more difficult) The question is can and should Horde be used on SME 9
Moving the SME 9 discussion from Bug 7980 (In reply to John H. Bennett III from comment #19) > (In reply to Ian Wells from comment #18) > > (In reply to chris burnat from comment #17) > > > We need a decision about either moving Horde 5.1 to Contribs, or including > > > this package(s) into sme9. A decision for the Sr. Devs to make. > > > > > > Resolving back to CONFIRMED in the meantime. > > > > > > http://lists.horde.org/archives/announce/2012/000850.html > > > > We currently have Horde 3 which is now end-of-life so we cannot ship with > > that. > > > > If Horde 5 is working then we should consider changing to that before > > leaving Beta. > > > > > > John, what would it take to include Horde 5 into SME 9? > > Hi Ian, > > Currently there are 132 files, that take up 123MB. All files are current as > of 3-20-2014. I just uploaded new zip files to my contribs directory today. > > One issue some may have are the inclusion of the latest pear files. Using > horde5, those devs always harp on using the latest updates, so I have been > trying to keep up with that. Which means some of the pear files are newer > and haven't been included in the latest CentOS updates. I've been using > these without issues, but that's just me. > > If we want to consider bundling this in the next beta, I'm fine with that, > but let's move this discussion to bug 6653, and talk about how to proceed.
Mirrors seem to working. You can use this to download the horde apps (horde - webmail framework,imp - mail, ingo - filters, turba - address book, kronolith - calendar, mnemo - notes, nag - tasks). They are all current. cd /root wget http://mirror.contribs.org/contribs/jbennett/horde51/horde51-rpms.zip #wget http://mirror.contribs.org/contribs/jbennett/horde51/horde51-srpms.zip unzip horde51-rpms.zip cd horde51 sh Install-horde5.sh signal-event post-upgrade ; signal-event reboot The md5sum's are also on my contribs site. The install script looks for the files in /root/horde51/RPMS These work for me in my testing. New installs and upgrades. The download is about 40MB. I just verified working with 9b1, and 9b2 (i386 and x64). A lot of things I haven't tested, and I hadn't wanted to discuss this route until after 9.0's release and whatever the future direction was, but since there is interest, here it is as a contrib. IMO, this is a really big change from Horde 3 to Horde 5. It doesn't look at all like what people are used to. The traditional view that most use today, is no longer being actively developed, and is mostly ugly looking in the current version. Only the dynamic, and mobile views are being enhanced, and their behavior is different from what folks are used to. There is no real release cycle any longer for horde updates. Now that they are using PEAR, they are now taking the mantra of release early, release often, which initially made keeping up hard to do. This info is probably more appropriate for bug 6653. Add Comment
(In reply to Greg Swallow from comment #34) > Created attachment 3684 [details] > php-extraprovides.spec > > spec for rpm to provide missing "provides" in stock php 5.3 rpm This is no longer needed. php-common-5.3.3-22 from RHEL 6.4 that will be in the next set of updates provides all the missing bits. I'm going to try again and just start with horde, imp, ingo and turba this time.
Created attachment 3684 [details] php-extraprovides.spec spec for rpm to provide missing "provides" in stock php 5.3 rpm
With this repo configuration on SME9 *rpmforge: includepkgs=php-pecl-http *remi: includepkgs=php-hord*,php-channel-hord*,syntaxhighlighter-httpd,syntaxhighlighter,scriptaculous,prototype,prototype-httpd,scriptaculous-httpd *epel: no include/exclude ...and a empty home-built rpm installed that provides: php(language), php-ereg, php-filter and php-xmlwriter = 5.3.0 (will attach spec) Because of https://bugzilla.redhat.com/show_bug.cgi?id=837042 I can install all the Horde 4 rpms: [root@sme9alpha SPECS]# yum --enablerepo=epel,remi,rpmforge install php-horde* Installing: php-horde-Horde-Alarm noarch 2.0.3-1.el6.remi remi 50 k php-horde-Horde-Argv noarch 2.0.4-1.el6.remi remi 65 k php-horde-Horde-Auth noarch 2.0.3-1.el6.remi remi 59 k php-horde-Horde-Autoloader noarch 2.0.1-1.el6.remi remi 20 k php-horde-Horde-Browser noarch 2.0.3-1.el6.remi remi 47 k php-horde-Horde-Cache noarch 2.0.1-2.el6 epel 25 k php-horde-Horde-Cli noarch 2.0.3-1.el6.remi remi 40 k php-horde-Horde-Compress noarch 2.0.3-1.el6.remi remi 50 k php-horde-Horde-Constraint noarch 2.0.1-2.el6 epel 13 k php-horde-Horde-Controller noarch 2.0.1-1.el6.remi remi 19 k php-horde-Horde-Core noarch 2.2.0-1.el6.remi remi 1.1 M php-horde-Horde-Crypt noarch 2.1.2-1.el6.remi remi 104 k php-horde-Horde-Crypt-Blowfish noarch 1.0.2-1.el6.remi remi 29 k php-horde-Horde-Data noarch 2.0.3-1.el6.remi remi 63 k php-horde-Horde-Date noarch 2.0.3-1.el6.remi remi 69 k php-horde-Horde-Date-Parser noarch 2.0.1-2.el6 epel 38 k php-horde-Horde-Db noarch 2.0.1-1.el6.remi remi 84 k php-horde-Horde-Editor noarch 2.0.3-1.el6.remi remi 16 k php-horde-Horde-Exception noarch 2.0.3-1.el6.remi remi 41 k php-horde-Horde-Form noarch 2.0.3-1.el6.remi remi 112 k php-horde-Horde-Group noarch 2.0.1-1.el6.remi remi 27 k php-horde-Horde-History noarch 2.0.1-1.el6.remi remi 23 k php-horde-Horde-Http noarch 2.0.1-1.el6.remi remi 20 k php-horde-Horde-Icalendar noarch 2.0.3-1.el6.remi remi 120 k php-horde-Horde-Image noarch 2.0.3-1.el6.remi remi 581 k php-horde-Horde-Imap-Client noarch 2.6.0-1.el6.remi remi 164 k php-horde-Horde-Injector noarch 2.0.1-1.el6.remi remi 28 k php-horde-Horde-Itip noarch 2.0.4-1.el6.remi remi 50 k php-horde-Horde-Ldap noarch 2.0.2-1.el6.remi remi 67 k php-horde-Horde-ListHeaders noarch 1.0.1-1.el6.remi remi 17 k php-horde-Horde-Lock noarch 2.0.1-1.el6.remi remi 19 k php-horde-Horde-Log noarch 2.0.1-2.el6 epel 23 k php-horde-Horde-LoginTasks noarch 2.0.2-1.el6.remi remi 45 k php-horde-Horde-Mail noarch 2.0.3-1.el6.remi remi 35 k php-horde-Horde-Memcache noarch 2.0.1-1.el6.remi remi 17 k php-horde-Horde-Mime noarch 2.0.4-1.el6.remi remi 99 k php-horde-Horde-Mime-Viewer noarch 2.0.3-1.el6.remi remi 104 k php-horde-Horde-Nls noarch 2.0.2-1.el6.remi remi 176 k php-horde-Horde-Notification noarch 2.0.1-1.el6.remi remi 29 k php-horde-Horde-Perms noarch 2.0.3-1.el6.remi remi 54 k php-horde-Horde-Prefs noarch 2.3.1-1.el6.remi remi 66 k php-horde-Horde-Rdo noarch 2.0.1-1.el6.remi remi 42 k php-horde-Horde-Role noarch 1.0.1-3.el6.remi remi 16 k php-horde-Horde-Routes noarch 2.0.2-1.el6.remi remi 49 k php-horde-Horde-Rpc noarch 2.0.3-1.el6.remi remi 72 k php-horde-Horde-Scribe noarch 2.0.1-1.el6.remi remi 9.3 k php-horde-Horde-Secret noarch 2.0.2-1.el6.remi remi 18 k php-horde-Horde-Serialize noarch 2.0.1-1.el6.remi remi 21 k php-horde-Horde-SessionHandler noarch 2.0.1-1.el6.remi remi 29 k php-horde-Horde-Share noarch 2.0.2-1.el6.remi remi 73 k php-horde-Horde-SpellChecker noarch 2.1.0-1.el6.remi remi 17 k php-horde-Horde-Stream noarch 1.2.0-1.el6.remi remi 19 k php-horde-Horde-Stream-Filter noarch 2.0.1-1.el6.remi remi 18 k php-horde-Horde-Stream-Wrapper noarch 2.0.1-1.el6.remi remi 16 k php-horde-Horde-Support noarch 2.0.3-1.el6.remi remi 32 k php-horde-Horde-SyncMl noarch 2.0.2-1.el6.remi remi 164 k php-horde-Horde-Template noarch 2.0.1-1.el6.remi remi 19 k php-horde-Horde-Test noarch 2.2.0-1.el6.remi remi 27 k php-horde-Horde-Text-Diff noarch 2.0.1-1.el6.remi remi 37 k php-horde-Horde-Text-Filter noarch 2.0.5-1.el6.remi remi 67 k php-horde-Horde-Text-Filter-Csstidy noarch 2.0.1-1.el6.remi remi 29 k php-horde-Horde-Text-Flowed noarch 2.0.1-1.el6.remi remi 19 k php-horde-Horde-Thrift noarch 2.0.1-2.el6 epel 29 k php-horde-Horde-Timezone noarch 1.0.2-1.el6.remi remi 25 k php-horde-Horde-Token noarch 2.0.3-1.el6.remi remi 47 k php-horde-Horde-Translation noarch 2.0.1-1.el6.remi remi 19 k php-horde-Horde-Tree noarch 2.0.1-1.el6.remi remi 20 k php-horde-Horde-Url noarch 2.1.0-1.el6.remi remi 22 k php-horde-Horde-Util noarch 2.1.0-1.el6.remi remi 38 k php-horde-Horde-Vfs noarch 2.0.4-1.el6.remi remi 83 k php-horde-Horde-View noarch 2.0.2-1.el6.remi remi 53 k php-horde-Horde-Xml-Element noarch 2.0.1-1.el6.remi remi 16 k php-horde-Horde-Xml-Wbxml noarch 2.0.1-1.el6.remi remi 33 k php-horde-content noarch 2.0.2-1.el6.remi remi 32 k php-horde-horde noarch 5.0.4-1.el6.remi remi 1.6 M replacing horde.noarch 3.3.11-2.el6.sme php-horde-imp noarch 6.0.4-1.el6.remi remi 1.6 M php-horde-ingo noarch 3.0.3-1.el6.remi remi 278 k php-horde-kronolith noarch 4.0.4-1.el6.remi remi 734 k php-horde-nag noarch 4.0.2-1.el6.remi remi 946 k php-horde-turba noarch 4.0.3-1.el6.remi remi 454 k Installing for dependencies: ckeditor noarch 3.6.4-1.el6 epel 1.6 M libevent x86_64 1.4.13-4.el6 base 66 k libicu x86_64 4.2.1-9.1.el6_2 base 4.9 M liblzf x86_64 3.6-2.el6 epel 20 k libmcrypt x86_64 2.5.8-9.el6 epel 96 k libtidy x86_64 0.99.0-19.20070615.1.el6 base 127 k php-channel-ezc noarch 1-2.el6 epel 4.3 k php-channel-horde noarch 1.0-1.el6.remi remi 3.4 k php-channel-phpunit noarch 1.3-3.el6 epel 4.8 k php-channel-symfony noarch 1.3-1.el6 epel 4.6 k php-ezc-Base noarch 1.8-1.el6 epel 224 k php-ezc-ConsoleTools noarch 1.6.1-1.el6 epel 781 k php-intl x86_64 5.3.3-14.el6_3 updates 69 k php-mcrypt x86_64 5.3.3-1.el6 epel 18 k php-pear-Console-Color noarch 1.0.3-1.el6 epel 10 k php-pear-Console-Getargs noarch 1.3.5-1.el6 epel 24 k php-pear-Console-Table noarch 1.1.4-1.el6.2 epel 17 k php-pear-Date-Holidays noarch 0.21.4-2.el6 epel 45 k php-pear-File-Find noarch 1.3.1-1.el6 epel 15 k php-pear-File-Fstab noarch 2.0.3-1.el6 epel 13 k php-pear-Image-Text noarch 0.6.1-1.el6 epel 19 k php-pear-Net-DNS2 noarch 1.2.4-2.el6 epel 77 k php-pear-Net-Sieve noarch 1.3.2-1.el6 epel 19 k php-pear-Numbers-Words noarch 0.16.2-1.el6 epel 52 k php-pear-Text-CAPTCHA noarch 0.4.4-1.el6 epel 19 k php-pear-Text-Figlet noarch 1.0.2-1.el6 epel 15 k php-pear-Text-Password noarch 1.1.1-1.el6 epel 10 k php-pear-XML-SVG noarch 1.1.0-2.el6 epel 16 k php-pecl-geoip x86_64 1.0.8-3.el6 epel 14 k php-pecl-http x86_64 1.6.5-2.el6.rf rpmforge 417 k php-pecl-lzf x86_64 1.6.2-2.el6 epel 11 k php-pecl-memcache x86_64 3.0.5-4.el6 base 60 k php-pecl-ssh2 x86_64 0.11.0-7.el6 epel 31 k php-pecl-xdebug x86_64 2.1.4-1.el6 epel 143 k php-phpunit-File-Iterator noarch 1.3.2-1.el6 epel 12 k php-phpunit-PHP-CodeCoverage noarch 1.1.2-1.el6 epel 133 k php-phpunit-PHP-Invoker noarch 1.1.0-1.el6 epel 8.9 k php-phpunit-PHP-Timer noarch 1.0.2-2.el6 epel 8.4 k php-phpunit-PHP-TokenStream noarch 1.1.3-1.el6 epel 16 k php-phpunit-PHPUnit noarch 3.6.12-2.el6 epel 130 k php-phpunit-PHPUnit-MockObject noarch 1.1.1-1.el6 epel 30 k php-phpunit-Text-Template noarch 1.1.1-1.el6 epel 7.2 k php-process x86_64 5.3.3-14.el6_3 updates 37 k php-soap x86_64 5.3.3-14.el6_3 updates 138 k php-symfony-YAML noarch 1.0.6-1.el6 epel 15 k php-tidy x86_64 5.3.3-14.el6_3 updates 34 k php-xmlrpc x86_64 5.3.3-14.el6_3 updates 51 k prototype noarch 1.7.1.0-1.el6.remi remi 42 k prototype-httpd noarch 1.7.1.0-1.el6.remi remi 2.8 k scriptaculous noarch 1.9.0-1.el6.remi remi 55 k scriptaculous-httpd noarch 1.9.0-1.el6.remi remi 2.8 k syntaxhighlighter noarch 3.0.83-1.el6.remi remi 45 k syntaxhighlighter-httpd noarch 3.0.83-1.el6.remi remi 2.9 k Transaction Summary ================================================================================ Install 133 Package(s)
Update from the Forums for the records, check: http://forums.contribs.org/index.php?topic=49240.new;topicseen#new Chris, I would move this discussion to the bug tracker, but the devs really discourage people from running scripts, whether there are good intentions or not, so I think until there are some RPM's that get generated for more general testing, I'll stay here. Greg Swallow did post in the bug tracker, links to this site, http://rpms.famillecollet.com/el5.i386/ that have some horde RPM's built. The sources are here, http://rpms.famillecollet.com/SRPMS/. Over my Christmas break, I may have a look at the sources and see how hard it would be to modify them to work with SME8. Thanks John.
(In reply to Greg Swallow from comment #30) > Hi John and all, > I noticed some Fedora contributors are working on Horde 5 rpms that you > could probably use as a starting point: > http://rpms.famillecollet.com/SRPMS/ > and see: > https://bugzilla.redhat.com/buglist.cgi?quicksearch=horde > > Wish I had more time for this, but I have too many things going on now. Yep, I saw that and bookmarked that site over the weekend. I actually had some time last week and got horde 5 working via the pear method and updated SME Server specific rpm's that I modified. New installs seem to work fine, upgrades from 3 to 5 needs more testing as I'm seeing some errors with some of the shares from my current installation. My plan is to ask on the horde dev list what's going on. Someone asked in the forums about doing some testing, so I had planned to post my instructions there, just so that someone else could test and report back. I could post them here, but it's using pear at the moment, and this is something that is working for me.
Hi John and all, I noticed some Fedora contributors are working on Horde 5 rpms that you could probably use as a starting point: http://rpms.famillecollet.com/SRPMS/ and see: https://bugzilla.redhat.com/buglist.cgi?quicksearch=horde Wish I had more time for this, but I have too many things going on now.
In my contribs directory, http://distro.ibiblio.org/smeserver/contribs/jbennett/sme8/horde4/, I have uploaded the SME Server specific RPMS and SRPMS that I have been testing with for horde 4. Everything seems to be working for me in a test environment, but I do see some log noise. I've tested new and upgraded installs. I didn't work on converting any of the pear files to RPMS's as Greg did. I started to look at what Greg did, but have run out of a lot of free time, so I just use pear to install/upgrade horde. Some things I got tripped up on or don't like. When looking at preferences for global and mail, if you don't click on show advanced preferences some of the items from previous versions won't show up. I simply didn't see this and took quite a while for me to find it. The calendar no longer supports categories, but supports tags. Not sure what the tag system is supposed to give me. I can tag an item, but looking at it in the calendar, doesn't do much for me as I don't see any differences, when I choose to show tags. If you have a calendar with multiple categories, you now must create separate calendar's for each category if you want them color coded. The sidebar now refreshes on everything you do. That gets kind of old quick. If you use gollem (file manager), you are logged in via FTP if enabled, once you log into horde, instead of being logged in only when you want to use the feature. There is supposed to be SSH support for this, but I haven't looked into it. I also haven't looked at horde5, merely because I haven't had time, and I did see that clear had migrated away from it also, so I had thought about looking to see if there was anything to gain to see how they migrated, but haven't had time for that either.
This NFR is worth investigating further for the next SME release, although it should be updated for Horde 5. Office 2013 has a new ActiveSync connector, which means that it can connect to ActiveSync compatible services in full groupware mode without the need for a third party connector like Funambol (http://www.microsoft.com/office/preview/en/outlook-2013-preview). Horde 5 should support these types of connections more or less out of the box (http://wiki.horde.org/ActiveSync). I note also that ClearOS has moved over to Zarafa while deprecating Horde (see http://www.clearcenter.com/support/documentation/clearos_professional_6/6.3.0_release_notes#hordekolab). Native Outlook 2013 compatibility for free would be a killer product differentiator IMO.
(In reply to John H. Bennett III from comment #26) > I don't have a timeframe on when I'd have something working, but at least I > should be able to find some time to work on this for possible inclusion in a > future version. Anything you can do will be welcome John! Including Calendar, Tasks etc. great! Thanks. chris
Looking at this link, http://www.ralf-lang.de/2012/02/22/horde-5-is-coming-horde-3-support-ends/, tells me it's time to either work to do it, or maybe choose another package. One of the comments states about packaging the whole groupware, which I would vote yes for. A webmail system isn't complete without a calendar, tasks, etc., IMHO. I realize I could be in the minority here, but I use the calendar, tasks, and notes applications a lot. I have a working install of horde4 using the pear method. I also tried the pear make-rpm-spec command on some of the files and my rpm names didn't look like what Greg has stated, so I'll need some pointers. My current plan is to work on the e-smith-, smeserver- rpms first with my working version to make sure the templating works. Horde4 gives you the ability to use *.local.php files so that you have a place for your modifications. One question I will have is do we want to use this for just the changes we make specifically? We can move the discussion to devinfo. I don't have a timeframe on when I'd have something working, but at least I should be able to find some time to work on this for possible inclusion in a future version.
Created attachment 3361 [details] template-horde-package.spec (In reply to Jonathan from comment #24) > They are not ignored, they are skipped with an error message IIRC. The error > message states what is wrong perfectly: for some packages a requirement is > that Horde_Role is installed. True, Horde_Role is a build requirement I think for all except the channel rpm and Horde_Role itself. I added that in the attached template. But the files with role=horde aren't listed in the spec file automatically without the previous patch and the edited template > The simple solution is to first create php-pear-Horde_Role and install it. > After that you should be able to create all other packages, at least that is > how I solved it. Maybe see what you can do to improve this template attached. I didn't try building them all with it yet, but just wanted to post it here since we both seem to be working on it. Greg
(In reply to Greg Swallow from comment #22) > The one part that was still not working for me is that the horde packages > xml files that list files like: > <file baseinstalldir="/" md5sum="538bf31471b3763a65f2a6b0fb61df29" > name="locale/nb/help.xml" role="horde"/> > ..the ones with 'role="horde"' are ignored by the pear make-rpm-spec command > whereas the ones marked role=script are listed properly. I edited the code > with the attached patch and it lists those files one per line like this in > the %files section: > %{pear_hordedir}/nag/config/.htaccess > > We're getting closer... They are not ignored, they are skipped with an error message IIRC. The error message states what is wrong perfectly: for some packages a requirement is that Horde_Role is installed. The simple solution is to first create php-pear-Horde_Role and install it. After that you should be able to create all other packages, at least that is how I solved it.
(In reply to Greg Swallow from comment #21) > (In reply to Jonathan from comment #20) > > As far as I have tested most RPMS Greg has provided build in the mock > > environment that is matching the build system. > > Some at least will require php-pear >= 1.7.0, ie php-horde-content, both to > build and run. That is available either from rpms.famillecollet.com (which > is what I am testing with now) or maybe we can build and use this one: > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHWAS/SRPMS/php- > pear-1.8.1-2.el5s2.src.rpm php-pear 1.8.9 is in smeupdates-testing IIRC
Created attachment 3360 [details] patch for file in php-pear-PEAR-Command-Packaging (In reply to Jonathan from comment #20) > IMHO the channel name should be added, this can be done by modifying the xml > template in the RPM for which the link was supplied in comment #2. Yes. I figured out how that works. You can copy the template.spec to say template-horde.spec and make changes. Doing that it's pretty simple to make the changes per the packaging guidelines and then run from your /SPECS/ directory pear make-rpm-spec --spec-template=/path/to/template-horde.spec ../SOURCES/Horde_xxx.tgz The one part that was still not working for me is that the horde packages xml files that list files like: <file baseinstalldir="/" md5sum="538bf31471b3763a65f2a6b0fb61df29" name="locale/nb/help.xml" role="horde"/> ..the ones with 'role="horde"' are ignored by the pear make-rpm-spec command whereas the ones marked role=script are listed properly. I edited the code with the attached patch and it lists those files one per line like this in the %files section: %{pear_hordedir}/nag/config/.htaccess We're getting closer...
(In reply to Jonathan from comment #20) > As far as I have tested most RPMS Greg has provided build in the mock > environment that is matching the build system. Some at least will require php-pear >= 1.7.0, ie php-horde-content, both to build and run. That is available either from rpms.famillecollet.com (which is what I am testing with now) or maybe we can build and use this one: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/RHWAS/SRPMS/php-pear-1.8.1-2.el5s2.src.rpm
(In reply to comment #2) > For the rest, I don't have the provides/requires quite right though - they > need a little tweaking like described here - > http://fedoraproject.org/wiki/Packaging:PHP Apart from that you also need to supply a different naming scheme parameter as the default generated php-Horde-Package where it should read php-pear-Horde-Package. AFAICT a parameter of "-p php-pear-%c-%S" should do that trick. The Provides sections at least need a different format as this: Provides: php-pear(%{pear_name}) = %{version} is not according to the documentation of Fedora and does not match the generated Requires: Requires: php-pear(pear.horde.org/Horde_Date) <= 2.0.0, php-pear(pear.horde.org/Horde_Exception) IMHO the channel name should be added, this can be done by modifying the xml template in the RPM for which the link was supplied in comment #2. As far as I have tested most RPMS Greg has provided build in the mock environment that is matching the build system.
(In reply to comment #16) > I would be interested to package the entire Groupware package. I don't > think it would be much more work. I don't think that would be to hard as it is provided as a special package just as the separate components, see near the bottom of http://pear.horde.org.
(In reply to comment #16) > I would be interested to package the entire Groupware package. I don't > think it would be much more work. And if the Horde pear modules are all > separately packaged then it would be fairly simple to separate what we > package now in SME Server from what is not and we could include just what > upgrades what is there now on the CD or official updates, and the rest could > be contribs, or if we include it all on the CD, it would be easy for you to > use just what you need for your own purposes I think Sounds good. I think we all agree taht this won't go into SME8, so there is no urgency. I'm sure you'll keep us informed of progress, and ask for help when necessary.
(In reply to comment #16) > Combining the individual php-pear-Horde-xxx rpms into one would be more work > than packaging them separately. OK, it doesn't make sense to do it combined then.
(In reply to comment #13) > Is there any real > reason that we cannot package all the horde components together? We do it > now. Combining the individual php-pear-Horde-xxx rpms into one would be more work than packaging them separately. Creating the spec file with the tool in the PEAR-Command-Packaging rpm works by reading the xml file and figuring out the dependancies for each one. That part works automatically, it's just the file list part does not work automatically. (In reply to comment #15) > I'm not advocating bundling any or all optional modules, just the essential > core. I would be interested to package the entire Groupware package. I don't think it would be much more work. And if the Horde pear modules are all separately packaged then it would be fairly simple to separate what we package now in SME Server from what is not and we could include just what upgrades what is there now on the CD or official updates, and the rest could be contribs, or if we include it all on the CD, it would be easy for you to use just what you need for your own purposes I think
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > We have specific reasons for packaging those separately. Is there any real > > reason that we cannot package all the horde components together? We do it > > now. > > No we don't. We package horde, imp, turba, etc all separately. All of horde is packaged in one RPM. All of imp in one RPM. All of turba in one RPM. > Also all > their dependencies are packaged separately. There are also many optional > modules that are in smecontribs that are separate. I'm not advocating bundling any or all optional modules, just the essential core. Our perl RPM includes many CPAN modules. I think this is a good thing.
(In reply to comment #13) > (In reply to comment #12) > We have specific reasons for packaging those separately. Is there any real > reason that we cannot package all the horde components together? We do it > now. No we don't. We package horde, imp, turba, etc all separately. Also all their dependencies are packaged separately. There are also many optional modules that are in smecontribs that are separate.
(In reply to comment #12) > I would compare it more to packaging all the e-smith and smeserver packages > into one. We have specific reasons for packaging those separately. Is there any real reason that we cannot package all the horde components together? We do it now.
I would compare it more to packaging all the e-smith and smeserver packages into one.
(In reply to comment #10) > After thinking on this I don't think this is preferable. I think the > separate packages is the better approach as the packages are released with > separate versions. And why is that preferable? > IMHO the one spec file approach will force a rebuild off all packages and > this means a user needs to update all packages, when only one package has > changed. The user only needs to upgrade one rpm whichever way we proceed (if only one package has changed). > When we build the packages in a RPM each it is still possible to update one > package and the user only sees the updated package, instead of all updates > for perhaps a minor fix. Yes, but then we need to deal with all the interdependencies within the packages, and probably deal with breakage when an upgrade is incomplete, with incompatible component packages installed. By combining in one 'horde' rpm, we simplify for the end-user, and are sure that we only have a set of mutually compatible horde components installed. Think about it in terms of, say, e-smith-openssh - would we be better if each file was packaged in a separate rpm? I'm sure you'll agree that we would not.
(In reply to comment #7) > If you did want to build one horde-4 rpm from the 83 or so tarballs then > that's not especially difficult in the spec file. You just need 83 or so > SourceX: specifications and 83 or so %setup calls in the %build section. Ask > if you want help to try that. I expect doing that would be preferable to > building 83 or so separate rpms. After thinking on this I don't think this is preferable. I think the separate packages is the better approach as the packages are released with separate versions. IMHO the one spec file approach will force a rebuild off all packages and this means a user needs to update all packages, when only one package has changed. When we build the packages in a RPM each it is still possible to update one package and the user only sees the updated package, instead of all updates for perhaps a minor fix.
(In reply to comment #8) > At the time of the first release when I started it was round 30 packages, > did they add so many extra in the mean time? Yup, they are all listed (and downloadable) here: http://pear.horde.org/ I posted a link in Comment 3 to the separate srpms I made. I wonder if it might be easier to make them separately at first and then try to combine them. The php-pear-PEAR-Command-Packaging rpm in Comment 2 was very easy to use and generates a spec that is pretty much complete except for the %files section. If the filelist generator macro works you could modify the template spec in that rpm and it might spew out an rpm that actually worked. (In reply to comment #7) > If you did want to build one horde-4 rpm from the 83 or so tarballs then > that's not especially difficult in the spec file. You just need 83 or so > SourceX: specifications and 83 or so %setup calls in the %build section. Ask > if you want help to try that. I expect doing that would be preferable to > building 83 or so separate rpms. I thought so too. Thanks for the offer. I think I'll try to help what I can with getting 8.0 ready without this first and then take you up on that unless Jonathan figures it out first or asks you first ;-)
(In reply to comment #7) > (In reply to comment #6) > > > ... some info on their opinion of how to package it: > > https://bugzilla.redhat.com/show_bug.cgi?id=726011#c1 > > If you did want to build one horde-4 rpm from the 83 or so tarballs At the time of the first release when I started it was round 30 packages, did they add so many extra in the mean time? > then > that's not especially difficult in the spec file. You just need 83 or so > SourceX: specifications and 83 or so %setup calls in the %build section. Ask > if you want help to try that. I expect doing that would be preferable to > building 83 or so separate rpms. Unfortunately it is not as simple as that as every source contains a package.xml in the root. If you just %setup them they are overwritten by the next archive to be extracted. I have been toying around with a solution like that today, using: %setup -a 1 -D -T %setup -a 2 -D -T
(In reply to comment #6) > ... some info on their opinion of how to package it: > https://bugzilla.redhat.com/show_bug.cgi?id=726011#c1 If you did want to build one horde-4 rpm from the 83 or so tarballs then that's not especially difficult in the spec file. You just need 83 or so SourceX: specifications and 83 or so %setup calls in the %build section. Ask if you want help to try that. I expect doing that would be preferable to building 83 or so separate rpms.
Created attachment 3352 [details] php_pear_gen_filelist (In reply to comment #5) > Perhaps this might help: > > http://www.ralf-lang.de/2011/05/21/howto-packaging-3rd-party-pear-channel- > software-with-php_pear_gen_filelist-macro/ I think so. The macro is not in Redhat or Fedora's php-devel rpm. It is in Opensuse in their php-devel rpm. All there is to it to test it out though is to append the attached text to /etc/rpm/macros.php. Also, I never got a response back by email from the two guys maintaining horde for Fedora, but I did get a response back on a bugzilla report here - some info on their opinion of how to package it: https://bugzilla.redhat.com/show_bug.cgi?id=726011#c1
(In reply to comment #4) > Good luck with this. I'm pretty down that the horde devs decided that pear > is the way to go for installs/updates of horde. There are many > inconsistencies with installing/updating via pear. The horde devs are > pretty adamant about not producing any complete tarballs, and as you've > found out making these into rpms is pretty tedious. Perhaps this might help: http://www.ralf-lang.de/2011/05/21/howto-packaging-3rd-party-pear-channel-software-with-php_pear_gen_filelist-macro/
(In reply to comment #3) > This is what I have done so far: > http://bit.ly/m9jWEz (84 srpms, ~24MB zip file) > There are 83 srpms for horde, plus one for php-pear-Net-DNS2, which isn't in > Remi's repository. They are at the point where 'yum localinstall *.rpm' is > satisfied with all the provides/requires and will install them. > ...but don't expect much more than that. I didn't deal with any unpackaged > files other than listing them in the %files section so the rpm would build. > Most don't have any unpackaged files though, it is the ones like > php-horde-horde/imp/turba that need some fixing. > I can keep working on it, but just wanted to share what I have so far, in case > someone else wants to work on it too. Good luck with this. I'm pretty down that the horde devs decided that pear is the way to go for installs/updates of horde. There are many inconsistencies with installing/updating via pear. The horde devs are pretty adamant about not producing any complete tarballs, and as you've found out making these into rpms is pretty tedious. IMHO, horde 4 is really not ready for primetime yet. For what SME Server currently includes, there have been 6 updates to horde, 7 to imp, 3 to turba, 2 to ingo, and 1 or 2 other updates to some of the various other individual packages since the April 5, 2011 initial release. The horde team is now running under the release early, release often mode. If we choose to go this route, I will help where I can, but my time has become limited.
This is what I have done so far: http://bit.ly/m9jWEz (84 srpms, ~24MB zip file) There are 83 srpms for horde, plus one for php-pear-Net-DNS2, which isn't in Remi's repository. They are at the point where 'yum localinstall *.rpm' is satisfied with all the provides/requires and will install them. ...but don't expect much more than that. I didn't deal with any unpackaged files other than listing them in the %files section so the rpm would build. Most don't have any unpackaged files though, it is the ones like php-horde-horde/imp/turba that need some fixing. I can keep working on it, but just wanted to share what I have so far, in case someone else wants to work on it too.
I built them separately, with 'pear make-rpm-spec xxxx.tgz' to make the spec files. That command is included in this rpm: http://rpms.famillecollet.com/enterprise/5/remi/i386/php-pear-PEAR-Command-Packaging-0.2.0-6.el5.remi.noarch.rpm And I made a "php-channel-horde" rpm that installs the pear.horde.org channel, similar to aonther php-channel-xxxx rpm in the famillecollet repository. It is pretty simple. For the rest, I don't have the provides/requires quite right though - they need a little tweaking like described here - http://fedoraproject.org/wiki/Packaging:PHP I am very out of practice with packaging rpms, and was never that expert at it years ago ;-)...and don't have an account on the build server, but I'll work on it a bit more and then upload what I have for you or someone else to fine-tune... Eg: (the channel rpm) php-channel-horde-1.3-1.el5.greg.src.rpm (everything else) php-horde-Horde-ActiveSync-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Alarm-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Argv-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Auth-1.0.4-1.el5.greg.src.rpm php-horde-Horde-Autoloader-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Browser-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Cache-1.0.4-1.el5.greg.src.rpm php-horde-Horde-Cli-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Compress-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Constraint-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Controller-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Core-1.2.1-1.el5.greg.src.rpm php-horde-Horde-Crypt-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Data-1.0.1-1.el5.greg.src.rpm php-horde-Horde-DataTree-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Date-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Date-Parser-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Db-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Editor-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Exception-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Feed-1.1.0-1.el5.greg.src.rpm php-horde-Horde-Form-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Group-1.0.0-1.el5.greg.src.rpm php-horde-Horde-History-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Http-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Icalendar-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Image-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Imap-Client-1.0.8-1.el5.greg.src.rpm php-horde-Horde-Imsp-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Injector-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Itip-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Ldap-1.1.1-1.el5.greg.src.rpm php-horde-Horde-Lock-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Log-1.0.0-1.el5.greg.src.rpm php-horde-Horde-LoginTasks-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Mail-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Mime-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Mime-Viewer-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Nls-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Notification-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Oauth-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Pdf-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Perms-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Prefs-1.1.1-1.el5.greg.src.rpm php-horde-Horde-Rdo-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Role-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Rpc-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Secret-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Serialize-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Service-Facebook-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Service-Twitter-1.1.0-1.el5.greg.src.rpm php-horde-Horde-SessionHandler-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Share-1.1.0-1.el5.greg.src.rpm php-horde-Horde-SpellChecker-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Stream-Filter-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Stream-Wrapper-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Support-1.0.0-1.el5.greg.src.rpm php-horde-Horde-SyncMl-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Template-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Text-Diff-1.0.1-1.el5.greg.src.rpm php-horde-Horde-Text-Filter-1.0.3-1.el5.greg.src.rpm php-horde-Horde-Text-Filter-Csstidy-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Text-Flowed-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Token-1.0.2-1.el5.greg.src.rpm php-horde-Horde-Translation-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Tree-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Url-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Util-1.0.4-1.el5.greg.src.rpm php-horde-Horde-Vfs-1.0.3-1.el5.greg.src.rpm php-horde-Horde-View-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Xml-Element-1.0.0-1.el5.greg.src.rpm php-horde-Horde-Xml-Wbxml-1.0.1-1.el5.greg.src.rpm (this is how the ones below are automatically named) php-horde-content-1.0.0-1.el5.greg.src.rpm php-horde-horde-4.0.6-1.el5.greg.src.rpm php-horde-imp-5.0.7-1.el5.greg.src.rpm php-horde-ingo-2.0.2-1.el5.greg.src.rpm php-horde-kronolith-3.0.4-1.el5.greg.src.rpm php-horde-mnemo-3.0.1-1.el5.greg.src.rpm php-horde-nag-3.0.1-1.el5.greg.src.rpm php-horde-timeobjects-1.0.1-1.el5.greg.src.rpm php-horde-turba-3.0.3-1.el5.greg.src.rpm php-horde-webmail-4.0.0-1.el5.greg.src.rpm (a requirement, I couldn't find packaged elsewhere) php-pear-Net-DNS2-1.1.2-1.el5.greg.src.rpm I did find the 5 other pear module rpms that are requirements of horde 4: php-pear-Console-Color noarch 1.0.3-3.el5.remi remi 9.4 k php-pear-Console-Table noarch 1.1.4-1.el5.remi remi 15 k php-pear-Crypt-Blowfish noarch 1.1.0-0.3.rc2.el5.remi remi 22 k php-pear-File-Find noarch 1.3.1-1.el5.remi remi 14 k php-pear-Net-Sieve noarch 1.3.0-1.el5.remi remi 20 k
Created attachment 3319 [details] Minimal draft of horde spec, no suitable build yet I have been playing with it as well a while back, but due too lack of time I have not progressed far. But too save you some typing here is my spec file with all the package definitions, I have only minimally tried building yet and one of the main problems I hit is that the packages.xml file of each package is extracted in the root and not in the source folder of the package, thus overwriting package.xml for every additional source that is extracted.