Re: [fossil-users] Fossil crashing when opening or checking out a repository.

[Michael Richter]

Trying to open the same repository under a Linux system (fossil version
1.33 [5b456cfa6b]) gives me this: "[1]9388 segmentation fault  fossil
open /path/to/Joystick.fossil"

On 15 April 2016 at 11:31, Michael Richter  wrote:

> Platform: Windows 10.
> Fossil version: 1.34 [62dcb00e68]
>
> After making a few changes to a project (IAR Embedded Workbench for ARM)
> and committing them on a feature branch, I tried to check out the main
> development branch.  The result was a hard crash.  My repository is now in
> a state where I can't open it, even in a fresh directory, and even after
> doing a "fossil all rebuild".  When I try I get Windows 10's idiotic
> dialogue: "Fossil is a simple, high-reliability, distributed software
> configuration management system. has stopped working \ A problem caused the
> program to stop working correctly.  Windows will close the program and
> notify you if a solution is available."  (All typos and odd wording
> straight from the original.)
>
> "fossil export" crashes as well.
>
> I appear to have lost, according to "fossil ui" one check-in's worth of
> work, most of which I fortunately happen to have in an archive.  I'm not
> sure, however, how to go about getting the repository into a recoverable
> state.  I *could* just use that archive as the basis of a new repository,
> but now I'm left with this nagging question of when it will happen again.
>
> Can anybody suggest some steps forward to recovery here?
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions
> of entering China our focus has really been what's best for the Chinese
> people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
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 crashing when opening or checking out a repository.

[Michael Richter]

Platform: Windows 10.
Fossil version: 1.34 [62dcb00e68]

After making a few changes to a project (IAR Embedded Workbench for ARM)
and committing them on a feature branch, I tried to check out the main
development branch.  The result was a hard crash.  My repository is now in
a state where I can't open it, even in a fresh directory, and even after
doing a "fossil all rebuild".  When I try I get Windows 10's idiotic
dialogue: "Fossil is a simple, high-reliability, distributed software
configuration management system. has stopped working \ A problem caused the
program to stop working correctly.  Windows will close the program and
notify you if a solution is available."  (All typos and odd wording
straight from the original.)

"fossil export" crashes as well.

I appear to have lost, according to "fossil ui" one check-in's worth of
work, most of which I fortunately happen to have in an archive.  I'm not
sure, however, how to go about getting the repository into a recoverable
state.  I *could* just use that archive as the basis of a new repository,
but now I'm left with this nagging question of when it will happen again.

Can anybody suggest some steps forward to recovery here?

-- 
"Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
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] How to actually >use< TH1?

[Andy Bradford]

Thus said Johan Kuuse on Wed, 13 Apr 2016 06:52:30 +0200:

> But I have had no success when  trying to use TH1 with the xfer pages.
> What I try to achieve is to use  a TH1 script to check the contents of
> a commit message, and conditionally reject the commit depending on the
> message syntax.

I'm not  sure this  is a  good use  for TH1.  Specifically, what  if the
commit is large  and you receive most of the  artifacts before receiving
the actual manifest artifact?

If the transfer invovles multiple syncs  to get across the wire, some of
the artifacts  will have been  committed to your repository  already and
now you'll end up with artifacts that  are not referenced in any of your
manifests, and  given that the manifest  has a commit message  that will
never meet the criteria you'll end up with a lot of clutter.

Perhaps I'm wrong?

Thanks,

Andy
-- 
TAI64 timestamp: 40005710524c


___
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] CGI arguments other than "repository" and "notfound"

[Richard Hipp]

On 4/14/16, Thomas Levine <_...@thomaslevine.com> wrote:
> Hi,
>
> "fossil serve" provides several options that I can't find for
> the CGI program "fossil cgi".

