Requesting an ebuild for Savane, the layer under savannah.gnu.org. Description from the project page: Savane is a Web-based Free Software hosting system. It currently includes issue tracking (bugs, task, support), project and member management, mailing lists, and individual account maintenance. Savane is the continuation of the Savannah project by its main authors. Backward compatibility with Savannah will be insured. Savannah itself was a fork of SourceForge 2.0. Over SourceForge.net, there is also Arch (tla) support, which is an interesting feature. Savane is released under the GPLv2. Reproducible: Always Steps to Reproduce:
Hi, I'm sorry, but we're not able to accept requests for new ebuilds at this time. All of our volunteer effort is taken up with maintaining existing packages, and with accepting new ebuilds that have been written by Gentoo users. We recommend that you try writing an ebuild of your own. Our ebuild scripts are written in bash. You can find some useful documentation on the gentoo.org web site; 'man 5 ebuild' also has a lot of useful reference information. If you're writing an ebuild for a web-based application, you also need to 'emerge webapp-config', and look at the man pages that it installs. Best regards, Stu
Created attachment 36569 [details] savane-1.0.2.ebuild This ebuild is currently pretty broken. Savane's configure/install procedure is rather interesting. Right now, I can create users, but for some reason cannot login. You will need to chown apache:apache /etc/savannah/* , which is not good. According to their INSTALL.verbose, that location is currently hardcoded in the backend, so there. You _need_ to read and follow INSTALL.verbose to make this work. Also, if you can't send email, you can still register by placing something like echo $GLOBALS['sys_https_url']."/account/verify.php?confirm_hash=$confirm_hash\n\n"; in account/register.ph around line 294. If someone else has time to fix this ebuild, by all means please do.
Now I started working with the Savane guys (in fact, I'm in the developer list), and I can help more with Savane-Gentoo integration. What we need is a default configure.guess. I'll attach mine when I'll come back (I'll be on holiday until August 14th). Then, we shall create an apache configuration file like the other modules (in /etc/apache2/conf/modules/) and install it like bugzilla does. The only problem, I haven't used webapp-config before, but it sounds like problems with Savane installation. Could anyone explain me better what's webapp-config for (in a couple of lines)? If you wait a little, I'll help you next week. Thank you :)
1. A sane configure.guess is a good start. What we need ideally---and correct me if I say something blatantly untrue---is a way to let the user configure the installation _after_, and not _before_, everything is copied over. Right now we either make the user answer a lot (40+) of questions before the ebuild can take over, which is poor form, or have the user or the ebuild look in undocumented and non-obvious places to change the default values. So yes, Savane's current installation procedure doesn't work well with webapp-config because the ebuild does not know where the files will end up. Installation is done (rougly) in 3 stages: - sandbox - webapp staging ground - htdocs (/var/www or /srv) Re: Apache configs. Firstly, Bugzilla uses an .htaccess file and doesn't install into /etc/apache. Secondly, does Savane work with non-Apache servers? If so, I'd much rather the ebuild be httpd-agnostic and not assume the user is running a particular server.
>A sane configure.guess is a good start. What we need ideally---and correct me if I say something blatantly untrue---is a way to let the user configure the installation _after_, and not _before_, everything is copied over. You're obviously right. The point is that the user should update his configuration through "make update-conf" after having modified /etc/savannah/savannah.conf.pl (or where we store our configuration). Further configurations are made (usually) in /etc/savannah/site-specific-contents. We can put a small shell script in /etc/savannah that calls "make update-conf" in the right dir, if you like (it can extract dinamically the topdir from savannah.conf.pl). I also find that all this savane/savannah naming policy stuff is rather confusing, so we should configure everything to go on */savane dirs rather than */savannah ones. Just my though, anyway. > Right now we either make the user answer a lot (40+) of questions before the ebuild can take over, which is poor form, or have the user or the ebuild look in undocumented and non-obvious places to change the default values. 40+? Weeell, they didn't seem so many. Anyway, we can easily do a fully automated install by providing a configure.guess: savane will watch for it and enter in non-interactive mode. We just have to tune the ebuild well to produce a good configure.guess, imho, which is all but easy. But doable. > So yes, Savane's current installation procedure doesn't work well with webapp-config because the ebuild does not know where the files will end up. Installation is done (rougly) in 3 stages: - sandbox - webapp staging ground - htdocs (/var/www or /srv) This is a little bigger problem, but not impossible to overcome. An idea (maybe a silly one): could we patch savane to produce a slightly different /etc/savannah/savannah.conf.php when running "make update-conf"? Maybe setting $sys_topdir and other values we need in a dinamic way (using php functions). The point, anyway, is that the user will always need to modify savannah.conf.pl by hand (which is normal). > Re: Apache configs. Firstly, Bugzilla uses an .htaccess file and doesn't install into /etc/apache. Right, I wasn't referring to that. > Secondly, does Savane work with non-Apache servers? If so, I'd much rather the ebuild be httpd-agnostic and not assume the user is running a particular server. It is possible (although not documented) that it runs on other servers. On the other hand, it will be no harm to automatize the integration of Savane with Apache1/2 by putting a 99_savane.conf in /etc/apache2/conf/modules.d/. I'll attach _an example_ of mine (not one for inclusion) to show what I mean.
Created attachment 37611 [details] An example of a configuration file for /etc/apache2/conf/modules.d/ This assume that DocumentRoot points to a Savane installation (as happens on my machine). If not, you've to uncomment the alias, and change the paths accordingly.
Savane 1.0.3 is out. Stuart, I added you on CC since I'm not sure you saw I posted some more comments on this bug... We can discuss a little the better way to do the ebuild and then prepare it for portage inclusion.
IMO, the ebuild is nowhere near commit-quality (at the very least, I'm not maintaining it if it's committed in its current state). > You're obviously right. The point is that the user should update his configuration through "make update-conf" after having modified /etc/savannah/savannah.conf.pl (or where we store our configuration). Further configurations are made (usually) in /etc/savannah/site-specific-contents. We can put a small shell script in /etc/savannah that calls "make update-conf" in the right dir, if you like (it can extract dinamically the topdir from savannah.conf.pl). That sounds a little crazy. So in order to make a configuration change, we need to keep the entire src tree around? I hope I am misunderstanding what you mean by calling make update-conf > 40+? Weeell, they didn't seem so many Yes, that was my count.
>IMO, the ebuild is nowhere near commit-quality (at the very least, I'm not maintaining it if it's committed in its current state). That's pretty obvious. It needs a lot of work. > That sounds a little crazy. So in order to make a configuration change, we need to keep the entire src tree around? I hope I am misunderstanding what you mean by calling make update-conf we can call "sv_update_conf" with the right parameters, it's the same. don't lose your patience for such a thing... :) Anyway, how we can conciliate the fact that webapp-config can do a lot of installations and the configuration file for the backend has to be always in /etc/savannah (and thus we can define only one mysql database)? >> 40+? Weeell, they didn't seem so many > Yes, that was my count. Twelve, reading the configure file with vim. Anyway, it doesn't matter as far as we use it in non-interactive mode.
> we can call "sv_update_conf" with the right parameters, it's the same. don't lose your patience for such a thing... :) what happened to just editing a text file? > Anyway, how we can conciliate the fact that webapp-config can do a lot of installations and the configuration file for the backend has to be always in /etc/savannah (and thus we can define only one mysql database)? That's the big one. Until we can have vhost-specific config files, webapp-config isn't going to like Savane.
> what happened to just editing a text file? savannah.conf.php has to be always regenerated after editing savannah.conf.pl, thus calling "sv_update_conf".
I'm starting to think about Savane-webappconf integration. I'm trying to come up with a fast solution on the Savane side that should make possible to have more than a configuration on a single host.
Matteo, that would be great. I'll be more than happy to look at ebuilds/discuss things if you can get something to work, I'm swamped with other webapp stuff atm. Thanks for all your work on this.
I'll start on working with multiple host support next week. If I manage it, it'll be out for 1.0.5. I'll reopen the bug when we'll have it. Due to Savane nature, using webapp-config would probably be limited to the "site-specific-content" dir, while both frontend and backend need just one installation on the whole machine. Achieving this means some reorganization of Savane design itself, that wasn't planned for this in the first place (and thus some non-trivial effort). A good occasion to improve it, then. :) Let's see if we can have Savane on Gentoo, at last...
