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

[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 of
which environment? To which value?

rolf

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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
> 
>
> from fossil using in a cgi script. What changed? And the variables of
> which environment? To which value?

Fossil is trying to locate the "~/.fossil file that contains your
global settings.  I don't know why it is trying to do this.  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.

In the CGI script itself, you can add lines like this:

 setenv: HOME /some/path

Which will cause the HOME environment variable to be set to something.
But, again, I don't understand why you need it.

If you can figure out what is going wrong, we'd appreciate it if you
would report your findings.



>
> rolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 exist, HOME does. I believe the error is complaining
that the HOME environment variable does not exist.

$ env -i /tmp/fossil/fossil http
HTTP/1.0 200 OK
Date: Thu, 5 Nov 2015 03:46:22 GMT
Connection: close
X-UA-Compatible: IE=edge
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 118


cannot locate home directory - please set the FOSSIL_HOME or HOME environment 
variables


Does CGI mode not also require HOME to be set?

Thanks,

Andy
-- 
TAI64 timestamp: 4000563ad16a


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 generate the https:// prefixes 
for the links, instead using http://. As a result, security features in the 
modern browser ignore the CSS stylesheets (because there is a protocol 
mismatch). So while pushing, pulling as well as website do work — the later 
looks quite ugly. I was looking for the way to make Fossil generate https:// 
prefix, but I couldn’t find any definite information. 

I am sure that Fossil itself is not to blame, because everything was working 
perfectly before the server upgrade. But maybe someone has encountered a 
similar problem and can point me into a direction where to look. The server 
migration script did change the conf file header from:


  ServerName URL

to


  ServerName https://URL:443 

There were no other changes. Other services (some Rails applications) are 
running without any issues. 

Any ideas?

Best, 

 Taras___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 is the truly correct way to do it, but it sure
solved my problem.

Cheers,
Eduard

On 11/04/2015 11:48 PM, Taras Zakharko wrote:
> 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
> generate the https:// prefixes for the links, instead using http://.
> As a result, security features in the modern browser ignore the CSS
> stylesheets (because there is a protocol mismatch). So while pushing,
> pulling as well as website do work — the later looks quite ugly. I was
> looking for the way to make Fossil generate https:// prefix, but I
> couldn’t find any definite information. 
>
> I am sure that Fossil itself is not to blame, because everything was
> working perfectly before the server upgrade. But maybe someone has
> encountered a similar problem and can point me into a direction where
> to look. The server migration script did change the conf file header from:
>
> 
>   ServerName URL
>
> to
>
> 
>   ServerName https://URL:443 
>
> There were no other changes. Other services (some Rails applications)
> are running without any issues. 
>
> Any ideas?
>
> Best, 
>
>  Taras
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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.
Thanks to Joe for stepping in to stop the bikeshedding :).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 environments (and won't work
>> on Windows). Why should fossil assist in doing the wrong thing?
>>
>
> Here you give away the game by saying "IMO".  Whether it's wrong is a
> question of policy, as you seem to admit.  And such examples have clearly
> led you down a path of arguing that your policy is the right one -- to the
> detriment of the tool.
>

You've hit it right on the head: POLICY. No SCM should enforce
project-specific policies, and symlinks (for me) fall into that category.


> Your particular example is actually great for my case, because it applies
> with equal force to the case of filesystems.  A filesystem can be mounted
> at any mount point, so an absolute symlink to '/etc' that works fine when
> the FS is mounted at '/' will not be correct when the FS is mounted at
> '/foo/bar'.  So absolute symlinks are also wrong in this case.  Why should
> Linux assist in doing the wrong thing?
>

The OS is there to make anything possible. An SCM is there to track source
code (which, by long-standing convention, exists in one tree). That's
comparing one fruit with another fruit (sorry, but a certain luxury
hardware vendor has ruined the more conventional phrasing of that for me).


>
>> Stated yet another way: we don't expect the SCM to solve all problems
>>> that users create.
>>>
>>
>> But if it sets out to solve them, then it should solve them, not provide
>> a half-solution to philosophically unsolvable problems. (IMO.)
>>
>
> Your argument is analogous to an argument that compilers can't detect and
> correct all program bugs, so we may as well not write compilers at all.
> This is an enormous problem, you could argue, because almost all programs
> have bugs, and so the compiler is doomed to fail almost every time!
>

