Re: [fossil-users] fossil server gives 403 after upgrade to apache 2.4

2017-02-17 Thread Warren Young 
On Feb 17, 2017, at 4:05 AM, Benedikt Ahrens  wrote:
> 
> after upgrade from apache2.2 to apache2.4, my fossil cgi server gives a
> 403 error.

Did you read the upgrade guide?

   https://httpd.apache.org/docs/2.4/upgrading.html

Apache 2.4 changes a bunch of things in the way permissions are handled, which 
probably explains your symptom.

This is not a Fossil problem.
___
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] fast-import crash (mark not declared)

2017-02-17 Thread Rafal Bisingier 
Hi,

On 2017-02-17 at 07:37 -0500
Richard Hipp  wrote:

>On 2/17/17, Rafal Bisingier  wrote:
>>
>> Out of curiosity: what will happen, when commited parent have timestamp
>> far away in future?  
>
>You could move the defective commit onto a branch (a branch named
>"mistake" is a popular choice). Or you could change the date on the
>defective commit.

Thank you for quick answer. Again. ;-)

-- 
Greetings
Rafal Bisingier
___
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] fast-import crash (mark not declared)

2017-02-17 Thread Richard Hipp 
On 2/17/17, Rafal Bisingier  wrote:
>
> Out of curiosity: what will happen, when commited parent have timestamp
> far away in future?

You could move the defective commit onto a branch (a branch named
"mistake" is a popular choice). Or you could change the date on the
defective commit.
-- 
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] fast-import crash (mark not declared)

2017-02-17 Thread Rafal Bisingier 
Hi,

On 2017-02-17 at 07:03 -0500
Richard Hipp  wrote:

>On 2/17/17, Richard Hipp  wrote:
>> On 2/17/17, Rafal Bisingier  wrote:  
>>>
>>> Shouldn't Fossil at least warn user trying to commit a child wit
>>> timestamp earlier than parent?  
>>
>> I think it does that, now.  
>
>Confirmed:  That fix went in 7 years ago:
>https://www.fossil-scm.org/fossil/info/8fdac87b688c3ea0

It's even harder than I proposed - abort instead of warning. Thank you
for confirmation.

Out of curiosity: what will happen, when commited parent have timestamp
far away in future? Do we have to skew our clock to commit a child? Or
is there some mechanism to get around it without breaking next commit?

-- 
Greetings
Rafal Bisingier
___
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] fast-import crash (mark not declared)

2017-02-17 Thread Richard Hipp 
On 2/17/17, Richard Hipp  wrote:
> On 2/17/17, Rafal Bisingier  wrote:
>>
>> Shouldn't Fossil at least warn user trying to commit a child wit
>> timestamp earlier than parent?
>
> I think it does that, now.

Confirmed:  That fix went in 7 years ago:
https://www.fossil-scm.org/fossil/info/8fdac87b688c3ea0
-- 
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] fossil server gives 403 after upgrade to apache 2.4

2017-02-17 Thread Benedikt Ahrens 
Addendum: I probably took the original configuration from [1], which
would need an update for apache2.4.

[1] https://www.fossil-scm.org/xfer/wiki?name=Cookbook#CGI


On 02/17/2017 12:05 PM, Benedikt Ahrens wrote:
> Hi,
> 
> after upgrade from apache2.2 to apache2.4, my fossil cgi server gives a
> 403 error. It worked fine with apache2.2.
> The rest of the website works after the upgrade, both over http and https.
> 
> The apache error log states:
> [Fri Feb 17 12:00:41.004779 2017] [authz_core:error] [pid 1681] [client
> 90.105.173.97:55792] AH01630: client denied by server configuration:
> /home/user/cgi-bin/r.cgi
> 
> The VirtualHost config is posted below.
> 
> Any help for solving this particular problem, or for improving the setup
> more generally, would be appreciated.
> 
> Best,
> Benedikt
> 
> 
> 
> 
> ServerAdmin ***
> ServerName ***
> 
> DirectoryIndex index.html index.php
> DocumentRoot /home/user/public_html
> 
> Options +FollowSymLinks -Indexes
> AllowOverride AuthConfig
> Require all granted
> 
> 
> ScriptAlias /cgi-bin/ /home/user/cgi-bin/
> 
> AllowOverride None
> Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
> # Order allow,deny
> # Allow from all
> Require all granted
> 
> 
> #   SSL Engine Switch
> SSLEngine on
> 
> SSLCertificateFile /etc/ssl/private/cert.ssl
> 
> ErrorLog /home/user/apache-logs/error.log
> 
> # Possible values include: debug, info, notice, warn, error, crit,
> # alert, emerg.
> LogLevel warn
> 
> CustomLog /home/user/apache-logs/access.log combined
> 
> 
> 
> ___
> 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] How to use triggers

