Re: gitweb: (potential) problems with new installation

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 2 Mar 2012, Ramsay Jones wrote:
> Jakub Narebski wrote:

> > > First, I should say that I had to modify the script, and move the static
> > > directory out of cgi-bin, in order to get it to work.
> > 
> > You should never have to modify generated gitweb.cgi script; that is what
> > configuration file, gitweb_config.perl by default, is for.  It is well
> > documented in gitweb.conf(5) manpage, which in turn is referenced in
> > gitweb(1) manpage... at least with modern git.
> 
> Indeed, but I find "sudo bash; cd /var/www/cgi-bin; vim gitweb.cgi; etc..."
> just as easy! :-D
> 
> However, ... point taken.

Note that position of static files, and where they are installed, can
be set at build time.
 
> > >                                                       However, this is 
> > > not something new; I had to do the same with the previous version. The
> > > problem is obviously an apache configuration problem, which I tried to
> > > fix last time and (having spent *lots* of effort) gave up on; the main
> > > symptom of the problem is that apache attempts to *exec* any file in
> > > cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which
> > > fills up the apache error logs with "permission denied" errors while
> > > trying to exec.
> > 
> > Strange.  Which version of Apache are you using, and how do relevant
> > parts of Apache configuration (httpd.conf etc.) look like?
> 
> Heh, I only described the above apache config problems (in the spirit of
> full disclosure) so that you would not be surprised by certain files not
> being in their usual location ... It wasn't a sneeky attempt to get some
> apache support! Having said that, my apache version is:
> 
>     Apache/2.2.3 (Ubuntu) mod_perl/2.0.2 Perl/v5.8.8 configured

Do you use CGI (mod_cgi or mod_cgid), or mod_perl?
 
> > If you use ScriptAlias directive, or ExecCGI option, then the problem
> > might be executable permissions -- Apache shouldn't execute scripts
> > without execute permission set as CGI scripts... errr... are you running
> > httpd as root?
> 
> No, it's running as www-data (well, the initial apache is run as root, but
> all worker processes are run as www-data - only the worker processes actually
> handle requests, I think).

Strange.  WORKSFORME anyway...
 
> > You can move to using "AddHandler cgi-script .cgi" instead.
> 
> I remember having tried that as well - without success.

This must be done _instead_ of ScriptAlias directive and/or ExecCGI option.

> > >     1. The new date timezone pop-up; The pop-up window comes up directly
> > >        over the date, so you can no longer read it, and once you have set
> > >        the desired timezone, it can not be dismissed. (including the x
> > >        button on the window). The only way to remove it is to refresh the
> > >        page, which makes it a little less that useful ... :-D
> > 
> > Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time
> > of writing Firefox, Chrome, IE, and ancient Konqueror without encountering
> > any problems.
> > 
> > Could you at minimum check for JavaScript errors using JavaScript Console
> > (clearing it and reloading gitweb page if needed)?  Please provide line
> > where error is with a bit of context (around 3 lines).
> 
> I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't
> have internet access from Linux... ).

JavaScript Console is built in, though there are plugins like Console^2
that extend it.

In Mozilla 1.7.12 it is "Tools > Web Development > JavaScript Console"
It is "Tools > Errors Console" or "Tools > Web Console" in modern Firefox.
 
> > Note also that as workaround you can simply turn off this feature: put
> > the following line in gitweb configuration file:
> > 
> >   $feature{'javascript-timezone'}{'default'} = [];
> 
> Thanks. [BTW, if it wasn't clear before, you cannot grab the pop-up and move
> it out of the way...]

Well, of course.  Currently JavaScript is hand-written, and does not use
any of JavaScript toolkits / UI frameworks.  There are some plans to move
gitweb to use jQuery or MooTools library (YUI is probably too large).
 
> > >        The apache error log looked correct:
> > >
> > >            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \
> > >            in regex; marked by <-- HERE in m/* <-- HERE git.*\.git/ at \
> > >            /var/www/cgi-bin/gitweb.cgi line 3084.
> > 
> > Hmmm... if we don't use regexp search, then all metacharacters should be
> > quoted, including leading '*'.  Strange.
> 
> Yes, this happens whether the re checkbox is set or *not*.

As I wrote in a separate thread, there were two separate errors, and both
need to be fixed.
 
> > If you did use regexp search, then it is a real issue, and it is not
> > something I have thought about.  Your search term
> > 
> >   *git.*\.git
> > 
> > is invalid regexp, because '*' quantifier which means zero or more 
> > occurrences does not follow any term.  Valid regexp is
> > 
> >   .*git.*\.git
> 
> Indeed, this is the regexp I had intended. (I started with a glob pattern,
> noticed the re checkbox, checked it, then went back to edit the search
> text, but forgot the initial '*' quantifier)

Fixed-string search should have worked even if this string contains
regexp metacharacters like '*'.  '*foo' searches for literal '*foo'
(using /\*foo/ search regexp)... or at least it should (send a patch
fixing this).

-- 
Jakub Narebski
Poland