Jakub Narebski[Cc-ed to git mailing list, again this time without HTML]
On Mon, 27 Feb 2012, Ramsay Jones wrote:
Show 10 quoted lines
> I recently decided to update the gitweb installation on my laptop, since > it was still running version 1.5.5! (also, the cgit I have installed is > about the same vintage ...) > > The version of gitweb I installed was, simply because I had just built > and tested it, the version included in the pu branch as of a couple of > days ago (commit 8544a26). > > 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.
Note also that you can specify where to put static files (page prerequisites) during "make install"... though that it would not obviate need to create and edit gitweb configuration file.
Show 8 quoted lines
> 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?
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?
You can move to using "AddHandler cgi-script .cgi" instead.
Show 12 quoted lines
> > Anyway, I moved the static directory into a gitweb directory (as a sibling > to cgi-bin) and changed the paths in gitweb.cgi by prefixing "../gitweb/". > > Now that I had working gitweb, I played with some of the new features and > noticed a few problems ... I suspect that most of the problems are caused > by my *old* version of firefox, which is: > > firefox version 2.0.0.3 > > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) \ > Gecko/20061201 Firefox/2.0.0.3
I have even older web browser:
Mozilla 1.7.12
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) \
Gecko/20050923 MultiZilla/1.7.9.0aShow 8 quoted lines
> However, I hope the following may be of use; even if only to document a > version of firefox that is not supported by gitweb. ;-) > > 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).
Note also that as workaround you can simply turn off this feature: put the following line in gitweb configuration file:
$feature{'javascript-timezone'}{'default'} = [];
Show 15 quoted lines
> 2. The error console shows a repeated warning about the css file, like
> so:
>
> Warning: Error in parsing value for property 'display'. \
> Declaration dropped.
> Source File: http://localhost/gitweb/static/gitweb.css
> Line: 621
>
> which corresponds to the following in gitweb.css:
>
> div.remote {
> margin: .5em;
> border: 1px solid #d9d8d1;
> display: inline-block; <-- line 621
> }This is probably caused by the fact that your web browser doesn't understand this value of 'display' property because it is too old, and does not implement CSS2.1 fully.
9.2.4 The 'display' property
inline-block
This value causes an element to generate an inline-level block
container. The inside of an inline-block is formatted as a block
box, and the element itself is formatted as an atomic inline-level
box.Nb. this is probably not necessary, gitweb looks just fine without it.
Show 10 quoted lines
> 3. I mis-typed an search term into the project search box and didn't > see the error message displayed by firefox as I expected (maybe > incorrectly?). Firefox displayed: > > XML Parsing Error: xml declaration not at start of external entity > Location: http://localhost/cgi-bin/gitweb.cgi?a=project_list&\ > s=*git.*%5C.git&btnS=Search > Line Number 30, Column 1: > <?xml version="1.0" encoding="utf-8"?> > ^
It is the problem with older Firefoxes, namely that with XHTML DTD and with application/xhtml+xml mimetype it enters strict XML compliance mode. If webpage is not well-formed XML it would display XML error page instead. It is enough that there is some whitespace before <?xml ... ?> processing instruction... which might make for intermittent and annoying to squash Heisenbug.
But in some cases it might happen if there are warnings or errors created by Perl itself and converted to web page by CGI::Carp (fatalsToBrowser).
Show 5 quoted lines
> 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.
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
or just
git.*\.git
Gitweb should probably check that regexp is valid before using it. Thanks for reporting this; I'll try to fix it shortly.
> Whereas the page source did look wrong. Just in case it would be of > use, I have included the page source below.
Thanks.
Damn, I thought that I have that issue squashed! The problem is when there is error thrown or warning triggered when gitweb already printed part of page. The error handler then writes error page from beginning inside existing page... not good.
I'll try to look at this.
Show 15 quoted lines
> As I said above, I suspect these problems are caused by my relatively old > Linux installation (I keep meaning to get around to updating, but I must > say that I don't like the new Ubuntu, although Linux Mint 12 looks quite > good ...). > > Having said that, ignoring the new features, gitweb is working fine for > me (I only installed it in the first place to test it out ...). Also, the > above represents (literally) only ten minutes of playing around with the > new features, without having read any documentation or code. So, if I have > mis-understood how something should work, then sorry for the noise! :( > > Hope this helps. > > ATB, > Ramsay Jones
[cut example HTML output]
-- Jakub Narebski Poland
