On Feb 26, 2017, at 1:45 PM, Richard Hipp wrote:
>
> initial implementation will support SHA1 and SHA3-228
224.
> Other hash algorithms may be supported
> in future releases as long as each hash algorithm has a unique hash
> length
That seems brittle. There are many fewer hash sizes than hash
On Feb 27, 2017, at 11:59 AM, Richard Hipp wrote:
>
> nobody has yet devised two files that generate identical SHA1 and MD4
> hashes at the same time!
But Joux proved it not especially difficult in this paper, which came up in one
of the earlier SHA-1 threads, to which you responded something l
On Feb 28, 2017, at 8:11 AM, Richard Hipp wrote:
>
> (3) All new content added to the repository (for example by "fossil
> commit") uses a SHA3-256 hash.
That is a brave step, one I resisted suggesting, but it’s probably for the
best. Defaults matter. If the default is SHA-1, we’ll still be l
On Feb 28, 2017, at 8:19 AM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp wrote:
>>
>> (4) There are no hash options. You cannot choose to use any hash
>> algorithm other than SHA3-256 for new content.
>>
>> (6) The only complication to upgrading is that you need to update all
>> of your
On Feb 28, 2017, at 9:17 AM, Richard Hipp wrote:
>
> This morning I was thinking of using SHA3-256. But after looking at a
> bunch of hashes on-screen, and seeing how long they are, I'm inclined
> now to go with the shorter SHA3-224.
Can you just look at $COLUMNS, $(tput cols), or getmaxyx(3)?
On Feb 28, 2017, at 2:08 PM, Richard Hipp wrote:
>
> On 2/28/17, Warren Young wrote:
>>
>>> Then after a month or so we can release Fossil 2.1, in which all new
>>> content is always SHA3.
>>
>> If there’s going to be a transition time, I think it wo
On Feb 28, 2017, at 6:49 PM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp wrote:
>>
>> Should the SHA3 hashes be SHA3-224 or
>> SHA3-256? In my view, the extra computation and storage overhead for
>> SHA3-256 is minimal and should not present a barrier. However, the
>> extra 8 characters
On Feb 28, 2017, at 6:50 PM, Warren Young wrote:
>
> ...for those who run their terminals at > 80 columns
If you go with that, you might want to call isatty(stdout) in case fossil is
being run in a pipeline, so code that tries to parse a hash out of the command
gets the full lengt
On Mar 1, 2017, at 3:35 PM, Richard Hipp wrote:
>
> The trunk check-in of Fossil
> (https://www.fossil-scm.org/fossil/timeline?c=trunk) is the release
> candidate for version 2.0. I plan to do the version 2.0 release with
> 48 hours. Please test it out, as you are able.
Is the server under rea
On Mar 1, 2017, at 4:29 PM, Richard Hipp wrote:
>
> On 3/1/17, Warren Young wrote:
>>
>> Is the server under really heavy load at the moment? I’ve got a clone from
>> http://www.fossil-scm.org that’s been running for several minutes now.
>> Updates normall
Would someone add this to Makefile.in, please:
reconfig:
@AUTOREMAKE@
ifeq ($(findstring clean,$(MAKECMDGOALS)),)
Makefile: @srcdir@/Makefile.in @srcdir@/auto.def
@AUTOREMAKE@ && $(MAKE)
I believe I got it from the autosetup docs somewhere.
This is valuable for those of us w
On Mar 1, 2017, at 4:39 PM, Warren Young wrote:
>
> Makefile: @srcdir@/Makefile.in @srcdir@/auto.def
You should also add the names of all other *.in files to that line, so that
when they change, you reconfigure the software and re-generate the output files
for the *.in files.
I’m br
On Mar 6, 2017, at 12:21 AM, Tino Lange wrote:
>
> Now that Fossil 2.0 is out I wonder if line 42 here:
> https://www.fossil-scm.org/index.html/artifact?ln=on&name=f23144d54a286503
> should be turned to 1 to change the mv-and-rm behaviour?
While I would like to see that behavior become the defau
On Mar 13, 2017, at 6:13 PM, Richard Hipp wrote:
>
> On 3/13/17, Ross Berteig wrote:
>> I seem to have the test suite bee in my bonnet this week.
>
> I, for one, am hoping that bee hangs around :-)
Can we get him a hat of office or something? :)
___
On Apr 4, 2017, at 7:33 AM, Richard Hipp wrote:
>
> They are now down to $40 USD to purchase the domain.
That’s cheap, as squatted-upon .coms go. :)
> adding fossil-scm.com is just
> one more DNS entry to maintain.
Yup. You’ll burn through another $40 soon enough that way.
> I am open to acq
On Apr 14, 2017, at 5:09 PM, Ross Berteig wrote:
> I've checked it in on the glob-docs branch until it has been read by at least
> one more pair of eyes.
How about two pair? (Because foureyes. Ahahah.)
Go put your Nomex underwear on; I’m a brutal copy editor.
Complaints, comments, and consi
On Apr 17, 2017, at 7:27 PM, Ross Berteig wrote:
>
> On 4/14/2017 9:15 PM, Warren Young wrote:
>> On Apr 14, 2017, at 5:09 PM, Ross Berteig wrote:
>> 1. It doesn’t tell you that globs and regexes are not the same thing.
>
> True, it probably should.I'll work t
On Apr 18, 2017, at 1:55 PM, Ross Berteig wrote:
>
> On 4/17/2017 8:24 PM, Warren Young wrote:
>> I wouldn’t say that regexes and globs are *related*
> They are related because they are both notations for describing patterns in
> text.
I’m objecting to the genealogical
I’ve checked in my new Platform Quirks section.
Oddly, I noticed only after doing the first checkin that it used my local user
name (tangent) as the user name on the remote (i.e. fossil-scm.org) repository.
I was able to fix it for a second clean-up checkin by re-cloning under my new
wyoung use
On Jun 6, 2017, at 7:29 AM, Stephan Beal wrote:
>
> i just stumbled across this and figured it might someday become a bug
> report against fossil:
>
> https://eclecticlight.co/2017/04/06/apfs-is-currently-unusable-with-most-non-english-languages/amp/
That article is written by a proponent of Un
On Jun 20, 2017, at 8:48 AM, Richard Hipp wrote:
>
> Review and criticism of this change is welcomed.
Since updating and installing it, I’m getting occasional aborts in relatively
simple tasks like fossil diff and fossil checkin.
fossil diff with uncommitted changes doesn’t give any diagnostic
On Jun 21, 2017, at 5:05 AM, Richard Hipp wrote:
>
> On 6/20/17, Warren Young wrote:
>>
>> Since updating and installing it, I’m getting occasional aborts in
>> relatively simple tasks like fossil diff and fossil checkin.
>
> Are these reproducible?
By “oc
On Jun 22, 2017, at 6:23 AM, Warren Young wrote:
>
>> Can you provide a test case?
>
> I can’t share the repo, but I’ve dropped an abort() in front of the line I
> referenced in the prior email, so sometime today I should have a backtrace
> for you.
Well, here it is, but
On Jun 22, 2017, at 8:37 AM, Warren Young wrote:
>
> On Jun 22, 2017, at 6:23 AM, Warren Young wrote:
>>
>>> Can you provide a test case?
I’ve got a much better test case now as well as a potential solution. It turns
out that the problem has nothing to do with Fossi
On Jun 23, 2017, at 10:09 AM, Richard Hipp wrote:
>
> Maybe Fossil needs to disable the stack and heap size limits prior to
> calling exec() or fork() and then reenable the limits afterwards?
Maybe. The current design is a bit like moralizing: Fossil has selected a
limit it is willing to live
On Jun 23, 2017, at 11:09 AM, Warren Young wrote:
>
> I’ve elaborated the test program to do a binary search for the exact limit,
> and it’s a smidge over 4 MiB here: 4210688 bytes.
I’ve posted that test program to Stack Overflow along with a question about how
(or whether!) we can
On Jun 23, 2017, at 12:16 PM, Warren Young wrote:
>
> I’ve posted that test program to Stack Overflow…
This Internet thing is pretty great. Just 3 minutes after posting, someone has
already come up with a better answer, which may be the best solution: call
getrlimit(RLIMIT_STACK) on
On Jun 24, 2017, at 8:09 AM, Richard Hipp wrote:
>
> This should be implemented on trunk. Please try it out and let me
> know how it works.
Yep, that’s got it, thanks!
Incidentally, I ran the test from the Stack Overflow post on a nearly-untouched
CentOS 7 VM over the weekend, and it required
On Jun 30, 2017, at 11:42 AM, Richard Hipp wrote:
>
> Trunk now contains a "Security Audit" page whose purpose is to review
> the countless settings and configuration options in Fossil and try to
> sniff out undesirable misconfigurations.
Yay!
Does it automate the permission sanity checks I pos
On Jul 1, 2017, at 1:50 PM, Richard Hipp wrote:
>
> I propose to release Fossil 2.3 on it's 10th birthday, which is coming
> up later this month, 2017-07-21. See
> https://www.fossil-scm.org/fossil/timeline?a=1970-01-01&y=ci&n=10
>
> It is unlikely that SQLite 3.20.0 will be released by then, s
On Jul 6, 2017, at 8:22 AM, Richard Hipp wrote:
>
> Question 1: "References" seems like the wrong section label. But I
> cannot come up with anything better. I also tried "Referenced By",
> but that seems even worse. Suggestions?
“Cited by”?
> Question 2: Should these backlinks also be sho
On Jul 31, 2017, at 2:36 PM, Richard Hipp wrote:
>
> I still don't know what to call it, however….
How about “apropos”?
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On Aug 11, 2017, at 9:41 AM, Richard Hipp wrote:
>
> I am open to arguments to the contrary, if you feel
> differently.
It would be an excuse to push out the final SQLite 3.20 version...
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
ht
The “unversioned” lines on this page make no sense:
https://tangentsoft.com/pidp8i/stat
Look first at the fifth line: how can the unversioned files occupy 484% of the
repository space?
If you take the “4 files” link from that line, it totals to 15.3 MB, but on
line 3 of the /stat output,
On Oct 1, 2017, at 8:31 PM, Richard Hipp wrote:
>
> Fixed now, I think.
Installed and verified, thank you!
> The problem was that fsize would sometimes get
> changed during the computation of the compression ratio, which in turn
> was throwing off the unversioned file size percentage.
Ah. In
I’ve just checked in a series of changes on the new wy-autoreconfig branch
which I’d like y’all to try out and hopefully enjoy, so that it gets merged
into trunk.
http://fossil-scm.org/index.html/timeline?r=wy-autoreconfig
It solves several problems:
1. If you touch any of the autosetup fil
On Oct 11, 2017, at 8:32 AM, Andy Bradford
wrote:
>
> *** Parse error in /home/amb/download/tarballs/fossil: Missing dependency
> operator (Makefile:70)
> *** Parse error: Need an operator in 'endif' (Makefile:74)
My change on line 70 of Makefile is a GNU make conditional. I’m guessing
you’r
On Oct 11, 2017, at 2:45 PM, Andy Bradford wrote:
>
> BSD make does have conditionals, but clearly not using the syntax that
> was there.
It’s more than that. There are two other GNU make-isms in that one line.
> you want a Makefile
> target that will rebuild the Makefile if it's out of dat
On Oct 20, 2017, at 8:52 AM, Richard Hipp wrote:
>
> part of the /juvlist output
I like the idea, though instead of adding another top-level URL, why not sniff
the Accept HTTP header to decide whether to return HTML or JSON?
I haven’t looked at the code for your Downloads page, but it’s trivia
On Nov 3, 2017, at 7:55 AM, Zakero wrote:
>
> Looking at this from a "skin" point of view, if a someone needs to include
> a script like jQuery somewhere in then that skin would also need to
> provide CSP support. May or may not be a reasonable expectation.
I believe your worry only comes up i
> On Nov 3, 2017, at 6:42 AM, Richard Hipp wrote:
>
> Option 1:
...
> And when new capabilities come out (such
> as CSP) it requires existing repositories to edit their header
> templates in order to insert the new information.
The current skin CSS diffing mechanism shows the way out of this
On Dec 4, 2017, at 3:07 AM, Johan Kuuse wrote:
>
> src/file.c:65
>
>
> #define RepoFILE 1/* Follow symlinks if*f* allow-symlinks is OFF */
>
> Should be:
>
> #define RepoFILE 1/* Follow symlinks if allow-symlinks is OFF */
That might not be a typo. “iff” is mathematical shorthan
Not long before all of this skin shakeup occurred, drh expressed interest in
integrating my Amber VT skin into the Fossil as one of the stock skins.
Nothing came of it, so I don’t know whether:
1. Y’all really don’t like it and were just poking fun. (I can understand
that. The skin definitely
On Dec 22, 2017, at 4:44 PM, Warren Young wrote:
>
> I’m announcing it here.
…and in retrospect, I am also failing to include the link. Sigh. :)
https://tangentsoft.com/pidp8i/setup_skinedit?w=0&sk=1
https://tangentsoft.com/pidp8i/setup_skinedit?w=2&sk=1
https://t
On Jan 16, 2018, at 2:38 PM, Richard Hipp wrote:
>
> I don't think there is anything like this in Fossil. Should we add it?
As a Vim guy, it doesn’t much appeal to me.
I mean that at a deeper level than the trivial: even if there were a way to run
a Fossil log command on a marked region in Vi
I think I’ve solved the “2.0.1.187” issue. For reference, here’s the symptom:
$ fossil up
Autosync: https://fossil-scm.org
Round-trips: 3 Artifacts sent: 0 received: 2
Pull done, sent: 1326 received: 3599 ip: 2.0.1.187
According to another post on this topic, “2.0.1.187” is
My vague understanding of Europe’s new GDPR legislation is that email addresses
and — shockingly — IP addresses are considered “personal information” and thus
Europeans will now have a right to insist that their data be removed on demand
from any web service that stores these things.
If that
On Jun 20, 2018, at 1:56 PM, Richard Hipp wrote:
>
> On 6/20/18, Andy Goth wrote:
>> Check-in ccf50f0619 adds email.c to main.mk, but there is no such file. Did
>> you (drh) mean to do "fossil add"?
>>
>> For now I'm having to stick with 7001228a09.
>
> Thanks. Should be fixed now.
Except no
On Jun 20, 2018, at 3:44 PM, Warren Young wrote:
>
> Except now it has mange. :)
Some more substantial observations:
1. Shouldn’t the copyright year at the top be 2018?
2. The literal popen() call down in the handler for email-send-method == “pipe”
might be insufficient for some situ
On Jun 20, 2018, at 4:25 PM, Richard Hipp wrote:
>
> On 6/20/18, Warren Young wrote:
>> Two options:
>>
>> a. Just say that mailx isn’t allowed, because it doesn’t have the correct
>> interface.
>>
>> b. Add a printf-like syntax for building the comma
On Jun 20, 2018, at 5:38 PM, Warren Young wrote:
>
> that means at least three different command-line MTAs.
s/MTA/MUA/
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
On Jul 26, 2018, at 7:28 PM, Ryan Noll (Mailing List)
wrote:
>
> I upgraded via source to 2.6 (fd3198322a 2018-07-25 13:20:15 UTC)
Unless you need one of the changes between the 2.6 release made in early May
and the current trunk, I’d recommend staying on release versions until the
current tr
On Jul 31, 2018, at 7:47 AM, Richard Hipp wrote:
>
> * Messages are organized into threads.
Will this work be reflected in part back into the ticketing system? Few
tickets in my repos get enough replies for this to be a noteworthy improvement
over the existing unthreaded ticket replies, but
On Jul 31, 2018, at 7:47 AM, Richard Hipp wrote:
>
> The intent is to replace this mailing list
Are you also going to import all the old content, so that people can clone the
forum repo — assuming you still plan to keep the forum and code as separate
repos — and get a locally-searchable archiv
On Nov 19, 2018, at 10:05 PM, Stephan Beal wrote:
>
> Is fossil-dev still the preferred place for dev-specific topics or is the
> forum preferred for that?
I’d use the forum.
I don’t think there ever was enough traffic to justify two lists in the first
place, for a project where its developmen
On Nov 20, 2018, at 5:43 AM, Stephan Beal wrote:
>
> It seems to me (based solely off of the docs, rather than understanding the
> implementation) that that could be implemented much more simply:
>
> proc check-function-in-lib {function libs {otherlibs {}}} {
>set _LIBS [get-define LIBS]
>
56 matches
Mail list logo
