{"thread":{"id":"29779","subject":"Re: gitweb: (potential) problems with new installation","startedAt":"2012-02-28T17:25:03Z","lastAt":"2012-03-05T19:39:48Z","messageCount":4,"participants":["Jakub Narebski","Ramsay Jones"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"185635","messageId":"201202281825.03904.jnareb@gmail.com","threadId":"29779","inReplyTo":null,"subject":"Re: gitweb: (potential) problems with new installation","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-28T17:25:03Z","receivedAt":"2012-02-28T17:25:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc-ed to git mailing list, again this time without HTML]\n\nOn Mon, 27 Feb 2012, Ramsay Jones wrote:\n \n> I recently decided to update the gitweb installation on my laptop, since\n> it was still running version 1.5.5! (also, the cgit I have installed is\n> about the same vintage ...)\n> \n> The version of gitweb I installed was, simply because I had just built\n> and tested it, the version included in the pu branch as of a couple of\n> days ago (commit 8544a26).\n> \n> First, I should say that I had to modify the script, and move the static\n> directory out of cgi-bin, in order to get it to work.\n\nYou should never have to modify generated gitweb.cgi script; that is what\nconfiguration file, gitweb_config.perl by default, is for.  It is well\ndocumented in gitweb.conf(5) manpage, which in turn is referenced in\ngitweb(1) manpage... at least with modern git.\n\nNote also that you can specify where to put static files (page \nprerequisites) during \"make install\"... though that it would not obviate\nneed to create and edit gitweb configuration file.\n\n>                                                       However, this is \n> not something new; I had to do the same with the previous version. The\n> problem is obviously an apache configuration problem, which I tried to\n> fix last time and (having spent *lots* of effort) gave up on; the main\n> symptom of the problem is that apache attempts to *exec* any file in\n> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which\n> fills up the apache error logs with \"permission denied\" errors while\n> trying to exec.\n\nStrange.  Which version of Apache are you using, and how do relevant\nparts of Apache configuration (httpd.conf etc.) look like?  \n\nIf you use ScriptAlias directive, or ExecCGI option, then the problem\nmight be executable permissions -- Apache shouldn't execute scripts\nwithout execute permission set as CGI scripts... errr... are you running\nhttpd as root?\n\nYou can move to using \"AddHandler cgi-script .cgi\" instead.\n\n> \n> Anyway, I moved the static directory into a gitweb directory (as a sibling\n> to cgi-bin) and changed the paths in gitweb.cgi by prefixing \"../gitweb/\".\n> \n> Now that I had working gitweb, I played with some of the new features and\n> noticed a few problems ... I suspect that most of the problems are caused\n> by my *old* version of firefox, which is:\n> \n>     firefox version 2.0.0.3\n> \n>     Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) \\\n>     Gecko/20061201 Firefox/2.0.0.3\n\nI have even older web browser:\n\n      Mozilla 1.7.12\n\n      Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) \\\n      Gecko/20050923 MultiZilla/1.7.9.0a\n\n> However, I hope the following may be of use; even if only to document a\n> version of firefox that is not supported by gitweb. ;-)\n> \n>     1. The new date timezone pop-up; The pop-up window comes up directly\n>        over the date, so you can no longer read it, and once you have set\n>        the desired timezone, it can not be dismissed. (including the x\n>        button on the window). The only way to remove it is to refresh the\n>        page, which makes it a little less that useful ... :-D\n\nHmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time\nof writing Firefox, Chrome, IE, and ancient Konqueror without encountering\nany problems.\n\nCould you at minimum check for JavaScript errors using JavaScript Console\n(clearing it and reloading gitweb page if needed)?  Please provide line\nwhere error is with a bit of context (around 3 lines).\n\n\nNote also that as workaround you can simply turn off this feature: put\nthe following line in gitweb configuration file:\n\n  $feature{'javascript-timezone'}{'default'} = [];\n \n>     2. The error console shows a repeated warning about the css file, like\n>        so:\n> \n>            Warning: Error in parsing value for property 'display'.  \\\n>            Declaration dropped.\n>            Source File: http://localhost/gitweb/static/gitweb.css\n>            Line: 621\n> \n>        which corresponds to the following in gitweb.css:\n> \n>            div.remote {\n> \t       margin: .5em;\n> \t       border: 1px solid #d9d8d1;\n> \t       display: inline-block;       <-- line 621\n>            }\n\nThis is probably caused by the fact that your web browser doesn't\nunderstand this value of 'display' property because it is too old,\nand does not implement CSS2.1 fully.\n\n\n  9.2.4 The 'display' property\n\n  inline-block\n     This value causes an element to generate an inline-level block\n     container. The inside of an inline-block is formatted as a block\n     box, and the element itself is formatted as an atomic inline-level\n     box.\n\n\nNb. this is probably not necessary, gitweb looks just fine without it.\n\n>     3. I mis-typed an search term into the project search box and didn't\n>        see the error message displayed by firefox as I expected (maybe\n>        incorrectly?). Firefox displayed:\n> \n>            XML Parsing Error: xml declaration not at start of external entity\n>            Location: http://localhost/cgi-bin/gitweb.cgi?a=project_list&\\\n>                s=*git.*%5C.git&btnS=Search\n>            Line Number 30, Column 1:\n>            <?xml version=\"1.0\" encoding=\"utf-8\"?>\n>            ^\n\nIt is the problem with older Firefoxes, namely that with XHTML DTD and\nwith application/xhtml+xml mimetype it enters strict XML compliance mode.\nIf webpage is not well-formed XML it would display XML error page instead.\nIt is enough that there is some whitespace before <?xml ... ?> processing\ninstruction... which might make for intermittent and annoying to squash\nHeisenbug.\n\nBut in some cases it might happen if there are warnings or errors created\nby Perl itself and converted to web page by CGI::Carp (fatalsToBrowser).\n \n>        The apache error log looked correct:\n> \n>            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \\\n>            in regex; marked by <-- HERE in m/* <-- HERE git.*\\.git/ at \\\n>            /var/www/cgi-bin/gitweb.cgi line 3084.\n\nHmmm... if we don't use regexp search, then all metacharacters should be\nquoted, including leading '*'.  Strange.\n\nIf you did use regexp search, then it is a real issue, and it is not\nsomething I have thought about.  Your search term\n\n  *git.*\\.git\n\nis invalid regexp, because '*' quantifier which means zero or more \noccurrences does not follow any term.  Valid regexp is\n\n  .*git.*\\.git\n\nor just\n\n  git.*\\.git\n\nGitweb should probably check that regexp is valid before using it.\nThanks for reporting this; I'll try to fix it shortly.\n\n>        Whereas the page source did look wrong. Just in case it would be of\n>        use, I have included the page source below.\n\nThanks.\n\nDamn, I thought that I have that issue squashed!  The problem is when\nthere is error thrown or warning triggered when gitweb already printed\npart of page.  The error handler then writes error page from beginning\ninside existing page... not good.\n\nI'll try to look at this.\n\n> As I said above, I suspect these problems are caused by my relatively old\n> Linux installation (I keep meaning to get around to updating, but I must\n> say that I don't like the new Ubuntu, although Linux Mint 12 looks quite\n> good ...).\n> \n> Having said that, ignoring the new features, gitweb is working fine for\n> me (I only installed it in the first place to test it out ...). Also, the\n> above represents (literally) only ten minutes of playing around with the\n> new features, without having read any documentation or code. So, if I have\n> mis-understood how something should work, then sorry for the noise! :(\n> \n> Hope this helps.\n> \n> ATB,\n> Ramsay Jones\n\n[cut example HTML output]\n\n-- \nJakub Narebski\nPoland\n"},{"id":"185944","messageId":"4F51211C.2090201@ramsay1.demon.co.uk","threadId":"29779","inReplyTo":"201202281825.03904.jnareb@gmail.com","subject":"Re: gitweb: (potential) problems with new installation","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2012-03-02T19:35:56Z","receivedAt":"2012-03-02T19:35:56Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Jakub Narebski wrote:\n>> First, I should say that I had to modify the script, and move the static\n>> directory out of cgi-bin, in order to get it to work.\n> \n> You should never have to modify generated gitweb.cgi script; that is what\n> configuration file, gitweb_config.perl by default, is for.  It is well\n> documented in gitweb.conf(5) manpage, which in turn is referenced in\n> gitweb(1) manpage... at least with modern git.\n\nIndeed, but I find \"sudo bash; cd /var/www/cgi-bin; vim gitweb.cgi; etc...\"\njust as easy! :-D\n\nHowever, ... point taken.\n\n>>                                                       However, this is \n>> not something new; I had to do the same with the previous version. The\n>> problem is obviously an apache configuration problem, which I tried to\n>> fix last time and (having spent *lots* of effort) gave up on; the main\n>> symptom of the problem is that apache attempts to *exec* any file in\n>> cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which\n>> fills up the apache error logs with \"permission denied\" errors while\n>> trying to exec.\n> \n> Strange.  Which version of Apache are you using, and how do relevant\n> parts of Apache configuration (httpd.conf etc.) look like?\n\nHeh, I only described the above apache config problems (in the spirit of\nfull disclosure) so that you would not be surprised by certain files not\nbeing in their usual location ... It wasn't a sneeky attempt to get some\napache support! Having said that, my apache version is:\n\n    Apache/2.2.3 (Ubuntu) mod_perl/2.0.2 Perl/v5.8.8 configured\n\n> If you use ScriptAlias directive, or ExecCGI option, then the problem\n> might be executable permissions -- Apache shouldn't execute scripts\n> without execute permission set as CGI scripts... errr... are you running\n> httpd as root?\n\nNo, it's running as www-data (well, the initial apache is run as root, but\nall worker processes are run as www-data - only the worker processes actually\nhandle requests, I think).\n\n> You can move to using \"AddHandler cgi-script .cgi\" instead.\n\nI remember having tried that as well - without success.\n\n>>     1. The new date timezone pop-up; The pop-up window comes up directly\n>>        over the date, so you can no longer read it, and once you have set\n>>        the desired timezone, it can not be dismissed. (including the x\n>>        button on the window). The only way to remove it is to refresh the\n>>        page, which makes it a little less that useful ... :-D\n> \n> Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time\n> of writing Firefox, Chrome, IE, and ancient Konqueror without encountering\n> any problems.\n> \n> Could you at minimum check for JavaScript errors using JavaScript Console\n> (clearing it and reloading gitweb page if needed)?  Please provide line\n> where error is with a bit of context (around 3 lines).\n\nI don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't\nhave internet access from Linux... ).\n\n> Note also that as workaround you can simply turn off this feature: put\n> the following line in gitweb configuration file:\n> \n>   $feature{'javascript-timezone'}{'default'} = [];\n\nThanks. [BTW, if it wasn't clear before, you cannot grab the pop-up and move\nit out of the way...]\n\n>>     2. The error console shows a repeated warning about the css file, like\n>>        so:\n>>\n>>            Warning: Error in parsing value for property 'display'.  \\\n>>            Declaration dropped.\n>>            Source File: http://localhost/gitweb/static/gitweb.css\n>>            Line: 621\n\n> \n> This is probably caused by the fact that your web browser doesn't\n> understand this value of 'display' property because it is too old,\n> and does not implement CSS2.1 fully.\n\nYep, I suspected as much. Not a Problem.\n\n>>        The apache error log looked correct:\n>>\n>>            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \\\n>>            in regex; marked by <-- HERE in m/* <-- HERE git.*\\.git/ at \\\n>>            /var/www/cgi-bin/gitweb.cgi line 3084.\n> \n> Hmmm... if we don't use regexp search, then all metacharacters should be\n> quoted, including leading '*'.  Strange.\n\nYes, this happens whether the re checkbox is set or *not*.\n\n> If you did use regexp search, then it is a real issue, and it is not\n> something I have thought about.  Your search term\n> \n>   *git.*\\.git\n> \n> is invalid regexp, because '*' quantifier which means zero or more \n> occurrences does not follow any term.  Valid regexp is\n> \n>   .*git.*\\.git\n\nIndeed, this is the regexp I had intended. (I started with a glob pattern,\nnoticed the re checkbox, checked it, then went back to edit the search\ntext, but forgot the initial '*' quantifier)\n\nThanks.\n\nATB,\nRamsay Jones\n"},{"id":"185953","messageId":"201203030055.34912.jnareb@gmail.com","threadId":"29779","inReplyTo":"4F51211C.2090201@ramsay1.demon.co.uk","subject":"Re: gitweb: (potential) problems with new installation","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-02T23:55:34Z","receivedAt":"2012-03-02T23:55:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 2 Mar 2012, Ramsay Jones wrote:\n> Jakub Narebski wrote:\n\n> > > First, I should say that I had to modify the script, and move the static\n> > > directory out of cgi-bin, in order to get it to work.\n> > \n> > You should never have to modify generated gitweb.cgi script; that is what\n> > configuration file, gitweb_config.perl by default, is for.  It is well\n> > documented in gitweb.conf(5) manpage, which in turn is referenced in\n> > gitweb(1) manpage... at least with modern git.\n> \n> Indeed, but I find \"sudo bash; cd /var/www/cgi-bin; vim gitweb.cgi; etc...\"\n> just as easy! :-D\n> \n> However, ... point taken.\n\nNote that position of static files, and where they are installed, can\nbe set at build time.\n \n> > >                                                       However, this is \n> > > not something new; I had to do the same with the previous version. The\n> > > problem is obviously an apache configuration problem, which I tried to\n> > > fix last time and (having spent *lots* of effort) gave up on; the main\n> > > symptom of the problem is that apache attempts to *exec* any file in\n> > > cgi-bin (e.g. gitweb.css, git-logo.png, git-favicon.png, etc.) which\n> > > fills up the apache error logs with \"permission denied\" errors while\n> > > trying to exec.\n> > \n> > Strange.  Which version of Apache are you using, and how do relevant\n> > parts of Apache configuration (httpd.conf etc.) look like?\n> \n> Heh, I only described the above apache config problems (in the spirit of\n> full disclosure) so that you would not be surprised by certain files not\n> being in their usual location ... It wasn't a sneeky attempt to get some\n> apache support! Having said that, my apache version is:\n> \n>     Apache/2.2.3 (Ubuntu) mod_perl/2.0.2 Perl/v5.8.8 configured\n\nDo you use CGI (mod_cgi or mod_cgid), or mod_perl?\n \n> > If you use ScriptAlias directive, or ExecCGI option, then the problem\n> > might be executable permissions -- Apache shouldn't execute scripts\n> > without execute permission set as CGI scripts... errr... are you running\n> > httpd as root?\n> \n> No, it's running as www-data (well, the initial apache is run as root, but\n> all worker processes are run as www-data - only the worker processes actually\n> handle requests, I think).\n\nStrange.  WORKSFORME anyway...\n \n> > You can move to using \"AddHandler cgi-script .cgi\" instead.\n> \n> I remember having tried that as well - without success.\n\nThis must be done _instead_ of ScriptAlias directive and/or ExecCGI option.\n\n> > >     1. The new date timezone pop-up; The pop-up window comes up directly\n> > >        over the date, so you can no longer read it, and once you have set\n> > >        the desired timezone, it can not be dismissed. (including the x\n> > >        button on the window). The only way to remove it is to refresh the\n> > >        page, which makes it a little less that useful ... :-D\n> > \n> > Hmmm... I have tested this code on Mozilla 1.7.12, and on modern at the time\n> > of writing Firefox, Chrome, IE, and ancient Konqueror without encountering\n> > any problems.\n> > \n> > Could you at minimum check for JavaScript errors using JavaScript Console\n> > (clearing it and reloading gitweb page if needed)?  Please provide line\n> > where error is with a bit of context (around 3 lines).\n> \n> I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't\n> have internet access from Linux... ).\n\nJavaScript Console is built in, though there are plugins like Console^2\nthat extend it.\n\nIn Mozilla 1.7.12 it is \"Tools > Web Development > JavaScript Console\"\nIt is \"Tools > Errors Console\" or \"Tools > Web Console\" in modern Firefox.\n \n> > Note also that as workaround you can simply turn off this feature: put\n> > the following line in gitweb configuration file:\n> > \n> >   $feature{'javascript-timezone'}{'default'} = [];\n> \n> Thanks. [BTW, if it wasn't clear before, you cannot grab the pop-up and move\n> it out of the way...]\n\nWell, of course.  Currently JavaScript is hand-written, and does not use\nany of JavaScript toolkits / UI frameworks.  There are some plans to move\ngitweb to use jQuery or MooTools library (YUI is probably too large).\n \n> > >        The apache error log looked correct:\n> > >\n> > >            [Sun Feb 26 16:50:52 2012] gitweb.cgi: Quantifier follows nothing \\\n> > >            in regex; marked by <-- HERE in m/* <-- HERE git.*\\.git/ at \\\n> > >            /var/www/cgi-bin/gitweb.cgi line 3084.\n> > \n> > Hmmm... if we don't use regexp search, then all metacharacters should be\n> > quoted, including leading '*'.  Strange.\n> \n> Yes, this happens whether the re checkbox is set or *not*.\n\nAs I wrote in a separate thread, there were two separate errors, and both\nneed to be fixed.\n \n> > If you did use regexp search, then it is a real issue, and it is not\n> > something I have thought about.  Your search term\n> > \n> >   *git.*\\.git\n> > \n> > is invalid regexp, because '*' quantifier which means zero or more \n> > occurrences does not follow any term.  Valid regexp is\n> > \n> >   .*git.*\\.git\n> \n> Indeed, this is the regexp I had intended. (I started with a glob pattern,\n> noticed the re checkbox, checked it, then went back to edit the search\n> text, but forgot the initial '*' quantifier)\n\nFixed-string search should have worked even if this string contains\nregexp metacharacters like '*'.  '*foo' searches for literal '*foo'\n(using /\\*foo/ search regexp)... or at least it should (send a patch\nfixing this).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"186137","messageId":"4F551684.8020701@ramsay1.demon.co.uk","threadId":"29779","inReplyTo":"201203030055.34912.jnareb@gmail.com","subject":"Re: gitweb: (potential) problems with new installation","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2012-03-05T19:39:48Z","receivedAt":"2012-03-05T19:39:48Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Jakub Narebski wrote:\n> Do you use CGI (mod_cgi or mod_cgid), or mod_perl?\n\nmod_cgid although mod_perl is also available (and *is* used by git-instaweb).\n\n>>> You can move to using \"AddHandler cgi-script .cgi\" instead.\n>> I remember having tried that as well - without success.\n> \n> This must be done _instead_ of ScriptAlias directive and/or ExecCGI option.\n\nIndeed :-D\n\nI had another quick look at this and (I now remember) the AddHandler approach\nactually *did* work. However, I already had some other (perl, shell) scripts\nin cgi-bin and would have had to add file extensions ('.pl' or '.sh') in order\nfor them to keep working.\n\nThe relevant part of httpd.conf looks like this:\n\n<Directory /var/www/>\n        Options Indexes FollowSymLinks MultiViews\n        AllowOverride None\n        Order allow,deny\n        allow from all\n        # This directive allows us to have apache2's default start page\n        # in /apache2-default/, but still have / go to the right place\n        #RedirectMatch ^/$ /apache2-default/\n</Directory>\n\nScriptAlias /cgi-bin/ /var/www/cgi-bin/\n<Directory \"/var/www/cgi-bin\">\n       Options +ExecCGI\n</Directory>\n<Directory \"/var/www/cgi-bin/static\">\n       Options -ExecCGI\n</Directory>\n\n#<Directory \"/var/www/cgi-bin\">\n#        Options +ExecCGI\n#        AddHandler cgi-script .cgi .pl .sh\n#</Directory>\n\nNote that the \"/var/www/cgi-bin/static\" directory entry *should* have solved\nthe problem, but it does not make any difference at all!\n\nBTW, the error.log entries look like:\n\n[Sun Mar 04 15:06:03 2012] [error] (13)Permission denied: exec of '/var/www/cgi-bin/static/gitweb.css' failed\n[Sun Mar 04 15:06:03 2012] [error] [client 127.0.0.1] Premature end of script headers: gitweb.css, referer: http://localhost/cgi-bin/gitweb.cgi\n\nwith similar entries for git-logo.png and gitweb.js. The access log show\n\"500 Internal Server error\" responses for gitweb.css, git-logo.png and gitweb.js.\n\nMaybe I should re-visit the decision and swap over to using the AddHadler\napproach - adding file extensions is not that hard! ;-)\n\nAnyway, the above should work as-is, and I'm somewhat puzzled that it doesn't.\nHowever, as I said before, it's not a gitweb fault.\n\n>>> Could you at minimum check for JavaScript errors using JavaScript Console\n>>> (clearing it and reloading gitweb page if needed)?  Please provide line\n>>> where error is with a bit of context (around 3 lines).\n>> I don't have a JavaScript Console. (I suppose that is an add-on? Hmm, I don't\n>> have internet access from Linux... ).\n> \n> JavaScript Console is built in, though there are plugins like Console^2\n> that extend it.\n> \n> In Mozilla 1.7.12 it is \"Tools > Web Development > JavaScript Console\"\n> It is \"Tools > Errors Console\" or \"Tools > Web Console\" in modern Firefox.\n\nAh, OK. I thought you meant something other than the \"Error Console\".\nIn that case, *no* javascript errors appear in the error console.\n\nATB,\nRamsay Jones\n"}]}