See the source code
(https://www.fossil-scm.org/fossil/artifact/2c2d97aec0?ln=2055-2190)
for a complete list.  Undocumented options might disappear in some
future release.

-- 
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

[fossil-users] CGI arguments other than "repository" and "notfound"

[Thomas Levine]

Hi,

"fossil serve" provides several options that I can't find for
the CGI program "fossil cgi".

The only "cgi" options I have managed to find are "repository" and
"notfound", as documented here.
https://www.fossil-scm.org/index.html/doc/trunk/www/server.wiki

I want to use --repolist and --baseurl in the CGI program.
Is this possible?

Here are the "serve" options, for reference.

  > fossil help serve | sed -n '/Options/,$ p'
  Options:
--baseurl URL   Use URL as the base (useful for reverse proxies)
--createCreate a new REPOSITORY if it does not already exist
--files GLOBLISTComma-separated list of glob patterns for static files
--localauth enable automatic login for requests from localhost
--localhost listen on 127.0.0.1 only (always true for "ui")
--nojailDrop root privileges but do not enter the chroot jail
--notfound URL  Redirect
-P|--port TCPPORT   listen to request on port TCPPORT
--th-trace  trace TH1 execution (for debugging purposes)
--repolist  If REPOSITORY is dir, URL "/" lists repos.
--scgi  Accept SCGI rather than HTTP
--skin LABELUse override skin LABEL

  See also: cgi, http, winsrv

Thanks

Tom
___
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] HOWTO: TLS-protected Fossil with nginx and Let's Encrypt

[Warren Young]

On Apr 14, 2016, at 3:50 PM, Joerg Sonnenberger  wrote:
> 
> On Thu, Apr 14, 2016 at 03:32:48PM -0600, Warren Young wrote:
>> STEP 1: Split your “server” configurations
> 
> I don't think this is necessary at all.

It is.  We want the proxy server to redirect all Fossil-over-HTTP requests to 
HTTPS, which means URLs may be interpreted differently depending on the 
protocol you use.

It is only all other URLs that are interpreted the same irrespective of the 
protocol.

There’s also no point to serving Let’s Encrypt’s challenge/response files over 
HTTPS.  They’re only needed during the ACME negotiation, which always proceeds 
over HTTP, else you couldn’t bootstrap the system.

>> STEP 2: Prepare for the Let’s Encrypt challenge/response sequence
> 
> This part can just statically go into the same server block, no need for
> a separate file.

My nginx server serves four different sites, and I wanted the generated SSL key 
to be good for all of them.  If you don’t extract this to an include file, you 
have to repeat it in each site’s server { } block.

