On Sun, Jul 22, 2012 at 09:57:18PM +0200, Stefan Fritsch wrote:
And if it gets secured to where a code execution exploit does not grant
full root rights, I would probably be in favor of including it with httpd.
I took a look using seccomp for this, and it would seem it is actually
rather hard;
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I simply skipped using it and instead
used the svn.merge script which, for the curious, does a simple
diff and patch.
I'm guessing that things are
On Thu, Jul 19, 2012 at 04:17:44PM +0200, Steinar H. Gunderson wrote:
Furthermore, Fedora has recently accepted the mpm-itk patch into their Apache
packages.
For the record, that is not accurate. The Fedora httpd package does not
contain the mpm-itk patch, I have repeatedly refused to add it
Is this still useful: svnmerge.py ?
http://www.orcaware.com/svn/wiki/Svnmerge.py
On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote:
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I
On 23.07.2012 17:55, Jim Jagielski wrote:
Is this still useful: svnmerge.py ?
http://www.orcaware.com/svn/wiki/Svnmerge.py
A quick check of
http://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/svnmerge/
and the mailing list activity suggests, that there isn't much going
Nah... obsoleted by merge tracking (svn:mergeinfo) with the svn 1.5 release.
Please ignore that script and use svn merge.
And also that svn is a TLP sibling nowadays can surely help :-)
Cheers,
-g
On Jul 23, 2012 10:56 AM, Jim Jagielski j...@jagunet.com wrote:
Is this still useful:
On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote:
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I simply skipped using it and instead
used the svn.merge script which, for the
On 23.07.2012 19:21, Joe Orton wrote:
On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote:
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I simply skipped using it and instead
used
Short question: should ProxyBlock apply to the hostname from the request
URI, or the hostname of the next hop?
Long question: the way ProxyBlock is documented does not make explicit
that it is applied to the next hop; it would be natural to expect it is
matched against the request URI
b) if it's not the desired behaviour, that's a lot more messy.
I had assumed this was a bug in the checking but apparently never
brought it here correctly.
On Mon, Jul 23, 2012 at 03:41:19PM -0400, Eric Covener wrote:
b) if it's not the desired behaviour, that's a lot more messy.
I had assumed this was a bug in the checking but apparently never
brought it here correctly.
Ah ha! I hadn't checked the list archives, sorry - you did indeed post
Jim Jagielski wrote on Mon, Jul 23, 2012 at 11:55:32 -0400:
Is this still useful: svnmerge.py ?
http://www.orcaware.com/svn/wiki/Svnmerge.py
For 1.4 repositories (regardless of server software version) yes. I'd
not use both svnmerge.py and 'svn merge' on the same branch, that's just
I can fix it up easily enough if you want to roll an RC2, otherwise I
can fix it up after 1.38 is out since this is nothing new.
Sure, go ahead and I'll roll RC2.
On Mon, Jul 23, 2012 at 1:38 AM, Steve Hay steve@verosoftware.com wrote:
Fred Moyer wrote on 2012-07-20:
Please download,
13 matches
Mail list logo
