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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html