[fossil-users] openssl 1.1 compatibility issue in http_ssl.c

2017-03-13 Thread Eduard 
Hi,

When upgrading to openssl 1.1, I noticed that repositories fail to sync
with "SSL: cannot connect to host hydra.ecd.space:443 (unsupported ip
family)". I found a Debian bug describing this issue[1], and Sergei
Golovan released a fix (see patch at bottom of their message in [1]).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847556#10

Best regards,
Eduard
___
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] Old fossil (1.29) accessing current fossil trunk?

2017-03-13 Thread Ross Berteig 

On 3/13/2017 8:57 AM, Richard Hipp wrote:

On 3/13/17, Stefan Bellon  wrote:

When upgrading from 1.24 to 1.29 years ago, the output of "fossil
annotate" changed and broke all our scripts (and even some customer
databases).

I expect even more incompatibilities when switching from 1.29 to 2.0
and therefore this is nothing that can be done in a few minutes.

We have to check for all the output of all fossil commands we use in
scripts whether they still produce the same output they did before.


I'm a little confused.  If you need to continue using Fossil 1.29 for
text output compatibility, then why is it a problem that you cannot
"fossil update" to the latest trunk?  After all, you won't be using
the latest trunk, right?

Also:  What can we do to help you move away from scripts that depend
on the details of command-line output and toward something that is
more likely to survive an update?  What are your scripts doing?  Would
it be better to run SQL queries directly against the repository
database?  Are new fixed-output-format commands needed in Fossil to
extract information that is important to scripts?


When fossil is configured to include JSON support it has a fossil json 
command that consumes a JSON object full of command and arguments and 
returns a JSON object of results. A similar feature is available over 
HTTP(S) through URLs beginning with /json.


Unfortunately JSON support is not configured in the default builds of 
fossil. I often turn it on for my personal builds, because I have some 
scripts that draw from the ticket system for report writing, and the 
JSON support for reading and querying tickets works quite nicely. I'd 
personally like to see the JSON support trusted enough to be on by default.


Also, not every command is available via JSON, and I suspect that there 
is no JSON equivalent to fossil annotate. If we can figure out how to 
represent the annotate/blame/praise data in JSON, then adding it should 
be possible.


--
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] Fossil 2.1 upgrade path

2017-03-13 Thread Richard Hipp 
On 3/13/17, Ross Berteig  wrote:
>
> So to move an existing project to the latest fossil after an SHA3-named
> artifact exists, it appears to be necessary to rebuild existing repos
> with version 2.0 or later so the database schema don't include a
> constraint that forbids SHA3 names.

Not, not exactly.

A rebuild is not necessary.  But you do need to access the repo once
(perhaps by running "fossil dbstat") in order to cause the minor CHECK
constraint update to occur.  Rebuild will do that, but it is more work
than is actually needed.  So, there is no harm in doing a rebuild, but
it is not strictly necessary.

-- 
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 2.1 upgrade path

2017-03-13 Thread Ross Berteig 

On 3/12/2017 10:50 AM, Richard Hipp wrote:

On 3/12/17, Piotr Orzechowski  wrote:

Can I
jump directly from 1.37 to 2.1?

Yes.  Simply download and install 2.1 and you are done.

Optional seconds step:  Type "fossil hash-policy sha3" in a check-out
directory of any repository that you want to start using SHA3 hashes.
Then next time you do a commit from that check-out, the repo will will
automatically start doing all new commits as SHA3.  If you do not care
aboud SHA1 vs SHA3, then you can safely ignore the second step.


I have a build on a x86_64 Linux box at my web host, which I 
bootstrapped on that box originally by building from one of the source 
tarballs, then cloned the fossil repo and rebuilt from the repo. My 
installed fossil was sitting at v1.36, and I'd like to bring it up to 
2.1 or later.


The other day I had updated my clone to version 2.0 and built, but had 
not installed yet. So I installed it, then attempted to update to tip of 
trunk. That failed:


[rosber15@aardwolf]$ fossil update trunk
Autosync:  http://fossil-scm.org/
Round-trips: 1   Artifacts sent: 0  received: 0
SQLITE_CONSTRAINT: abort at 14 in [INSERT INTO 
blob(rcvid,size,uuid,content)VALUES(0,-1,:uuid,NULL)]: CHECK constraint 
failed: blob

fossil: SQL error: CHECK constraint failed: blob
[rosber15@aardwolf]$

Before panicking, I did fossil rebuild and tried again, mostly because 
of what seemed like a database schema issue. Now fossil update trunk 
succeeds.


So to move an existing project to the latest fossil after an SHA3-named 
artifact exists, it appears to be necessary to rebuild existing repos 
with version 2.0 or later so the database schema don't include a 
constraint that forbids SHA3 names.


--
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] Support for commonmark markdown in fossil

