Updating from my local build 1.32 (which works fine) to a local build
(but not necessary with the same configure options) 1.34 I now get
cannot locate home directory - please set the FOSSIL_HOME or HOME environment
variables
from fossil using in a cgi script. What changed? And the variables
On 11/4/15, Rolf Ade wrote:
>
>
> Updating from my local build 1.32 (which works fine) to a local build
> (but not necessary with the same configure options) 1.34 I now get
>
>
> cannot locate home directory - please set the FOSSIL_HOME or HOME
> environment variables
>
>
>
Thus said Richard Hipp on Wed, 04 Nov 2015 21:31:38 -0500:
> On the https://www.fossil-scm.org/fossil website (which also runs as
> CGI) the HOME environment variable is set to /root, but no such
> directory exists within the chroot jail in which Fossil is running.
While /root doesn't
Dear all,
I am serving repositories on our internal server via the Fossil GCI mechanism
behind Apache2 with SSL. The system is OS X. Everything was running perfectly,
but today I have updated the OS X Server app to the new version and while
everything is still running, Fossil now fails to
Hi Taras,
I've had a very similar problem. I fixed it by setting the "HTTPS"
environment variable (for CGI execution) to "on" when the request comes
in through https, i.e.
SetEnv HTTPS on
You might want to remove the "" part if you're only accepting https
anyway.
I'm not sure whether this
On Thu, Nov 5, 2015 at 7:52 AM, Stephan Beal wrote:
> You've hit it right on the head: POLICY. No SCM should enforce
> project-specific policies, and symlinks (for me) fall into that category.
>
And next time i'll finish reading the new thread posts before replying.
On Tue, Nov 3, 2015 at 4:48 PM, Eric Rubin-Smith wrote:
>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal
> wrote:
>
>>
>> Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous
>> link to /etc might be wrong in certain build
On Tue, Nov 3, 2015 at 7:59 PM, David Mason wrote:
>
> It's simple: a symlink is a filesystem artifact and should be reflected as
> such in the repository. It should not be followed; if foo is a symlink and
> I say "fs add foo/bar" it should probably give an error. (This
Piotr Orzechowski wrote:
>
> Trying "make distclean" did not help, the error persisted.
>
Odd, it did work here (i.e. adding "--with-tcl-private-stubs=1"
to configure after "make distclean").
>
> #define Tcl_Canceled(a,b) TCL_OK did its job well. :)
>
Glad to hear it.
--
Joe Mistachkin
>
> This issue was more subtle than it originally appeared. I think the
> current
> trunk
> changes should make it work right for both versioned and non-versioned
> allow-symlinks
> settings.
Thanks so much for looking at that. I was trying to get started writing
some unit test cases around
Thus said Eric Rubin-Smith on Wed, 04 Nov 2015 10:01:10 -0500:
> * Failures: amend-comment-5.1 amend-comment-5.2 amend-comment-5.3
> amend-comment-5.4
These are unaffected. If you were to enable -verbose mode they would
probably indicate that you're missing ed (necessary for testing
Thus said Warren Young on Tue, 03 Nov 2015 15:44:04 -0700:
> This isn't a LaTeX issue at all. I see substantially the same problem
> with #includes on newer versions of GCC. Older versions of the code
> carry a presumption about the tools used to build the code. You can't
> expect
12 matches
Mail list logo