For each domain you give to letsencrypt via the -d flag, Let’s Encrypt’s ACME 
service repeats the challenge/response process.  If any domain given via -d 
returns a 404 error when the ACME service attempts to access 
/.well-known/acme-challenge/* on that domain name, the cert generation process 
will fail.

Thus, you must repeat this block in each server { } block for which you give a 
-d flag, else the whole process fails.  Let’s Encrypt won’t just skip over them 
and give you a key for a subset of the domains you requested.  It’s 
all-or-nothing.

>> STEP 3: Write the wrapper script
> 
> Personally, I would recomment just using the SSH FUSE binding and doing
> the dance from a separate machine. No need to have letsencrypt and all
> dependencies running on a server.

Fossil only does user authentication and permission management over HTTP.  If 
you serve it over plain SSH, all users effectively get admin-level privileges 
on the repository, which is only acceptable when serving a private repo among 
trusted colleagues.

There are games you can play with OpenSSH configuration files to get 
Fossil-over-HTTP-over-SSH and thus still let Fossil do user/permission 
management, but that’s about as complex to set up as this nginx proxying 
scheme.  It’s an ongoing complexity, too: for every user you add, you must 
duplicate the SSH configuration hackery to give them access to the Fossil repo. 
 Whereas with HTTPS proxying, it’s a one-shot effort.

The only advantage SSH has here over HTTPS is that it doesn’t require you to 
use a centralized PKI for keys; it’s perfectly acceptable to use decentralized 
PSKs with SSH.  Now that we have Let’s Encrypt, the disadvantages of a 
centralized PKI in the TLS case disappear.

>> Let’s Encrypt certs only last for 90 days, which means it’s an ongoing
>> task to keep this up-to-date.  Until Let’s Encrypt learns about safe
>> nginx configuration file modification, it’s a manual process.  (With
>> Apache, letsencrypt-auto sets up a background auto-renewal process so
>> you can’t forget to renew.  You could script this manually for nginx,
>> if you wanted.)
> 
> Given that it is *not* supposed to change the configuration on renewal
> at all, that's a non-issue.

The nginx configuration doesn’t change, but the content of the *.pem files *do* 
change on each renewal.  If you don’t re-generate those files and reload the 
nginx configuration every 90 days at most, it continues to serve those 
now-expired certs until you do.  With HSTS enabled, that means clients that 
obey the HSTS demand will stop talking to your server, because they were told 
to only accept HTTPS, and they refuse to talk to an HTTPS server with an 
expired cert.

Something I forgot to mention in the article is that we created the 
letsencrypt-wrapper script instead of just giving the command in the script 
interactively because the renewal process is basically “re-run the wrapper and 
restart nginx”.  So, you could cron that process to run every 80 days or so, 
avoiding the risk of locking your users out by forgetting to renew the cert.

I’m still wary of doing that, since I’ve had server upgrades empty the crontab 
files so that all the scheduled jobs don’t run any more.  You only discover 
this after you get the tech support call.
___
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] HOWTO: TLS-protected Fossil with nginx and Let's Encrypt

[Joerg Sonnenberger]

On Thu, Apr 14, 2016 at 03:32:48PM -0600, Warren Young wrote:
> STEP 1: Split your “server” configurations

I don't think this is necessary at all.

> STEP 2: Prepare for the Let’s Encrypt challenge/response sequence

This part can just statically go into the same server block, no need for
a separate file.

> STEP 3: Write the wrapper script

Personally, I would recomment just using the SSH FUSE binding and doing
the dance from a separate machine. No need to have letsencrypt and all
dependencies running on a server.

> STEP 5: Create the base SSL/TLS configuration
> --
> 
> We extracted the site configuration from our server { } blocks above because 
> we now need to create a second such block for each site that nginx serves.
> 
> server {
> include local/ssl;
> include local/site;
> }
> 
> That is, instead of including the letsencrypt-challenge file — since we only 
> serve the Let’s Encrypt challenge/response sequence via HTTP — we include the 
> following SSL configuration file:
> 
> listen 443 ssl;
> 
> ssl on;

No need for "ssl on" in combination with the ssl on the listen line --
means all the config can be shared with plain HTTP.

> Let’s Encrypt certs only last for 90 days, which means it’s an ongoing
> task to keep this up-to-date.  Until Let’s Encrypt learns about safe
> nginx configuration file modification, it’s a manual process.  (With
> Apache, letsencrypt-auto sets up a background auto-renewal process so
> you can’t forget to renew.  You could script this manually for nginx,
> if you wanted.)

Given that it is *not* supposed to change the configuration on renewal
at all, that's a non-issue.

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

[fossil-users] HOWTO: TLS-protected Fossil with nginx and Let's Encrypt

[Warren Young]

The existing documentation [1] for setting up SSL with Fossil is pretty thin.  
“Just set up an SSL web proxy,” it says.  Yeah, “just.” :)

Other advice recently given on this list is to use stunnel, but that’s only of 
use when Fossil hosts the whole web site, so you just need to proxy Fossil.  If 
Fossil is just a *part* of an existing web site — e.g. a typical open source 
project site, with docs, downloads, a forum, a blog, etc. all hosted outside 
Fossil, such as static files, a CMS, etc. — you’re probably using a full web 
server or a proxy server of some kind, and need to enable SSL/TLS in *that* 
layer instead.

Another thing about the existing documentation is that it’s focused on 
self-signed certs, which requires messing with the platform’s certificate trust 
store to allow Fossil to trust your certificate.  Here in 2016, we don’t need 
to mess with self-signed certs any more.

I’ve recently worked out solutions to all of the above problems, so I thought 
I’d document the process here.

The main thing that makes all of this relatively painless is Let’s Encrypt [2], 
which provides free globally-trusted TLS certificates for you, on demand.  It’s 
in a beta state right now, a fact which will cause us a bit of grief below, but 
even in its current state it’s still better than the bad old manual way, 
involving a lot of openssl command line gymnastics.

If you’re using Apache as your front end proxy (e.g. mod_proxy) you can use the 
letsencrypt-auto helper, which will let you skip a few of the steps below as 
they’re taken care of by the helper program.

I prefer nginx for simple proxying, however, because its takes a lot less RAM 
than Apache, which directly affects how much I need to spend per month on 
hosting fees: VPS and cloud hosting providers charge for the RAM you use, so 
the less RAM you need, the lower your hosting fees.

Unfortunately, the automatic Let’s Encrypt certificate installer doesn’t yet 
know how to safely modify your nginx configuration files, so you have to do it 
by hand.  The rest of this article will assume you’re going down this 
semi-manual path.



STEP 1: Split your “server” configurations
--

Throughout this article, we’re going to assume that we’re setting up HTTPS as a 
simple alternative for most of the site, which will continue to be accessible 
over HTTP.  The only exception will be the Fossil sub-section, which we’ll 
force to HTTPS for security reasons.

You probably have your site’s nginx configuration written as a single server { 
} block at the moment, because it is only serving on port 80/HTTP.  The way 
nginx works, you need a separate block to serve the same content on port 
443/HTTPS.

Since most of the port 80 configuration will be the same as the port 443 
configuration, we’ll follow the DRY principle and extract the common bits to a 
separate file.  Thus, this:

   server {
   listen 80;
   server_name .example.com 1.2.3.4 “”;
   location / {
   root /var/www/example.com;
   ...
   }
   ...
   }

…needs to become this:

   server {
   listen 80;
   include local/letsencrypt-challenge;
   include local/site;
   }

…plus a separate per-site file, which we’re calling local/site stored relative 
to your nginx configuration directory:

   server_name .example.com 1.2.3.4 “”;
   location / {
   root /var/www/example.com;
   ...
   }
   ...

We’ll write the second server { } block for the HTTPS case later, after we’ve 
generated the TLS keys.

If your nginx server has multiple name-based virtual hosts and you want this 
TLS cert to cover all of them, split those, too.  Each one needs to include the 
letsencrypt-challenge file, which we’ll create in the next step.



STEP 2: Prepare for the Let’s Encrypt challenge/response sequence
--

The server { } block above includes a file called local/letsencrypt-challenge, 
which contains this:

location '/.well-known/acme-challenge' {
default_type "text/plain";
root /var/www/letsencrypt;
}

This simply declares that any URL beginning with the Let’s Encrypt ACME 
protocol challenge prefix is served from a directory somewhere under your OS’s 
web root.

The letsencrypt program writes temporary challenge/response files in that 
directory for remote access by the Let’s Encrypt ACME service, so it needs to 
be a) writeable by the one who runs the wrapper script in a later step; and b) 
readable by the web server, which on SELinux-protected machines often means a 
specific sub-tree of the filesystem, like /var/www. 

(Because these challenge/response files are ephemeral, served only during the 
ACME negotiation, some tutorials you’ll find online will recommend using 
something in /tmp instead, but that doesn’t work under MAC systems like SELinux 
that restrict the web server to reading from only certain directories.  That’s 
why I recommend using /var/www/letsencrypt above.  If your host OS has a MAC 
system but 

Re: [fossil-users] feature implemented or suggestion for stash

[Ross Berteig]

On 4/14/2016 11:10 AM, Stephan Beal wrote:

On Thu, Apr 14, 2016 at 7:00 PM, Warren Young > wrote:
On Apr 12, 2016, at 11:30 PM, Stephan Beal > wrote:
> i haven't ever bisected.
Wow…

I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)


The ability to bisect is one of the strongest arguments in favor of
version control.


I've needed it in the past, but as luck had it only on projects from 
before I knew about fossil, and I suspect before fossil really existed. 
CVS was fine for keeping a change log and record of the past from which 
with great luck and careful usage one *might* be able to return to a 
past build. Bisect was not something that would have been easily done 
with it.


Since I've been using fossil, luck has mostly kept me from needing to 
search for obscure bugs that were latent until noticed. But from 
watching the list and noticing the ease with which others have used it 
for that purpose, it was clearly not only a compelling argument in favor 
of version control, but also a compelling reason to never check in 
anything to trunk that breaks the build.



i admit that it's a fantastic capability, i've just never needed to use
it. (Contrast with "fossil clean" - i have Opinions about anyone other
than myself cleaning up my source trees, and simply _won't_ use that
feature.)


I'm 100% with Stephan on this one. On those rare occasions where I've 
wanted the effect of fossil clean, I've opened a fresh working directory 
instead.


>


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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 implemented or suggestion for stash

[Stephan Beal]

On Thu, Apr 14, 2016 at 7:00 PM, Warren Young  wrote:

> On Apr 12, 2016, at 11:30 PM, Stephan Beal  wrote:
> >
> > i haven't ever bisected.
>
> Wow…
>
> I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)
>

i've just been lucky - never needed to use it to find where a particular
problem arrived :). (But that's admittedly luck, rather than any form of
skill!)


> Bisecting is most useful when you get a bug report from the field and
> can’t see from that report how any of the recent changes caused the
> failure.


See, if anyone other that myself used my software, i might have needed it
;).



> I used bisect on Fossil itself to find the regression that broke sorting
> in the Tickets view, fixed in [0e555dee6].  The problem was introduced
> about 6 months prior to the bug’s discovery.  How would you have found a
> problem like that without bisecting?
>

i'd have left it to you to find :-D!


> I suppose if you’re working on software with 100% regression test coverage,


LOL! Nope - just lucky. i was born in Las Vegas - maybe that has something
to do with it ;).


> The ability to bisect is one of the strongest arguments in favor of
> version control.
>

i admit that it's a fantastic capability, i've just never needed to use it.
(Contrast with "fossil clean" - i have Opinions about anyone other than
myself cleaning up my source trees, and simply _won't_ use that feature.)

-- 
- 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] feature implemented or suggestion for stash

[Richard Hipp]

On 4/14/16, Warren Young  wrote:
>
> I suppose if you’re working on software with 100% regression test coverage,
> such problems would never become buried in the project history: as soon as a
> change breaks things, you get told about it by the test harness.

Not so.  The better the test suite, the more you need bisect.  With a
really strong test suite what happens is that the occasional bug that
does slip in is probably something extremely subtle and it can go a
very long time (years) without being noticed.  Finding the origin of
the problem becomes very difficult without bisect.

Note that bisect can also be used to figure out when a problem was
fixed!  This happened on SQLite just moments ago.  (See
http://www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg07964.html
for the mailing list post).  The OP was concerned about SQLite not
making a wise index choice.  He sent in the database, and I noticed
that my current version of SQLite was making the right choice.  I used
bisect to figure out exactly which check-in fixed the problem, which
also revealed exactly what the problem was without me having to spend
time debugging it.

>
> The ability to bisect is one of the strongest arguments in favor of version
> control.

+1

-- 
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 implemented or suggestion for stash

[Warren Young]

On Apr 12, 2016, at 11:30 PM, Stephan Beal  wrote:
> 
> i haven't ever bisected.

Wow…

I don’t bisect every day, but when I do bisect, I bisect with Fossil. :)

Bisecting is most useful when you get a bug report from the field and can’t see 
from that report how any of the recent changes caused the failure.  So, you 
start with the last-known-good version, and quickly bisect your way toward the 
checkin that broke things.

I used bisect on Fossil itself to find the regression that broke sorting in the 
Tickets view, fixed in [0e555dee6].  The problem was introduced about 6 months 
prior to the bug’s discovery.  How would you have found a problem like that 
without bisecting?

I suppose if you’re working on software with 100% regression test coverage, 
such problems would never become buried in the project history: as soon as a 
change breaks things, you get told about it by the test harness.  But even 
Fossil, which is about as well-tested as software gets, in my experience, had 
this one slip by because there is no regression testing done on the UI code.

The ability to bisect is one of the strongest arguments in favor of version 
control.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users