2017-03-13 Thread Warren Young 
On Mar 13, 2017, at 12:57 PM, Martin S. Weber  wrote:
> 
> On 03/13/17 19:00, Warren Young wrote:
>> On Mar 13, 2017, at 10:32 AM, Natacha Porté  wrote:
>>> Or do you expect it to count parentheses and prevent you from ever
>>> linking to a URL with unbalanced parentheses?
>> 
>> Yes.  Other Markdown processors do that.
> 
> It doesn't necessarily have to count parens, in the specific case mentioned 
> by Warren opting for the longest instead of the shortest syntactically 
> correct match would do as well. In other words, use
> regexen naively, duh :)

Regex matching of URLs is difficult:

   https://mathiasbynens.be/demo/url-regex

It doesn’t seem that src/markdown.c uses regexes.  At least, I don’t see any 
“regex” or “regcomp” text in that file.

A simpler method that may also work is:

1. Count parens and don’t close the URL until the paren count goes to 0.  (Open 
paren = +1, closed = -1.)

2. …unless you hit a whitespace, EOL, or other thing after a closed paren that 
clearly means the URL is finished.

That would let you have unbalanced parens, too.
___
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] Support for commonmark markdown in fossil

2017-03-13 Thread David Vines 

On 13/03/2017 15:50, Warren Young wrote:


A related wish that comes up here now and then is some kind of pretty-printer 
support, so that common programming languages are colored nicely.  Google’s 
code-prettify JS library would work for this:

https://github.com/google/code-prettify



Admittedly it only does syntax colouring (and not formatting), but I found the instructions at the 
link below of how to add syntax colouring to a repository pretty straight forward to follow:


https://www.fossil-scm.org/xfer/wiki?name=Cookbook#source-hilight

Dave
___
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] Support for commonmark markdown in fossil

2017-03-13 Thread Martin S. Weber 

On 03/13/17 19:00, Warren Young wrote:

On Mar 13, 2017, at 10:32 AM, Natacha Porté  wrote:

Or do you expect it to count parentheses and prevent you from ever
linking to a URL with unbalanced parentheses?


Yes.  Other Markdown processors do that.


It doesn't necessarily have to count parens, in the specific case 
mentioned by Warren opting for the longest instead of the shortest 
syntactically correct match would do as well. In other words, use

regexen naively, duh :)
___
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] Support for commonmark markdown in fossil

2017-03-13 Thread Warren Young 
On Mar 13, 2017, at 10:32 AM, Natacha Porté  wrote:
> 
> on Monday 13 March 2017 at 09:50, Warren Young wrote:
>> I have found bugs in Fossil’s Markdown implementation.  For example, it 
>> doesn’t deal properly with hyperlinks to Wikipedia documents that end in a 
>> parenthesis, as when the Wikipedia topic needs disambiguation:
>> 
>>   I like [Fossil](https://en.wikipedia.org/wiki/Fossil_(software))!
> 
> ...
> Or do you expect it to count parentheses and prevent you from ever
> linking to a URL with unbalanced parentheses?

Yes.  Other Markdown processors do that.  Stack Exchange and GitHub, for two.

https://gist.github.com/wyoung/8cb1b16f128c7e6050fd71a3040488ee
___
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] Support for commonmark markdown in fossil

2017-03-13 Thread Natacha Porté 
Hello,

on Monday 13 March 2017 at 09:50, Warren Young wrote:
> I have found bugs in Fossil’s Markdown implementation.  For example, it 
> doesn’t deal properly with hyperlinks to Wikipedia documents that end in a 
> parenthesis, as when the Wikipedia topic needs disambiguation:
> 
>I like [Fossil](https://en.wikipedia.org/wiki/Fossil_(software))!

I'm not sure I really understand the problem here. The links ends at the
first unescaped closing parenthesis, so I would expect anyone wanting it
to be part of the URL to escape it, just like any literal star or
underscore or bracket or backtick in the text.

Or do you expect it to count parentheses and prevent you from ever
linking to a URL with unbalanced parentheses?


Hoping this helps,
Natacha
___
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] Old fossil (1.29) accessing current fossil trunk?

2017-03-13 Thread Richard Hipp 
On 3/13/17, Stefan Bellon  wrote:
>
> When upgrading from 1.24 to 1.29 years ago, the output of "fossil
> annotate" changed and broke all our scripts (and even some customer
> databases).
>
> I expect even more incompatibilities when switching from 1.29 to 2.0
> and therefore this is nothing that can be done in a few minutes.
>
> We have to check for all the output of all fossil commands we use in
> scripts whether they still produce the same output they did before.
>

I'm a little confused.  If you need to continue using Fossil 1.29 for
text output compatibility, then why is it a problem that you cannot
"fossil update" to the latest trunk?  After all, you won't be using
the latest trunk, right?

Also:  What can we do to help you move away from scripts that depend
on the details of command-line output and toward something that is
more likely to survive an update?  What are your scripts doing?  Would
it be better to run SQL queries directly against the repository
database?  Are new fixed-output-format commands needed in Fossil to
extract information that is important to scripts?
-- 
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] Support for commonmark markdown in fossil

2017-03-13 Thread Warren Young 
On Mar 11, 2017, at 7:07 AM, Mark Janssen  wrote:
> 
> the fossil markdown support is fairly limited (for example there are no code 
> blocks)

