Upload project web pages
See Homepage for general info on the per-project web pages.
To import an initial setup web pages for your project, use the
repository (this is completely separate from any source trees). The web
tree always uses CVS. For basic CVS usage, see CvsGettingStarted.
First, you need to configure your SshAccess.
You should have read instructions in your CVS project page on savannah (e.g., the emacs CVS page is http://savannah.gnu.org/cvs/?group=emacs).
Go to the local directory where you want to put your local copy the CVS HTML tree. For example:
mkdir ~/project/www cd ~/project/www
Download the CVS HTML tree structure (substitute developername with your login and projectname with your project system name):
cvs -z3 -d:ext:email@example.com:/web/projectname co projectname
Then, in the directory \~/project/www/projectname, copy all the files you want to insert in the CVS HTML tree. For example:
cp ~/tmp/index.html ~/project/www/projectname
Once you have locally set your HTML tree, you can import it. To import a file and a directory:
cd ~/project/www/projectname cvs add index.html cvs add mydir # (or: cvs add index.html mydir) cvs commit
Done! The webpages will be updated within an hour. The location of your homepage is the default URL in your project's Select[ed] Features.
Similarly, updating your web pages after the initial import is a matter of updating and committing in your CVS tree.
Exception: large updates, involving either many updates or many megabytes, may not be fully completed. Unfortunately, there is no warning when this happens (Savannah does not receive any information from the backend FSF machines), it's just that some files may not be present. If you notice this, the thing to do is submit a new ticket at https://savannah.gnu.org/support/?group=administration.
For Savannah administrators
When a project's web pages, we can retrigger the update at the FSF side with the same command that is run by the CVS loginfo hook (SavannahInternals). Do this on the vcs machine (though probably it does not technically matter).
# T=gnu or T=non-gnu # PROJ=project identifier vcs$ curl http://www.gnu.org/new-savannah-project/new.py \ -s -F type=$T -F project=$PROJ
A successful call should result in an empty HTTP-200, e.g.:
# curl -D /dev/stderr http://www.gnu.org/new-savannah-project/new.py -s -F type=non-gnu -F project=pretest 2>&1 HTTP/1.1 100 Continue HTTP/1.1 200 OK Date: Thu, 01 Dec 2016 04:29:15 GMT Server: Apache/2.4.7 Access-Control-Allow-Origin: (null) Cache-Control: max-age=0 Expires: Thu, 01 Dec 2016 04:29:15 GMT Content-Length: 0 Content-Type: text/html Content-Language: en
It may take more than one call, a few minutes apart.
1. The script
new.py will return HTTP-404 (page not found) on
any errors! That's not only confusing, but also hard to troubleshoot.
The 404 errors are sent back to apache, which in turns renders
an entire www.gnu.org "page not found" template.
2. The script
new.py will return HTTP-404 (page not found)
if the project name is invalid, or if the type is invalid
(e.g. not "gnu" or "non-gnu").
3. A copy of the script can be found in
4. A copy of the relevant apache configuration can be found in
(search for "new.py").