[fossil-users] 1.34: "cannot locate home directory"

2015-11-04 Thread Rolf Ade
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

Re: [fossil-users] 1.34: "cannot locate home directory"

2015-11-04 Thread Richard Hipp
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 > > >

Re: [fossil-users] 1.34: "cannot locate home directory"

2015-11-04 Thread Andy Bradford
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

[fossil-users] Fossil does not generate https link prefix

2015-11-04 Thread Taras Zakharko
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

Re: [fossil-users] Fossil does not generate https link prefix

2015-11-04 Thread Eduard
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

Re: [fossil-users] symlinks (was Re: xkcd on git)

2015-11-04 Thread Stephan Beal
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.

Re: [fossil-users] symlinks (was Re: xkcd on git)

2015-11-04 Thread Stephan Beal
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

Re: [fossil-users] symlinks (was Re: xkcd on git)

2015-11-04 Thread Stephan Beal
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

Re: [fossil-users] Can't build Fossil 1.34 with Tcl 8.5

2015-11-04 Thread Joe Mistachkin
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

Re: [fossil-users] symlinks (was Re: xkcd on git)

2015-11-04 Thread Eric Rubin-Smith
> > 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

Re: [fossil-users] symlinks (was Re: xkcd on git)

2015-11-04 Thread Andy Bradford
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

Re: [fossil-users] handling backports

2015-11-04 Thread Andy Bradford
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