2017-02-17 Thread Zoltán Kócsi 
On Thu, 16 Feb 2017 21:14:22 -0700
Warren Young  wrote:

> On Feb 16, 2017, at 6:39 PM, Zoltán Kócsi 
> wrote:
> > 
> > The itch I want to scratch is what I described: automated
> > generation of binaries and documentation on the server at certain
> > points in time. 
> 
> See attached existence proof. :)
> [...]

Brilliant!

Thanks!

Zoltan
___
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] fast-import crash (mark not declared)

2017-02-17 Thread Petr Ovtchenkov 
On Fri, 17 Feb 2017 00:04:29 -0600
Artur Shepilko  wrote:

> ... 
> I just realized that the check-in date may be altered via "fossil
> amend --date"  or from UI via check-in's edit submenu.
> This will add the tag "date=" and update the check-ins MTIME.
> 
> Looks like both timeline and export indeed pick up the updated MTIME.
> 
> I looked up the sqlite's cases that crashed export (655991ec8a781d67,
> 1ef0dc9328f47506) and both seem to have a corrected date tag, yet the
> corresponding event.MTIME is not updated, i.e. MTIME=OTIME. That's why
> this had no expected effect. I guess, it's on purpose as you
> mentioned, for testing.

If I understand correctly, objects graph depends upon wall time, right?

If so, this looks as serious defect in design.

--

  WBR,

- ptr


___
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] fast-import crash (mark not declared)

2017-02-17 Thread Rafal Bisingier 
Hi

On Fri, 17 Feb 2017 at 06:07 -0500
Richard Hipp  wrote:

> On 2/17/17, Rafal Bisingier  wrote:
> >
> > Shouldn't Fossil at least warn user trying to commit a child wit
> > timestamp earlier than parent?  
> 
> I think it does that, now.  The timewarps all happened a while ago.

Oh, then sorry for the noise... ;-)

-- 
Greetings
Rafal Bisingier
___
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] fast-import crash (mark not declared)

2017-02-17 Thread Richard Hipp 
On 2/17/17, Rafal Bisingier  wrote:
>
> Shouldn't Fossil at least warn user trying to commit a child wit
> timestamp earlier than parent?

I think it does that, now.  The timewarps all happened a while ago.

-- 
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] fossil server gives 403 after upgrade to apache 2.4

2017-02-17 Thread Benedikt Ahrens 
Hi,

after upgrade from apache2.2 to apache2.4, my fossil cgi server gives a
403 error. It worked fine with apache2.2.
The rest of the website works after the upgrade, both over http and https.

The apache error log states:
[Fri Feb 17 12:00:41.004779 2017] [authz_core:error] [pid 1681] [client
90.105.173.97:55792] AH01630: client denied by server configuration:
/home/user/cgi-bin/r.cgi

The VirtualHost config is posted below.

Any help for solving this particular problem, or for improving the setup
more generally, would be appreciated.

Best,
Benedikt




ServerAdmin ***
ServerName ***

DirectoryIndex index.html index.php
DocumentRoot /home/user/public_html

Options +FollowSymLinks -Indexes
AllowOverride AuthConfig
Require all granted


ScriptAlias /cgi-bin/ /home/user/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
# Order allow,deny
# Allow from all
Require all granted


#   SSL Engine Switch
SSLEngine on

SSLCertificateFile /etc/ssl/private/cert.ssl

ErrorLog /home/user/apache-logs/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /home/user/apache-logs/access.log combined



___
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] fast-import crash (mark not declared)

2017-02-17 Thread Rafal Bisingier 
Hi

On Thu, 16 Feb 2017 at 14:15 -0800
Ross Berteig  wrote:

> Sure, we'd all love it if everyone kept their clocks in sync, but in the real 
> world skew is simply going to happen. In the absence of a central server to 
> provide the authoritative time stamp, a DVCS like both Fossil and Git has no 
> real choice other than to trust the time provided by each local machine as 
> authoritative enough to document each commit.
> 
> If commits from each user of a project end up lined up in order on the 
> timeline, that is just a happy side effect of people keeping their clocks 
> synchronized.
> 
> Having a parent committed after a child does look odd, but I think it has to 
> be simply accepted as part of the record, warts and all, of the work on the 
> project.

Shouldn't Fossil at least warn user trying to commit a child wit
timestamp earlier than parent? I suppose that in the moment of commit
fossil is able to check this two timestamps (system time and ts of
parent checkin) and compare it? I'd even say that in case of local
time misconfiguration (when commiting child will end up with earlier
timestamp than it's parent) it's possible to semi-automagically "fix"
this by setting "computed timestamp" a the new commit timestamp. or
better by simply executing what "fossil amend --date" do.

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