Sorry if you don't appreciate me lumping all of these patches together. These are various fixes I had to make when installing Ikiwiki. Some are due it being a non-Debian system, the others are actual bugs. --- upstream/IkiWiki/Rcs/svn.pm 2006-09-16 01:11:55.000000000 +0100 +++ main/IkiWiki/Rcs/svn.pm 2006-09-16 01:12:50.000000000 +0100 @@ -34,7 +34,7 @@ my $field=shift; my $file=shift; - my $info=`LANG=C svn info $file`; + my $info=`svn info $file`; my ($ret)=$info=~/^$field: (.*)$/m; return $ret; } #}}} @@ -140,7 +140,7 @@ if $svn_version =~ /\d\.(\d)\.\d/ && $1 >= 2; my $svn_url=svn_info("URL", $config{srcdir}); - my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url'`, + my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url' --config-dir /tmp`, ForceArray => [ 'logentry', 'path' ], GroupTags => { paths => 'path' }, KeyAttr => { path => 'content' }, The first hunk of this patch is strange. It just failed to work with this in place, and it took me a long time to figure it out. I realise what you are trying to do, and it still works here as I use a similar LANG anyway. For reference svn version 1.3.1 (r19032), my $LANG=en_GB.utf8, but I'm not sure what the CGI was running under. > That's strange. Is the problem to do with setting LANG=C or to do > with the way it's set and exported on the same line as the svn info call? > Can you reproduce the problem running svn info outside of ikiwiki? > --[[Joey]] The second removes problems with cannot access /home/$user/.svnsomething in the logs. I think this problem was also fatal (I should have reported these sooner). I can try and debug these problems if you could suggest some way to do so, but I am probably losing the server in a couple of days, so I can't be of too much help I'm afraid. > I imagine that passing --config-dir /tmp would be either insecure or > would limit ikiwiki use to one user per machine. > `--config-dir /etc/subversion` might be better, though still a hack, > since a user's real ~/.subversion might be needed to access some repos. > > Maybe I didn't notice this problem since I have a ~/.subversion > everywhere that I've used ikiwiki. Hmm, no, I don't reproduce it, svn > happily recreated the directory during an ikiwiki run after I moved it > out of the way here. Maybe an issue with old versions of svn? Although > AFIACR, svn has auto-created ~/.subversion for years. > > What's the error message? --[[Joey]] ---- --- IkiWiki/Plugin/search.pm +++ IkiWiki/Plugin/search.pm @@ -99,7 +99,7 @@ close TEMPLATE; $cgi="$estdir/".IkiWiki::basename($config{cgiurl}); unlink($cgi); - symlink("/usr/lib/estraier/estseek.cgi", $cgi) || + symlink("/usr/local/libexec/estseek.cgi", $cgi) || error("symlink $cgi: $!"); } # }}} obviously I'm not asking you to include this patch, but it would be good if this sort of thing was configurable (at build time?). I can have a go if you like, but I'm not sure what would be acceptable to you. > This should be made configurable via an option in %IkiWiki::config, > the search plugin could register a getopt hook to handle it. --[[Joey]] ---- --- IkiWiki.pm +++ IkiWiki.pm @@ -734,7 +734,18 @@ my $page=shift; my $spec=shift; - return eval pagespec_translate($spec); + my $pagespec = pagespec_translate($spec); + + my $newpagespec; + + local($1); + if ($pagespec =~ /(.*)/) { + $newpagespec = $1; + } else { + die "oh"; + } + + return eval $newpagespec; } #}}} sub match_glob ($$) { #{{{ This works around a silly, but extremely annoying, taint bug in older versions of perl. I'm not sure of the details, but it means that either values become tainted from nowhere, or they don't get untainted possibly. This also affects backports to sarge. `"oh"` is not going to be very informative if that code path is ever taken, but I hope that it never is. > You're not the first person to report a problem here with older versions > of perl and pagespec tainting. I suspect that this would work around it: return eval possibly_foolish_untaint(pagespec_translate($spec)); > I'm _very_ uncomfortable putting that in the shipping version of ikiwiki, > because pagespecs are potentially _insanely_ dangerous, given how they're > evaled and all. The tainting is the only sanity check there is that > `pagespec_translate` manages to clean up any possibly harmful perl code > in a pagespec. It's good to have belt and suspenders here. > > For all I know, older versions of perl are keeping it tainted because > `pagespec_translate` is somehow broken under old versions of perl and is > in fact not fully untainting the pagespec. Ok, probably not, it's more > likely that some of the regexps in there don't manage to clear the taint > flag with old versions of perl, while still doing a perfectly ok job of > sanitising the pagespec. > > I suppose that the version of perl ($^V) could be checked and the untaint > only be called for the old version. Though it seems it would be better > to try to debug this some first. Maybe instrumenting `pagespec_translate` > with calls to Scalar::Utils's tainted() function and seeing which parts > of pagespecs arn't getting untainted would be a good start. > > --[[Joey]] ---- As for backports there is a problem with the sarge version of libcgi-session-perl and my sslcookie patch (complaints about a missing include file auto/CGI/Session/cookie.al IIRC). This file does not and has not ever existed, but it appears to be fixed in the backport of libcgi-session-perl that I did. That puts the dependency required at somewhere between 3.95-2 and 4.14-1. This could then be added to debian/control. It would mean one more package to backport, but stops the bug if anyone actually uses my sslcookie option except me. > May as well, done --[[Joey]] As for backports I managed with * ikiwiki_1.26 * libcgi-formbuilder-perl_3.03.01-1 * libcgi-session-perl_4.14-1 backported to sarge, with bpo in sources.list. This only covers Depends: though, for instance hyperestraier needs to be backported, which I haven't got round to yet as there is a chain to do.