Again, fruit and other fruit. An SCM has a very specific target, whereas a
compiler is there to make _anything_ possible.


> We can support symlinks without setting out to solve all problems that
> arise.  It's not a half-solution -- it's a full solution to a narrower
> (and, in fact, pretty simple) problem.
>

If it were that simple, it likely would have been done to the majority's
satisfaction by now ;).


> It defaults to off, and it should go without saying that a "do the right
> thing" setting should default to on.
>

i disagree - "off" is the most platform-compatible option. i want all of my
source trees to check out identically on all platforms, and that cannot
happen if i've got a symlink in there. (That said, i _thought_ it defaulted
to "on" for Unix platforms.)

My thoughts on symlinks in SCMs can be summarized accurately in 3 words:
"can of worms."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 might
> surprise people the first time, but it's easy to explain - foo/bar isn't
> part of the repo, regardless of where foo points.)
>

But it's not quite that simple, philosophically speaking: we expect Fossil
to extract _exactly_ what we put in it, and that's not portably possible
when it comes to symlinks. As soon as someone checks out your repo on a
non-Unix system, fossil is creating output which you did not put in fossil.
That's a tremendous psychological/philosophical hurdle for me. i'd rather
live without symlinks than know that my repos check out differently
depending on the platform.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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 this so I could submit them back here.  I note
that 69 tests fail in version [2186f0f0e7] (see below).  Though it seems
pretty unlikely (from their names) that your symlink changes caused this.

* End of utf: 69 errors so far **
* Final result: 69 errors out of 27300 tests
* Failures: amend-comment-5.1 amend-comment-5.2 amend-comment-5.3
amend-comment-5.4 clean-6 clean-12 clean-18 relative-tree-name-100.1
relative-tree-name-100.2 relative-tree-name-100.3 relative-tree-name-100.4
relative-tree-name-101.1 relative-tree-name-101.2 relative-tree-name-101.3
relative-tree-name-102.1 relative-tree-name-102.2 relative-tree-name-102.3
relative-tree-name-103.1 absolute-tree-name-100.1 absolute-tree-name-100.2
absolute-tree-name-100.3 absolute-tree-name-100.4 absolute-tree-name-101.1
absolute-tree-name-101.2 absolute-tree-name-101.3 absolute-tree-name-102.1
absolute-tree-name-102.2 absolute-tree-name-102.3 absolute-tree-name-103.1
merge-utf-27-23 merge-utf-27-32 merge_multi-4 merge_renames-5
mv-soft-relative-2 mv-soft-relative-4 mv-hard-relative-2 mv-hard-relative-4
mv-soft-absolute-2 mv-soft-absolute-4 mv-hard-absolute-2 mv-hard-absolute-4
rm-soft-relative-4 rm-soft-relative-6 rm-hard-relative-4 rm-hard-relative-6
rm-soft-absolute-4 rm-soft-absolute-6 rm-hard-absolute-4 rm-hard-absolute-6
revert-1-1 revert-1-2 revert-1-3 revert-1-4 revert-1-5 revert-1-6
revert-1-7 revert-2-1 th1-checkout-1 th1-checkout-2 th1-header-2
th1-footer-2 th1-footer-3 th1-artifact-3 th1-artifact-5 th1-artifact-7
th1-artifact-9 th1-globalState-1 th1-globalState-8 th1-encode64-3

In any case, the three scenarios I am personally aware of behave as
expected now.  Thanks again!

For completeness, Warren Young seems to be complaining about Fossil's path
resolution logic when symlinks are present.  This is (from my perspective)
a very different issue, but you nevertheless may want to track it.  Also, I
did not read every detail in the thread ("xkcd on git") that led to this
subtopic, so perhaps people aired other symlink-related complaints there.

Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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  the
interactive edit of a comment).  I ran the suite and it runs fine:

* End of amend: 0 errors so far **
* Final result: 0 errors out of 123 tests

Andy
-- 
TAI64 timestamp: 4000563a2855


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] handling backports

[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  10-year-old sources  to  build  correctly under  bleeding-edge
> tools.

I'm not  sure what  is meant by  ``bleeding-edge'' tools,  but yabbawhap
(released in 1991) still compiles (presumably correctly), unmodified, on
a modern  OpenBSD system using GCC,  as do numerous other  packages that
are well over 15 years old and have received no modifications.

Andy
-- 
TAI64 timestamp: 40005639bf20


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users