We must have different definitions of “code block.”

This is a Fossil wiki page with a very large code block down at the end:

https://tangentsoft.com/pidp8i/wiki?name=PEP001.PA

And it’s an interesting programming story besides, IMHO. :)

That code block — the amber-on-black box — is simply the boxed text you see 
indented four spaces, the same as specified by CommonMark.

Fossil also allows  and  in Markdown, if you want more control over 
what you get in the HTML output.

Fossil *doesn’t* support this “fenced code block” feature I see in CommonMark.  
Is that what you wanted?  I assume that has value for some indenting or quoting 
reason, but I have yet to find the older indented code block style unsuitable.

A related wish that comes up here now and then is some kind of pretty-printer 
support, so that common programming languages are colored nicely.  Google’s 
code-prettify JS library would work for this:

https://github.com/google/code-prettify

I have found bugs in Fossil’s Markdown implementation.  For example, it doesn’t 
deal properly with hyperlinks to Wikipedia documents that end in a parenthesis, 
as when the Wikipedia topic needs disambiguation:

   I like [Fossil](https://en.wikipedia.org/wiki/Fossil_(software))!

The URL is missing the trailing closing paren and an extra closing paren shows 
up in the HTML rendered output.

It would also be nice to have Markdown support in tickets.  I write Markdown 
text faster than I write Wiki formatted text.

> I have made a version of fossil which supports the commonmark markdown format

If it’s simply “stronger” than the current Markdown implementation on the 
common subset of the two Markdown flavors, I’m in favor of the change.  I don’t 
mind going back and tweaking my Markdown text to format correctly under the new 
system, especially if the differences amount to removing workarounds for 
Fossil’s current Markdown rendering engine.

> - (Maybe) add a repo wide markdown flavour setting

That sounds necessary, at least through the transition period, for much the 
same reason we how have “fossil set hash-policy”.  

If I update my local Fossil with your version and say “fossil ui” in a repo 
made by someone who doesn’t use a Fossil binary with your Markdown engine, the 
Markdown might not render properly if my Fossil doesn’t also know how to use 
the “legacy” rendering engine.

> would there be any interest in adding commonmark support?  

For now, I’m torn until you give me better examples than “no code block 
support.” :)
___
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] Old fossil (1.29) accessing current fossil trunk?

2017-03-13 Thread Stefan Bellon 
Sadly it is not that simple.

When upgrading from 1.24 to 1.29 years ago, the output of "fossil
annotate" changed and broke all our scripts (and even some customer
databases).

I expect even more incompatibilities when switching from 1.29 to 2.0
and therefore this is nothing that can be done in a few minutes.

We have to check for all the output of all fossil commands we use in
scripts whether they still produce the same output they did before.

But ok, then we know why our automated tests do not work any more.

Greetings,
Stefan


On Mon, 13 Mar, Richard Hipp wrote:

> On 3/13/17, Stefan Bellon  wrote:
> >
> > Is this (old) version not able to work with current trunk anymore?
> > Do we have to upgrade to 2.0 or 2.1?
> >  
> 
> Correct.  As of check-in
> https://www.fossil-scm.org/fossil/info/7815d015f3b5a663 (2017-03-10)
> the self-hosting Fossil repository now contains artifacts named by
> SHA3 hashes, and Fossil version 2.0 or later is necessary to
> understand those now hashes.
> 
> The upgrade is simple.  Just replace your current fossil executable
> with a new one.  Everything should work exactly as it did before.
> There are no incompatibilities.  The only difference is that Fossil
> 2.1 will read and write the latest repositories whereas Fossil 1.x
> will not.
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org


-- 
Stefan Bellon
___
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] Old fossil (1.29) accessing current fossil trunk?

2017-03-13 Thread Richard Hipp 
On 3/13/17, Stefan Bellon  wrote:
>
> Is this (old) version not able to work with current trunk anymore? Do
> we have to upgrade to 2.0 or 2.1?
>

Correct.  As of check-in
https://www.fossil-scm.org/fossil/info/7815d015f3b5a663 (2017-03-10)
the self-hosting Fossil repository now contains artifacts named by
SHA3 hashes, and Fossil version 2.0 or later is necessary to
understand those now hashes.

The upgrade is simple.  Just replace your current fossil executable
with a new one.  Everything should work exactly as it did before.
There are no incompatibilities.  The only difference is that Fossil
2.1 will read and write the latest repositories whereas Fossil 1.x
will not.

-- 
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] Old fossil (1.29) accessing current fossil trunk?

2017-03-13 Thread Stefan Bellon 
Hi all,

recently when updating our fossil trunk workspace with an old copy of
fossil (1.29) we are getting error messages as follows:

$ fossil version
This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC
$ fossil update
Autosync:  http://www.fossil-scm.org/
Round-trips: 1   Artifacts sent: 0  received: 0
unknown command: [igot]

Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 368 bytes sent, 1088 bytes received
Autosync failed
Cannot proceed with update

Is this (old) version not able to work with current trunk anymore? Do
we have to upgrade to 2.0 or 2.1?

Greetings,
Stefan

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