Re: [fossil-users] Feature requests: fossil ui and server improvements
Hi! On Wed, Feb 20, 2013 at 4:31 AM, Warren Young war...@etr-usa.com wrote: I gather that it behaves the way it currently does because fossil server was added later, and before that point, fossil ui was the only way to get Fossil to act as a web server. That makes this stay running behavior of fossil ui vestigial now, no? If I want Fossil to remain running to provide network service, I should use fossil server not fossil UI, right? The problem with that is, fossil cannot know when the browser exits because modern browser start scripts don't always behave intuitively: stephan@host:~]$ google-chrome Created new window in existing browser session. [stephan@host:~]$ 4. It would be nice if Fossil would probe for the existence of X11 on *ix type systems before attempting to start the browser. The code in this question should work: http://stackoverflow.com/**questions/637005/x-server-**runninghttp://stackoverflow.com/questions/637005/x-server-running That requires yet another library dependency, however, and gives us, in essence, no new functionality. If we start a browser and X11 (or forwarding of X11 over ssh) is not available then the browser will die with something like cannot open display. It would be wrong, IMO, to move that level of detection of external errors into fossil. There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Feature requests: fossil ui and server improvements
Stephan Beal sgb...@googlemail.com writes: There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. Links[1] supports at least some Javascript. Not sure how well--I've only ever used it on the couple of occasions I've needed to SSH from work to my home computer and fiddle with the web interface on the wireless point. [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29 ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom car...@wistly.net wrote: Stephan Beal sgb...@googlemail.com writes: There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. Links[1] supports at least some Javascript. Not sure how well--I've only ever used it on the couple of occasions I've needed to SSH from work to my home computer and fiddle with the web interface on the wireless point. [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29 Interesting. I never thought to try that, but it does work. I did this: sudo apt-get install lynx fossil setting web-browser lynx fossil ui ... and it works! You don't see the timeline graph (of course) and the side-by-side diff display doesn't work, but a lot of things do work. ___ 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] Feature requests: fossil ui and server improvements
Richard Hipp d...@sqlite.org writes: On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom car...@wistly.net wrote: Stephan Beal sgb...@googlemail.com writes: There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. Links[1] supports at least some Javascript. Not sure how well--I've only ever used it on the couple of occasions I've needed to SSH from work to my home computer and fiddle with the web interface on the wireless point. [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29 Interesting. I never thought to try that, but it does work. I did this: sudo apt-get install lynx fossil setting web-browser lynx fossil ui ... and it works! You don't see the timeline graph (of course) and the side-by-side diff display doesn't work, but a lot of things do work. You probably know this already, but just so anyone reading the list's archives is clear: lynx and links are two separate, unrelated text-mode browsers. The latter supports (some) Javascript; the former does not. ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 09:40:27AM -0500, Richard Hipp wrote: On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom car...@wistly.net wrote: Stephan Beal sgb...@googlemail.com writes: There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. Links[1] supports at least some Javascript. Not sure how well--I've only ever used it on the couple of occasions I've needed to SSH from work to my home computer and fiddle with the web interface on the wireless point. [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29 Interesting. I never thought to try that, but it does work. I did this: sudo apt-get install lynx fossil setting web-browser lynx fossil ui ... and it works! You don't see the timeline graph (of course) and the side-by-side diff display doesn't work, but a lot of things do work. I've used it several times; I recall there were some issues about the spawn of the text browser, but I can't remember now. And I think elinks is more clever than links, for javascript, iirc. I use elinks most, among textmode browsers. Regards, Lluís. ___ 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] Feature requests: fossil ui and server improvements
On Tue, Feb 19, 2013 at 10:31 PM, Warren Young war...@etr-usa.com wrote: 3. The enter_chroot_jail() stuff seems to be broken. The enter_chroot_jail() routine works fine with the fossil http command. I have setups in active use where I launch fossil from xinetd as root and it does the right thing. But I can't say that I have every tried it with fossil server. It has never before occurred to me to use it in that way. It might have never worked. -- 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] Feature requests: fossil ui and server improvements
On Wed, 20 Feb 2013 15:40:27 +0100, Richard Hipp d...@sqlite.org wrote: On Wed, Feb 20, 2013 at 9:19 AM, Carson Chittom car...@wistly.net wrote: Stephan Beal sgb...@googlemail.com writes: There is also no reason to prohibit text-based browsers. i'm not aware of any which support JavaScript, meaning that they will be severely castrated when using fossil, but it would be wrong to prohibit them just because X11 isn't running. Links[1] supports at least some Javascript. Not sure how well--I've only ever used it on the couple of occasions I've needed to SSH from work to my home computer and fiddle with the web interface on the wireless point. [1] http://en.wikipedia.org/wiki/Links_%28web_browser%29 Interesting. I never thought to try that, but it does work. I did this: sudo apt-get install lynx fossil setting web-browser lynx fossil ui ... and it works! You don't see the timeline graph (of course) and the it would be nice to make this (text browsers) really usable. re the timeline graph: here (text browser) as well as in the CLI timeline output it would be a further point to the wish list to have an ASCII art rendering of the graph a la `hg glog' which I find extremely helpful. right now with fossil one is really forced to use a full-fledged web browser to understand the topology of a repo. side-by-side diff display doesn't work, but a lot of things do work. well not quite, not for me: the timeline links are not recognized (neither by lynx, nor by links, nor by w3m, nor by elinks (the latter being a spin-off of links supporting frames and being quite nice over all): lynx highlights the sha1 hashes but I can't navigate to them and activate the link. `links' does not recognize/highlight the sha1 hashes at all, `elinks' believes nearly everything on the page is a (dead) link. can someone confirm these problems? j. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 9:47 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Feb 19, 2013 at 10:31 PM, Warren Young war...@etr-usa.com wrote: 3. The enter_chroot_jail() stuff seems to be broken. The enter_chroot_jail() routine works fine with the fossil http command. I have setups in active use where I launch fossil from xinetd as root and it does the right thing. But I can't say that I have every tried it with fossil server. It has never before occurred to me to use it in that way. It might have never worked. So I just tried it. I type: sudo /home/drh/bin/fossil server and it is working fine for me. Browsing to http://localhost:8080/test_env; confirms that fossil has entered a chroot jail prior to serving content. So, I'm not able to reproduce your problem. -- D. Richard Hipp d...@sqlite.org -- 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 3:51 PM, j. van den hoff veedeeh...@googlemail.comwrote: can someone confirm these problems? Just to be pedantic for a moment: i wouldn't call them problems unless they are supposed to work, and i don't think we've ever focused on anything working for text-based browsers (and, more recently, any browsers without javascript). Yes, it would be nice if [e]links worked great with fossil, but more and more functionality has been implemented with JS and CSS over time, and that largely runs counter to the text browsers' capabilities (though elinks has decent color support). i remember trying fossil out once or twice on elinks, just to see what happened, but i don't think it's realistic to expect any text-mode browser to be a tier-1 client in terms of supported features. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 10:06 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Feb 20, 2013 at 3:51 PM, j. van den hoff veedeeh...@googlemail.com wrote: can someone confirm these problems? Just to be pedantic for a moment: i wouldn't call them problems unless they are supposed to work, and i don't think we've ever focused on anything working for text-based browsers (and, more recently, any browsers without javascript). Yes, it would be nice if [e]links worked great with fossil, but more and more functionality has been implemented with JS and CSS over time, and that largely runs counter to the text browsers' capabilities (though elinks has decent color support). i remember trying fossil out once or twice on elinks, just to see what happened, but i don't think it's realistic to expect any text-mode browser to be a tier-1 client in terms of supported features. Well stated. -- 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] Feature requests: fossil ui and server improvements
On Wed, 20 Feb 2013 16:06:35 +0100, Stephan Beal sgb...@googlemail.com wrote: On Wed, Feb 20, 2013 at 3:51 PM, j. van den hoff veedeeh...@googlemail.comwrote: can someone confirm these problems? Just to be pedantic for a moment: i wouldn't call them problems unless whatever you call it if something does not work when testing it out. maybe you are more comfortable after `s/these problems/this behaviour/g'? I'm fully aware that fossil is not targeting full support of text browsers but that (text browser support) is what's discussed in the threat and that caused my question. they are supposed to work, and i don't think we've ever focused on anything working for text-based browsers (and, more recently, any browsers without javascript). Yes, it would be nice if [e]links worked great with fossil, but more and more functionality has been implemented with JS and CSS over time, and that largely runs counter to the text browsers' capabilities (though elinks has decent color support). i remember trying fossil out once or twice on elinks, just to see what happened, but i don't think it's realistic to expect any text-mode browser to be a tier-1 client in terms of supported features. which I don't (expect). question is, what functionality could easily be provided (ability to use the links in the timeline to see the code, e.g., would seem mandatory if text browsers are not completely off-limits). personally, I'm not _that_ much interested in text browser support (but it would minimize distraction by allowing to stay in the terminal). rather I would like to see better support of CLI usage without ever touching the browser. currently, I feel the inability to easily get a clear picture of the DAG (i.e. absence of an (optional) ASCII version of the DAG in the `fossil timeline' output) is the only important reason I by and then fire up the browser (granted, the graphical diff facility is nice but of course such tools are around anyway and can be called via `fossil gdiff' if need be). j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Feature requests: fossil ui and server improvements
On Tue, Feb 19, 2013 at 10:31 PM, Warren Young war...@etr-usa.com wrote: 2a. It would be nice if fossil server had a -A address flag to make it bind to a particular network interface, for use on multihomed machines. We would like to use a machine with multiple IP aliases have www.foo.com and fossil.foo.com in DNS, with Apache and Fossil both bound to port 80 but on different IPs. In http://www.fossil-scm.org/fossil/info/f4143c5b59 you can add an IP address to the --port option: fossil server --port 67.18.92.124:80 Please try it and let me know if you encounter any difficulties. Seems to work on linux and windows for me. -- 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] Feature requests: fossil ui and server improvements
Op 20-2-2013 15:51, j. van den hoff schreef: On Wed, 20 Feb 2013 15:40:27 +0100, Richard Hipp d...@sqlite.org wrote: Interesting. I never thought to try that, but it does work. I did this: sudo apt-get install lynx fossil setting web-browser lynx fossil ui ... and it works! You don't see the timeline graph (of course) and the side-by-side diff display doesn't work, but a lot of things do work. ELinks actually has no problems with the side-by-side diff; even the colouring works (if you set $TERM=xterm-256colors before you launch elinks, that is). The CAPTCHA is perfectly readable, as well. well not quite, not for me: the timeline links are not recognized (neither by lynx, nor by links, nor by w3m, nor by elinks I have to login first, but after that ELinks shows all the links properly -- and they all work, too. Check-ins, tickets, branches, everything shows up as expected. (Haven't tried lynx or links as yet). Perhaps Fossil doesn't recognize ELink's user-agent string, and that's why you need to log in first? The only thing elinks doesn't show properly on my machine, is the timeline graph. Of course, if you're using a different skin, that relies heavily on javascript and CSS, the chance of problems will rise accordingly. (I've included a syntax highlighter for my code on the artifact pages, but sadly, that doesn't seem to work in elinks). -- Martijn Coppoolse ___ 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] Feature requests: fossil ui and server improvements
On 2/20/2013 09:21, Richard Hipp wrote: In http://www.fossil-scm.org/fossil/info/f4143c5b59 you can add an IP address to the --port option: I don't see that that patch touches the parsing of -P in main.c: iPort = mxPort = atoi(zPort); It also doesn't change how inaddr.sin_addr.sin_addr is set in cgi.c, which you'd need to do in order to bind fossil to just one interface on a multihomed server. So, no surprise, when I try it here with -P 10.11.12.13:1415 I get: ../fossil: unable to open listening socket on ports 10 It is of course treating the leading 10 in the IP as a port number. ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 9:16 PM, Warren Young war...@etr-usa.com wrote: iPort = mxPort = atoi(zPort); Did you perchance grab the trunk by accident? This is in its own branch: http://fossil-scm.org/index.html/timeline?r=bind-to-ip http://fossil-scm.org/index.html/vdiff?from=12ff5ff85e0b61f0to=f4143c5b594fc836 and the sin_addr modification appears there. It also doesn't change how inaddr.sin_addr.sin_addr is set in cgi.c, which you'd need to do in order to bind fossil to just one interface on a multihomed server. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Feature requests: fossil ui and server improvements
On 2/20/2013 07:52, Richard Hipp wrote: So I just tried it. I type: sudo /home/drh/bin/fossil server and it is working fine for me. Browsing to http://localhost:8080/test_env; confirms that fossil has entered a chroot jail prior to serving content. I, too, can get fossil server to run as root when I make it serve a directory of *.fossil files. My problem case is different. It fails when serving a single repository, either when given a *.fossil file name as ?REPOSITORY? or when run from within an open Fossil checkout: $ fossil serve /path/to/repo.fossil Sorry for not specifying that in the original email. I had no reason to believe the two command forms would behave so differently with regard to permission handling. ___ 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] Feature requests: fossil ui and server improvements
On Wed, Feb 20, 2013 at 3:16 PM, Warren Young war...@etr-usa.com wrote: On 2/20/2013 09:21, Richard Hipp wrote: In http://www.fossil-scm.org/**fossil/info/f4143c5b59http://www.fossil-scm.org/fossil/info/f4143c5b59you can add an IP address to the --port option: I don't see that that patch touches the parsing of -P in main.c: I was referring to the version. The complete patch is a collection of two different checkins. The complete patch is here: http://www.fossil-scm.org/fossil/vdiff?from=12ff5ff85e0b61f0to=f4143c5b594fc836 iPort = mxPort = atoi(zPort); It also doesn't change how inaddr.sin_addr.sin_addr is set in cgi.c, which you'd need to do in order to bind fossil to just one interface on a multihomed server. So, no surprise, when I try it here with -P 10.11.12.13:1415 I get: ../fossil: unable to open listening socket on ports 10 It is of course treating the leading 10 in the IP as a port number. __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] Feature requests: fossil ui and server improvements
On 2/20/2013 13:23, Richard Hipp wrote:
On Wed, Feb 20, 2013 at 3:16 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
I don't see that that patch touches the parsing of -P in main.c:
I was referring to the version. The complete patch is a collection of
two different checkins. The complete patch is here:
I see.
Yes, that works for me, thanks.
I still think separating TCP port and IP address as two options makes
more sense. Patch attached.
Also, I've noticed that if you give 0 (or equivalently, a non-integer)
as the port number, fossil blindly accepts it, causing the stack to
allocate a random port. I think it would be better if Fossil treated -P
arguments = 0 the same as no -P given.
Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -1872,10 +1872,11 @@
** to ui may be a directory and will function as server if and only if
** the --notfound option is used.
**
** Options:
** --localauth enable automatic login for requests from localhost
+** -A|--addr IPADDRbind to IPADDR only instead of to all interfaces
** -P|--port TCPPORT listen to request on port TCPPORT
** --th-trace trace TH1 execution (for debugging purposes)
** --baseurl URL Use URL as the base (useful for reverse proxies)
** --notfound URL Redirect
** --files GLOBLISTComma-separated list of glob patterns for static files
@@ -1890,11 +1891,11 @@
int isUiCmd; /* True if command is ui, not server' */
const char *zNotFound;/* The --notfound option or NULL */
int flags = 0;/* Server flags */
const char *zAltBase; /* Argument to the --baseurl option */
const char *zFileGlob;/* Static content must match this */
- char *zIpAddr = 0;/* Bind to this IP address */
+ const char *zIpAddr = 0; /* Bind to this IP address (--addr) */
#if defined(_WIN32)
const char *zStopperFile;/* Name of file used to terminate server */
zStopperFile = find_option(stopper, 0, 1);
#endif
@@ -1904,10 +1905,11 @@
g.useLocalauth = find_option(localauth, 0, 0)!=0;
if( g.thTrace ){
blob_zero(g.thLog);
}
zPort = find_option(port, P, 1);
+ zIpAddr = find_option(addr, A, 1);
zNotFound = find_option(notfound, 0, 1);
zAltBase = find_option(baseurl, 0, 1);
if( zAltBase ){
set_base_url(zAltBase);
}
@@ -1917,16 +1919,10 @@
flags |= HTTP_SERVER_LOCALHOST;
g.useLocalauth = 1;
}
find_server_repository(isUiCmd zNotFound==0);
if( zPort ){
-int i;
-for(i=strlen(zPort)-1; i=0 zPort[i]!=':'; i--){}
-if( i0 ){
- zIpAddr = mprintf(%.*s, i, zPort);
- zPort += i+1;
-}
iPort = mxPort = atoi(zPort);
}else{
iPort = db_get_int(http-port, 8080);
mxPort = iPort+100;
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Feature requests: fossil ui and server improvements
1. If I say fossil ui and the browser starts successfully and then
exits, Fossil should exit, too. It should arguably exit even if it
fails to start the browser, since you asked for a UI and it couldn't
provide one.
I gather that it behaves the way it currently does because fossil
server was added later, and before that point, fossil ui was the only
way to get Fossil to act as a web server. That makes this stay
running behavior of fossil ui vestigial now, no? If I want Fossil to
remain running to provide network service, I should use fossil server
not fossil UI, right?
2a. It would be nice if fossil server had a -A address flag to make
it bind to a particular network interface, for use on multihomed
machines. We would like to use a machine with multiple IP aliases have
www.foo.com and fossil.foo.com in DNS, with Apache and Fossil both bound
to port 80 but on different IPs.
2b. It would also be nice to be able to set the HTTP_SERVER_LOCALHOST
internal flag with, say, fossil server -L, so that if you are proxying
access to Fossil, Fossil's listening port isn't directly accessible on
external network interfaces.
3. The enter_chroot_jail() stuff seems to be broken. I get this in the
browser if I try to run fossil server as root:
SQLITE_CANTOPEN: cannot open file at line 28175 of [7e10a62d0e]
SQLITE_CANTOPEN: os_unix.c:28175: (2) open(/server.fossil-journal) - No such
file or directory
SQLITE_CANTOPEN: statement aborts at 25: [INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://mongo:82',1,now())]
Database Error
unable to open database file: {INSERT INTO
config(name,value,mtime)VALUES('baseurl:http://mongo:82',1,now())}
If you have recently updated your fossil executable, you might need to run fossil
all rebuild to bring the repository schemas up to date.
I guess someone has messed up the order of operations here, so that the
DB isn't open by the time it tries this, hence why the DB's journal
doesn't yet exist. It's probably a good thing for the DB to not be
opened until after root privileges are dropped.
The only reason I'm trying to run Fossil as root is so I can bind it to
port 80, without using a reverse proxy.
I've tried both v1.24 and the fossil trunk:
This is fossil version 1.25 [646c4a67f9] 2013-02-19 12:29:39 UTC
4. It would be nice if Fossil would probe for the existence of X11 on
*ix type systems before attempting to start the browser. The code in
this question should work:
http://stackoverflow.com/questions/637005/x-server-running
I mention it because I'm writing a script that calls either fossil ui
or fossil server depending on whether a GUI is available. Checking
$DISPLAY isn't good enough because my Windows SSH client sets that
variable regardless of whether I have X running. (X sometimes *is*
running on the Windows box. Just not all the time.) So, Firefox tries
to run on my Linux server, thinking it can display on my Windows box, so
my SSH client spams me with errors that it could not forward packets to
the local X server until Firefox gives up and dies.
Fossil should check that $DISPLAY exists first, of course, so it doesn't
get confused on Cygwin and Mac systems, where it may find X libraries at
configure time, but where X is often not running.
I'm currently hacking around this in my script by attempting xterm -e
exit before fossil ui, since that results in only *one* error when X
isn't running.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
