Re: [fossil-users] Python bindings to Fossil?

[Joe Prostko]

On Fri, Jan 8, 2016 at 12:01 PM, Tomek Kott 
wrote:

> A year and a half ago, there was some discussion on creating some python
bindings for Fossil/libfossil:
http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg18153.html.
Does anyone know if that happened or where they might reside? My google-fu
is failing me.

Your Google-Fu isn't failing you.  Basically, I got stalled on that before
I even started.  My work life kind of took another direction shortly after
that post, and well, as a result, my spare time is way more limited than I
want it to be.

While I'd still like to see it happen (whether it's me or somebody else
that does the work), I definitely won't have time to take an honest look at
this any time soon.


- joe
___
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] Veracity Version control

[Joe Prostko]

On Tue, Mar 10, 2015 at 12:55 PM, jungle Boogie jungleboog...@gmail.com
wrote:

 Has anyone ever used Veracity?

I used it very briefly, but ended up going to Fossil.  The one guy behind
it also wrote a book about VCSs called Version Control By Example 
http://ericsink.com/vcbe/ that compares a given situation (team working on
files, merges, conflicts/resolution, etc.) with each different VCS and how
they compare.  It also gives a lot of VCS theory about how they work and
common terminology.  Fossil is mentioned in one sentence, basically saying
it is interesting with new ideas.

I think Veracity could have gotten a decent amount of traction if it wasn't
essentially abandoned, but as you mentioned, it seems like the project is
mostly or entirely dead at this point.

- joe
___
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] Timeline graph display options

[Joe Prostko]

On Mon, Mar 9, 2015 at 11:06 PM, Richard Hipp d...@sqlite.org wrote:

 Which timeline graph do you prefer:

 (1) https://www.fossil-scm.org/fossil/timeline?y=cinomo=0
 (2) https://www.fossil-scm.org/fossil/timeline?y=cinomo=1

I personally prefer 2.  Initially 1 looks more aesthetically pleasing, but
when shown the other examples, it simply looks too busy.  Also, I think the
EE part of me sees the examples in 2 and they remind me of circuit nodes,
and therefore they are easily understood.  That may not apply to everyone
though.

To summarize, I prefer 2.

- joe
___
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 1.31 directory name

[Joe Prostko]

On Sat, Mar 7, 2015 at 6:51 PM, Andy Goth andrew.m.g...@gmail.com wrote:

 Fossil 1.31 has been published to the SlackBuild website.

 http://slackbuilds.org/repository/14.1/development/fossil/

Very cool.  I still didn't get around to making the Haiku packages yet,
even though the build recipe has existed since the day 1.31 came out, I
think.  We don't have an automated builder yet, and well, I haven't gotten
around to creating packages for our three main architectures yet.  I'm
hoping to get that done this weekend.

- joe
___
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 source download naming scheme

[Joe Prostko]

On Tue, Feb 24, 2015 at 3:11 PM, Richard Hipp d...@sqlite.org wrote:
 On 2/24/15, robotanarchy robotanar...@bingo-ev.de wrote:
 I'd replace the underscore with a dot, so it becomes

   fossil-1.31.tar.gz

 ..but other than that, that's my point.

 Can you guys do that?


 We can call things whatever we want.  It's just a name.

 The question is Why?.

 Fossil's trunk is usually stable enough for everyday use.  Indeed, the
 self-hosting server for Fossil, as well as the repos for SQLite and
 Tcl/Tk are all usually running from the latest trunk, or something
 close to that.  The releases are not somehow more stable.  They are
 merely snapshots that provide convenient download points for users.

No argument from me there.

 So it seems like having dates on the download would be more meaningful
 than having a made-up version number.  No?  With a date, at least you
 know about how old the code is.  What information does a made-up
 version number provide?  How is that better than a date?

I think this is mostly handy for packagers, where it's easier to write
a packaging script knowing the downloaded file will be
somepieceofsoftware-1.2.3.tar.gz, which then extracts out to
somepieceofsoftware-1.2.3.  It is mostly a matter of following
convention though used with most other software, as I admit I
personally don't care at all what the filename is and what it extracts
to, as long as the method is consistent (or mostly consistent) from
release to release.  That said, if the version number isn't important,
why didn't you call the latest release Fossil 20150223162734 instead
of Fossil 1.31?  I think it's useful to keep the naming scheme
consistent in as many places as possible, when possible.  To be
honest, I don't think most people care about the date of a software
release, but they are interested in having the latest stable version,
whatever that is.  As you said, the versions for Fossil are snapshots,
but a lot of people correlate something like Fossil 1.31 as being the
latest stable, regardless of it actually meaning that or not.

- joe
___
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 1.31 directory name

[Joe Prostko]

On Tue, Feb 24, 2015 at 12:02 PM, Richard Hipp d...@sqlite.org wrote:
 On 2/24/15, Andy Goth andrew.m.g...@gmail.com wrote:

 Unlike previous releases, the unpacked directory name does not contain the
 seconds.  This means the directory and archive filenames don't match, which
 is a problem for the SlackBuild script.

 Are there any plans to reupload with the directory renamed

 I'll get to that as I am able.  We have a bug in SQLite right now.
 You are in queue

Yes, I wondered about the directory name not matching the filename,
but just modified my Haiku build recipe to account for it.  I'll be
sure to change the recipe file once the tar.gz with the full path is
in place.

Good luck on tackling the SQLite bug!

- joe
___
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 source download naming scheme

[Joe Prostko]

On Tue, Feb 24, 2015 at 3:59 PM, jungle Boogie jungleboog...@gmail.com wrote:
 Hi Joe,

 How have you been updating packages in the past?

 All releases are like this:
 20150223162734
 20150119112900
 20140612172556
 20140127173344
 2013094349

I just used those as they were without issue.  See any of the recipe files here:

http://bb.haikuports.org/haikuports/src/3acdb243c266b70a2051fa370f2e8e8b83fa4bff/dev-vcs/fossil

That said, it would be cleaner to just use our $portVersionedName
variable (for example, which would return fossil-1.31) in SRC_URI and
SOURCE_DIR if the filename were fossil-1.31.tar.gz and the extracted
directory were fossil-1.31, for instance.  There would be less to
change in the recipe files from version to version (only the
sha256sum), although admittedly, changing three lines isn't exactly a
huge ordeal.  :)

In any case, it totally doesn't bother me at all the way things are
now, but it's different than the way most software tarballs are done.
As Richard mentioned, this can all wait until 2.0, for sure.

- joe
___
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 version 1.31 testing

[Joe Prostko]

On Mon, Feb 23, 2015 at 1:16 PM, Richard Hipp d...@sqlite.org wrote:
 New tarball with the missing files has been uploaded.

Are you sure about that?  I tried buliding on two separate OS's now
(Manjaro Linux and Haiku) and it fails to build with either with the
same error as previously mentioned.  This is the source tar.gz in
question: https://www.fossil-scm.org/download/fossil-src-20150223162734.tar.gz

Here is the build failure which occurs after ./configure and make:

cc -o bld/mkbuiltin ./src/mkbuiltin.c
bld/mkbuiltin --prefix ./src/ ./src/../skins/black_and_white/css.txt
./src/../skins/black_and_white/footer.txt
./src/../skins/black_and_white/header.txt
./src/../skins/default/css.txt ./src/../skins/default/footer.txt
./src/../skins/default/header.txt ./src/../skins/eagle/css.txt
./src/../skins/eagle/footer.txt ./src/../skins/eagle/header.txt
./src/../skins/enhanced1/css.txt ./src/../skins/enhanced1/footer.txt
./src/../skins/enhanced1/header.txt ./src/../skins/etienne1/css.txt
./src/../skins/etienne1/footer.txt ./src/../skins/etienne1/header.txt
./src/../skins/khaki/css.txt ./src/../skins/khaki/footer.txt
./src/../skins/khaki/header.txt ./src/../skins/plain_gray/css.txt
./src/../skins/plain_gray/footer.txt
./src/../skins/plain_gray/header.txt ./src/../skins/rounded1/css.txt
./src/../skins/rounded1/footer.txt ./src/../skins/rounded1/header.txt
./src/diff.tcl ./src/markdown.md bld/builtin_data.h
cc -o bld/makeheaders ./src/makeheaders.c
make: *** No rule to make target 'src/../manifest.uuid', needed by
'bld/VERSION.h'.  Stop.


- joe
___
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 version 1.31 testing

[Joe Prostko]

On Mon, Feb 23, 2015 at 8:04 PM, Joe Prostko joe.pros...@gmail.com wrote:

 same error as previously mentioned.  This is the source tar.gz in
 question: https://www.fossil-scm.org/download/fossil-src-20150223162734.tar.gz

As an FYI, the sha1sum matches what is reported on the website at
http://www.hwaci.com/fossil_download_checksums.html .  That said, I
still see the build failure.

[jprostko@galago Downloads]$ sha1sum fossil-src-20150223162734.tar.gz
8fbde3f48f10cf128c902035aaa6aae06e869098  fossil-src-20150223162734.tar.gz


- joe
___
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 version 1.31 testing

[Joe Prostko]

On Mon, Feb 23, 2015 at 9:09 PM, Richard Hipp d...@sqlite.org wrote:
 On 2/23/15, Joe Prostko joe.pros...@gmail.com wrote:
 On Mon, Feb 23, 2015 at 1:16 PM, Richard Hipp d...@sqlite.org wrote:
 New tarball with the missing files has been uploaded.

 Are you sure about that?

 Uploaded yet again.  Please retry.

Confirmed working.  Thank you!

- joe
___
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] FLOSS interview

[Joe Prostko]

On Fri, Jan 9, 2015 at 1:59 PM, jungle Boogie jungleboog...@gmail.com
wrote:

 Hi Luca,
 On 8 January 2015 at 23:18, Luca Ferrari fluca1...@infinito.it wrote:

  Partly unrelated, and quite old, but there's another interesting
  interview about SQLite: http://twit.tv/show/floss-weekly/26
 

 Yes, but unfortunately the file is 404.

 % fetch https://twit.cachefly.net/FLOSS-026.ogg
 fetch: https://twit.cachefly.net/FLOSS-026.ogg: Not Found

Well, the MP3 version is still available from the original link that Luca
shared, so you can download that as an alternative.  It does indeed seem
that the Ogg link is dead though.

- joe
___
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] Any other language bindings to Fossil?

[Joe Prostko]

On Fri, Nov 7, 2014 at 3:27 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Thu, Nov 6, 2014 at 10:10 PM, Ron W ronw.m...@gmail.com wrote:

 You should not need to port s2 to Python, rather reference the s2
bindings to libfossil as an example.


 Indeed, don't try to port it - shape the API how you want it, using s2 as
a guideline for how to use the libfossil APIs.

Thanks for the advice.  I will probably start work this weekend, although
like a lot of us, I don't have a ton of spare time nowadays, so progress
will likely be slow.

- joe
___
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] Any other language bindings to Fossil?

[Joe Prostko]

On Fri, Nov 7, 2014 at 10:09 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Fri, Nov 7, 2014 at 3:53 PM, Joe Prostko joe.pros...@gmail.com wrote:

 Thanks for the advice.  I will probably start work this weekend,
although like a lot of us, I don't have a ton of spare time nowadays, so
progress will likely be slow.


 Feel free to post questions about using/navigating it off-list (or on the
dev list if they're of general interest). i use such mails to improve the
docs and APIs.

 The very top section of this page:


http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki?name=HackersGuide

 will tell you where everything is.

Thanks again for the tips!  I will certainly contact you or the dev list if
I have any questions along the way.  I'm sure there will be more than one.
 :)

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

[fossil-users] Any other language bindings to Fossil?

[Joe Prostko]

Hello,

I know that libfossil is in progress, but has anybody been doing work that
involves doing Python or PHP bindings to Fossil (whether or not they are
utilizing libfossil or not)?

I'm asking since I have been starting to utilize Salt 
http://www.saltstack.com/ lately for work, and well, there's currently VCS
integration for Git, Hg, and SVN, but there's nothing there for Fossil.  I
think I could get a lot of the functionality working by calling the Fossil
binary directly from Python, but some things would be better suited by
interfacing with an existing library (like libfossil), or well, maybe even
a full reimplementation of Fossil in pure Python.

Has anybody done any work on interfaces between Fossil and other
programming languages, or is that something that still requires a lot of
work to be done?  I have looked at the supported libraries used in Salt for
Git integration, and each one has a different approach.  The one,
GitPython, indeed just interfaces with Git directly, another one, pygit2
(the preferred option), interfaces with the C library libgit2, and Dulwich
implements Git itself in pure Python.

In any case, any insights about what approach you would take would be
appreciated.  I think I'll probably just have to start implementing things
to see where I get tripped up without using anything resembling a dedicated
library, but I suspect that the fileserver backend capability is where I'll
start running into issues if I try calling the Fossil binary directly.

If anybody is curious, here is some information on gitfs as implemented on
Salt:

http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html


Thanks for any insights about existing or work-in-progress language
interfaces to Fossil, as well as any other advice.

If somebody else has started work on integrating Fossil into Salt, that
would be good to know as well.  :)

- joe
___
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] Any other language bindings to Fossil?

[Joe Prostko]

On Thu, Nov 6, 2014 at 3:29 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Thu, Nov 6, 2014 at 9:13 PM, Joe Prostko joe.pros...@gmail.com wrote:

 Has anybody done any work on interfaces between Fossil and other
programming languages, or is that something that still requires a lot of
work to be done?


 As you probably already know, but here it is for those who don't:


https://docs.google.com/document/d/13gRSl6-bj3LV-OKgE-BsqvqF33UFYW3oa3A2OJC5QSY/view

I can't view this at work since Google docs is blocked, but I assume you
are talking about s2?  I guess worst case I can try to port s2 to Python
or the like, although I suspect that will be a bit of work.  I guess
anything worthwhile takes work though.  :)

Thanks for the input, as it may very well help me, as well as inform others!

- joe
___
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] Any other language bindings to Fossil?

[Joe Prostko]

On Thu, Nov 6, 2014 at 4:10 PM, Ron W ronw.m...@gmail.com wrote:

 You should not need to port s2 to Python, rather reference the s2
bindings to libfossil as an example.

Yeah, that is why I put `port` in quotes in my last response.  I probably
should have just stated what I actually meant instead.  :)

 I am considering doing a Perl binding to libfossil, probably using h2xs
to generate the low level type mapping, then writing a thin layer of Perl
code to present a more Perl-ish interface as well as perform exception
handling.

Very cool.  I guess if nobody else speaks up, I may have to take a crack at
a Python binding to libfossil.  Like I mentioned, I want to see what I can
accomplish without doing that though, as perhaps I won't have to do a whole
lot in order to have a suitable solution for Fossil integration in Salt.

- joe
___
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] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

On Sun, Jul 27, 2014 at 3:22 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
 2014-07-26 5:08 GMT+02:00 Joe Prostko joe.pros...@gmail.com:
 Using the handy `fossil bisect`, I found that this revision is causing
 me problems while compiling Fossil from within Haiku.

 Should be fixed here:
 http://fossil-scm.org/index.html/info/14aea4f883

 Thanks for the report.

Confirmed as fixed on Haiku, and compiles/works fine on this Manjaro
machine as well.  Thank you!

 The real issue was that although SQLite is supposed to be
 compiled with NDEBUG=1, this macro was defined too
 late, after the inclusion of the first assert.h. This resulted
 in the TESTONLY macro to be an empty define, but the
 assert() macro was not empty. On most platforms (e.g. linux)
 the assert() macro is re-defined every time when assert.h
 is included again, then this problem is not noticed. However,
 it really was a problem in fossil's build system, which
 caused fossil's embedded SQLite to be compiled in
 debug mode :-( This side-effect was not intentional!

I had honed in on the problem being related to NDEBUG, but didn't get
any farther than that.  I am glad you were able to figure this out,
and that the fix helped to address a Fossil bug as well.  :)

- joe
___
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] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

On Fri, Jul 25, 2014 at 11:08 PM, Joe Prostko joe.pros...@gmail.com wrote:
 Using the handy `fossil bisect`, I found that this revision is causing
 me problems while compiling Fossil from within Haiku.

I did some more digging, and the problem seems to be that the assert.h
included from within config.h is causing problems when sqlite3.c
includes config.h due to _HAVE_SQLITE_CONFIG_H being defined.

I did a dirty workaround of copying config.h to jpconfig.h, and then
commenting out the include line for assert.h on line 55 of jpconfig.h.
I then edited sqlite3.c to include jpconfig.h instead of config.h on
line 7635.  All other files that include config.h build just fine, as
the only file that has problems with config.h in its original form is
sqlite3.c.  Things compile and run just fine when jpconfig.h is
included by sqlite3.c instead of config.h.

I played around a bit to try to get some sort of clever header guard
in place, but ultimately it didn't work...or wasn't clever enough.  ;)

If somebody more familiar with all of the code has any ideas, that
would be appreciated.  I'm sure I'm overlooking something obvious to
fix this, all without negatively affecting other platforms.  I thought
I could find the answer by looking at the SQLite codebase, but well,
it generates its config.h during configure, and it looks nothing like
the config.h included with Fossil, that's for sure.

Also, in case it's useful, here's the assert.h that is used by Haiku.

http://cgit.haiku-os.org/haiku/tree/headers/posix/assert.h

I'll probably look at this all again tomorrow if nobody has any ideas,
but wanted to share my latest findings.

- joe
___
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 is now 7 years old

[Joe Prostko]

Congratulations!   I must say that Fossil is the best thing to happen
to my development workflow this year, as I am pretty sure that using
Git has resulted in the premature death of too many of my brain cells.
I'm glad to be able to replace Git in every place that I possibly can
with Fossil.

The occasion of the seven year anniversary reminds me of something
I've been meaning to ask on the list.  It has been asked in the past
according to my check of the archives, but is there any chance you
would be willing to go on Floss Weekly and talk about Fossil?  I know
that you were on there to talk about SQLite quite some time ago, but I
would love for there to be a show featuring Fossil.  I know that
Randal's current way for projects to get on the show is that he will
only schedule a time if the project leader(s) contacts him directly.
In any case, I hope you will consider going on the show (alone or with
another core committer), as it would be a great way to let more people
know about the awesomeness that is Fossil.

- joe

On Fri, Jul 25, 2014 at 11:57 AM, Richard Hipp d...@sqlite.org wrote:
 The seventh anniversary of the first self-commit of Fossil source code was
 this past Monday.  Time flies.

 The logical predecessor of Fossil was CVSTrac (http://www.cvstrac.org/)
 which was a wiki and trouble-ticket system built atop CVS.  CVSTrac became
 the inspiration for Trac (http://trac.edgewall.org/wiki/CvsTrac) which is a
 similar tool for SVN that became far more popular than CVSTrac and which is
 still in active use.  Fossil was originally created to provide features
 needed in SQLite development, features that I couldn't get with CVS+CVSTrac,
 or with Monotone or Git or Mercurial or any other configuration management
 system available at the time.  I worked on prototypes of Fossil for a year
 or more prior to the first self-commit on 2007-07-21, but none of those
 early prototypes survive.

 Code archeologists will be able to find a lot of commonality between the
 CVSTrac and Fossil source codes.  There is a clear genetic relationship
 between the two systems.

 Fossil was created for the purpose of aiding in the development of SQLite.
 (Other uses for Fossil, though welcomed, are secondary.)  The SQLite
 documentation sources (http://www.sqlite.org/docsrc/timeline?a=2000-01-01)
 were split off from the SQLite source tree in CVS on 2007-11-12, just a few
 months after Fossil began self-hosting.  But the core SQLite source code did
 not move to Fossil until 2009-08-11, just after the release of SQLite
 version 3.6.17, over two years after Fossil became self-hosting.  The move
 from CVS to Fossil has proven to be a boon for SQLite development.

 CVSTrac was in active use by SQLite for a little over 7 years.  To my
 knowledge, nobody uses CVSTrac any more.  (OpenSSL was the last known user
 of CVSTrac and they switched over to Git at the beginning of 2013.) Fossil
 will soon overtake CVSTrac in terms of years of use, and Fossil has a great
 deal more momentum and a much larger user base than CVSTrac ever had.

 --
 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Issue compiling with 16f1076334 and newer revisions

[Joe Prostko]

Using the handy `fossil bisect`, I found that this revision is causing
me problems while compiling Fossil from within Haiku.

This revision brought in -D_HAVE_SQLITE_CONFIG_H and in theory should
work on platforms that support utime() and usleep().  In any case, I
have found that for Haiku anyway, the build fails with this revision
or better, unless I get rid of -D_HAVE_SQLITE_CONFIG_H in Makefile.in.

I admit I didn't really dig into this at all yet, but in any case, the
build fails with both GCC 2.95.3 and GCC 4.8.3 on Haiku.  I'm not sure
why it is happening as of yet.  I suspect it will come down to the
compiler not liking something with respect to typedef'ing structs
though, as I admit this failure seems familiar to me.

Below is the output from revision ffef4edceb with GCC 4.8.3 (since it
is more verbose) in case Jan or anyone else can make sense of it
before I get a chance to try to dig deeper into the situation.


cc -I/packages/openssl-1.0.0m-2/.self/develop/headers-g -O2
-DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H  -I. -I./src -Ibld
-DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_ENABLE_LOCKING_STYLE=0
-DSQLITE_THREADSAFE=0 -DSQLITE_DEFAULT_FILE_FORMAT=4
-DSQLITE_OMIT_DEPRECATED -DSQLITE_ENABLE_EXPLAIN_COMMENTS  -c
./src/sqlite3.c -o bld/sqlite3.o
In file included from ./src/config.h:55:0,
 from ./src/sqlite3.c:7635:
./src/sqlite3.c: In function 'pcache1TruncateUnsafe':
./src/sqlite3.c:38822:26: error: 'nPage' undeclared (first use in this function)
   assert( pCache-nPage==nPage );
  ^
./src/sqlite3.c:38822:26: note: each undeclared identifier is reported
only once for each function it appears in
./src/sqlite3.c: In function 'sqlite3WalFindFrame':
./src/sqlite3.c:49527:36: error: 'Wal' has no member named 'lockError'
   assert( pWal-readLock=0 || pWal-lockError );
^
./src/sqlite3.c: In function 'sqlite3WalExclusiveMode':
./src/sqlite3.c:50265:36: error: 'Wal' has no member named 'lockError'
   assert( pWal-readLock=0 || pWal-lockError );
^
./src/sqlite3.c: In function 'cellSizePtr':
./src/sqlite3.c:52346:18: error: 'debuginfo' undeclared (first use in
this function)
   assert( nSize==debuginfo.nSize );
  ^
./src/sqlite3.c: In function 'autoVacuumCommit':
./src/sqlite3.c:54514:11: error: 'nRef' undeclared (first use in this function)
   assert( nRef=sqlite3PagerRefcount(pPager) );
   ^
./src/sqlite3.c: In function 'balance':
./src/sqlite3.c:58117:18: error: 'balance_deeper_called' undeclared
(first use in this function)
 assert( (balance_deeper_called++)==0 );
  ^
./src/sqlite3.c:58156:20: error: 'balance_quick_called' undeclared
(first use in this function)
   assert( (balance_quick_called++)==0 );
^
./src/sqlite3.c: In function 'sqlite3_backup_step':
./src/sqlite3.c:60361:15: error: 'rc2' undeclared (first use in this function)
   assert( rc2==SQLITE_OK );
   ^
./src/sqlite3.c: In function 'sqlite3VdbeSorterWrite':
./src/sqlite3.c:75447:31: error: 'nExpect' undeclared (first use in
this function)
 assert( rc!=SQLITE_OK || (nExpect==pSorter-iWriteOff) );
   ^
./src/sqlite3.c: In function 'sqlite3ExprCodeTarget':
./src/sqlite3.c:80833:36: error: 'iCacheLevel' undeclared (first use
in this function)
|| pParse-iCacheLevel==iCacheLevel );
^
./src/sqlite3.c: In function 'sqlite3DeleteTable':
./src/sqlite3.c:86185:15: error: 'pOld' undeclared (first use in this function)
   assert( pOld==pIndex || pOld==0 );
   ^
./src/sqlite3.c:86208:11: error: 'nLookaside' undeclared (first use in
this function)
   assert( nLookaside==0 || nLookaside==db-lookaside.nOut );
   ^
./src/sqlite3.c: In function 'sqlite3InitCallback':
./src/sqlite3.c:100108:25: error: 'rcp' undeclared (first use in this function)
 assert( (rc0xFF)==(rcp0xFF) );
 ^
./src/sqlite3.c: In function 'execSql':
./src/sqlite3.c:108467:11: error: 'rc' undeclared (first use in this function)
   assert( rc!=SQLITE_ROW || (db-flagsSQLITE_CountRows) );
   ^
make: *** [bld/sqlite3.o] Error 1
___
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] Minor fossil success story

[Joe Prostko]

On Mon, Jul 14, 2014 at 2:15 PM, Richard Hipp d...@sqlite.org wrote:
 Maybe I'll add Stephan's quote to
 http://www.fossil-svm.org/index.html/doc/tip/www/quotes.html

I think you meant
http://www.fossil-scm.org/index.html/doc/tip/www/quotes.wiki .  :)
___
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] Update config.* in autosetup directory?

[Joe Prostko]

On Sat, Jun 21, 2014 at 9:11 PM, Joe Prostko joe.pros...@gmail.com wrote:

 I was just trying to build Fossil on the x86-64 version of Haiku, and
 it didn't get far since the platform failed to be identified.  I
 replaced the versions of config.guess and config.sub shipped with
 Fossil and then configure worked, as well as the rest of the build.

 Is there any chance those two files can be updated?

 They are available at the following links:

 config.guess: 
 http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
 config.sub: 
 http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

Hey, I am just replying to this mail in case it didn't get noticed the
first time around.  If config.sub and config.guess could be updated to
something more recent before Fossil 1.30 comes out, that would be
appreciated.  If there is a reason to stay with the older versions of
those files, I will be happy to supply a patch to have support for
Haiku x86-64.  Just let me know.

Thanks!

- joe
___
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] Update config.* in autosetup directory?

[Joe Prostko]

On Mon, Jul 7, 2014 at 5:03 PM, Joe Mistachkin sql...@mistachkin.com wrote:

 Joe Prostko wrote:

 Is there any chance those two files can be updated?

 They are available at the following links:

 config.guess:
 http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess
 ;hb=HEAD
 config.sub:
 http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;h
 b=HEAD


 I've updated them on the 'pending-review' branch.  These changes, which look
 fairly extensive, are going to need wider review (and possibly more testing)
 before being merged to trunk.  Hopefully, this will be completed well before
 the release of 1.30.

Thank you, Joe!  And yes, keep the changes in the pending-review
branch until you are sure everything is safe to merge.  Like you, I
would prefer things be done right, so there's definitely no rush.

Thanks again.

- joe
___
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] Changing header include order in main.c

[Joe Prostko]

On Mon, Jun 23, 2014 at 12:29 AM, Joe Mistachkin sql...@mistachkin.com wrote:

 Joe Prostko wrote:

 If I move the zlib.h inclusion below the crypto.h inclusion's #endif,
 then Fossil compiles and works fine with both GCC2 and GCC4.


 Fixed on trunk.  Thanks for the report.

Cool, thanks for the fix!  If the fix was a lot more involved, I
simply would have made it a required patch for our packaging system,
seeing as it's kind of unfair to expect you to support ancient
compilers like GCC 2.95.3, obviously.

Thanks again, as this makes my life easier.  :)

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

[fossil-users] Changing header include order in main.c

[Joe Prostko]

Hello,

Something else I found while compiling Fossil on Haiku.  It should be
the last issue I'm having.

I admit I didn't notice it before 1.29 came out, but essentially this
commit caused me some problems:

http://fossil-scm.org/index.html/info/48f1239eb2e9098b5c2f3b7d118683e4418f4696

The change that causes the issue is the header change on line 37 of main.c.

The build works fine for Haiku if you are using the GCC4 compiler, but
it bombs out using our GCC2 compiler (which is in place since we
attempt to be binary/source compatible with BeOS applications).

This problem isn't directly because of a different header being used,
but is because of the include order of the headers in main.c that only
becomes a factor when the different header is used.

If I move the zlib.h inclusion below the crypto.h inclusion's #endif,
then Fossil compiles and works fine with both GCC2 and GCC4.

There's a good explanation of the problem in the comments of the link
below.  The last comment of the thread also shows an alternate way to
address the issue.  Basically, the heart of the problem is that
free_func is typedef'd in zlib, and that causes confusion with the
free_func that exists in OpenSSL in headers like crypto.h.
Essentially, in my case, I was getting the syntax error before
`free_func' error on lines 466 and 471 of crypto.h that comes from
OpenSSL 1.0.0m which is currently provided with Haiku.

http://compgroups.net/comp.postgresql.hackers/build-error/2936423

Patch against Fossil trunk below, which may get mangled by my mail
client.  If it does't it's easy enough to move the zlib.h inclusion
down a few lines.  :)

--- fossil-old/src/main.c   2014-06-22 22:45:33.318664838 -0400
+++ fossil/src/main.c   2014-06-22 22:47:58.151663045 -0400
@@ -32,10 +32,10 @@
 #else
 #  include errno.h /* errno global */
 #endif
-#include zlib.h
 #ifdef FOSSIL_ENABLE_SSL
 #  include openssl/crypto.h
 #endif
+#include zlib.h
 #if INTERFACE
 #ifdef FOSSIL_ENABLE_TCL
 #  include tcl.h


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

[fossil-users] Update config.* in autosetup directory?

[Joe Prostko]

Hello,

I was just trying to build Fossil on the x86-64 version of Haiku, and
it didn't get far since the platform failed to be identified.  I
replaced the versions of config.guess and config.sub shipped with
Fossil and then configure worked, as well as the rest of the build.

Is there any chance those two files can be updated?  Only config.guess
really needs to be updated in the case of Haiku, but probably both
files should be updated at the same time.

The current timestamps for the files shipped with Fossil are
2010-09-24 for config.guess and 2010-09-11 for config.sub.  The latest
available via git.savannah.gnu.org are 2014-03-23 for config.guess and
2014-05-01 for config.sub.

They are available at the following links:

config.guess: 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
config.sub: 
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

Thank you!

- joe
___
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] FYI: doc URLs don't work with filenames that have + in their names

[Joe Prostko]

On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com wrote:

 Incidentally, I'm bothering with nginx proxying because the SCGI method
seems to have broken in 1.28.  It was working fine on my site with 1.27
from the Ubuntu repository until I upgraded to 1.28 by building from
source.  (I wanted the /tree feature.)

This should work in trunk or when 1.29 comes out, as Richard fixed it post
1.28.
___
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] FYI: doc URLs don't work with filenames that have + in their names

[Joe Prostko]

On Tue, May 27, 2014 at 11:31 PM, Warren Young war...@etr-usa.com wrote:
 On 5/27/2014 17:10, Joe Prostko wrote:

 On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
 mailto:war...@etr-usa.com wrote:

   Incidentally, I'm bothering with nginx proxying because the SCGI
 method seems to have broken in 1.28.  It was working fine on my site
 with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
 building from source.  (I wanted the /tree feature.)

 This should work in trunk or when 1.29 comes out, as Richard fixed it
 post 1.28.


 Confirmed.  I'm back on SCGI now.  Thanks!


No problem!  I reported it some time back, and Richard committed the fix.

 1. You don't need to do regex matching on the URL here.  This does the same
 thing more efficiently and more clearly:

 location /demo_project/ {

 nginx does prefix matching by default.  Using regex matching (~) just to pin
 the match to the start of the path with ^ adds nothing.

I always write this as:

location ~ ^/demo_project {

myself.  That way, it's a case-sensitive search where I don't have to
worry about the trailing slash, and it stops searching once it finds
/demo_project.  I could be mistaken though, but I thought the way you
suggested wouldn't be as flexible.

I guess I'd have to test it to be sure, as anything resembling regex
is kind of like black magic to me.  ;)

- joe
___
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 responds Not Found [1.28]

[Joe Prostko]

On Fri, May 23, 2014 at 1:00 AM, pablo pa...@thy.oib.com wrote:
 Hi to all,

 What I have to do for FOSSIL SERVER to work on my server?

 I have installed a linux server on a VmWare Workstation and using the 1.28
 version of fossil.
 When I try to browse the repository i get a message of Not Found no matter
 what path I try to access (/index , /timeline)

My guess is it is because you are running Fossil as root.  This was
fixed somewhat recently, here:

http://fossil-scm.org/index.html/info/5e47d555e4770445328a34f8a46f6487b75192f6

Are you running as root on your other TKL installation?  If you can
build from source, maybe try a trunk build.  If not, I think you'll
have to wait for 1.29 to come out, which I suspect will be really
soon.

- joe
___
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] Location of .fossil Database

[Joe Prostko]

On Wed, May 21, 2014 at 11:34 AM, Igor de Oliveira Couto
i...@semperuna.com wrote:

 loving it. One point that I found somewhat disappointing, is that Fossil
 creates a .fossil database in my home directory.

 I know that many applications in Linux/Unix store their preferences and
 settings in dot-files, in the user's home directory - ie., ~/.myapp. This,
 however, is a Linux standard, and does not translate to other platforms.

Yes, this occurred to me as well, since I also use an OS (Haiku) that
specifies where certain files go ideally.  I had thought of providing
a patch so the .fossil ends up in a given user's settings directory,
but didn't get around to doing it, as I admit it slipped my mind until
now.  :)

 preferences, and so does the MacOS. The Apple guidelines are quite specific
 as to where applications should store their temporary, support and
 preference files, and the system provides *several* places that developer
 should use (and apps that don't are not considered 'good citizens'). There
 are also guidelines for the *naming* of such support files on all
 platforms...

Yes, in Haiku, settings should live in the B_USER_SETTINGS_DIRECTORY
(basically, you check against this macro and see what the system gives
you back).  That said, it happily works fine in ~ as Fossil does now.
I suppose it's not the correct way of doing things though, even if
it works fine and I doubt many or any people would notice.

 I believe that it should not be too difficult to add a check in the Fossil
 code, so that the name and location of the .fossil would vary, depending
 on the platform it's running in. I was going to add that as a request ticket
 to the Fossil repo, but saw that it was recommended that we run this by the
 user-list first, to see whether this is something that has been previously
 discussed or not.

 Is there a reason why this should not be added as a feature request?

Yes, I suppose it could be done, but as Stephan mentioned, it may be a
pain to keep this maintained as platforms may decide to change the
settings directories around, for example.  I know on Haiku we have
done this more than once, but well, we are still an immature platform,
so that is to be expected.  I don't expect such things on mature
platforms.

If it were decided to add in the preferred settings directories for
additional platforms, I would gladly provide a patch for Haiku.  I
don't know anything about OS X though, personally, so I can't help
there.

- joe
___
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] Location of .fossil Database

[Joe Prostko]

On Wed, May 21, 2014 at 12:49 PM, Stephan Beal sgb...@googlemail.com wrote:

 And if the dir structure doesn't exist, fossil has to go creating it, etc.
 We know the home dir exists, which makes it easy. Ideal? No, but easy.

Indeed.  That is why I'm likely going to simply not bother making any
changes whatsoever to the Haiku port (which actually isn't even a port
currently, since it compiles and works fine now thanks to folks like
Stephan and Andy B. helping me out with that).  I guess I could patch
it to put the .fossil in a more appropriate directory, but I'm not
sure if it's worth the effort, especially when there's files like
.bash_profile that can exist in ~.  Heck, usually I set up my SSH
files in ~/.ssh, for that matter.  I am guessing that Mac is a bit
more strict about these kinds of things though.  I try to be pragmatic
when possible though and not make things difficult when there's no
need to.

 We all have our quirks. One of mine is that i refuse to come into physical
 contact with an Apple product of any sort, do not provide any tech support
 of any kind for Apple products, nor do i allow Apple products in my flat.
 (Why i do that is not relevant here, i'm just pointing out that we are all
 pedantic about something or other.)

Hmm, that kind of sounds like me, although I was strongly considering
buying a Macbook Pro at one point before I got a similarly-spec'd PC
laptop running Linux.  :)

 i'll admit to having uninstalled apps which have violated my sense of
 propriety, but an extra file in my home dir is not (because of the Unix
 history behind it) one of those proprieties. Historical momentum wins
 here, i think, and Unix has -lots- of historical momentum.

Indeed, I can agree with that pretty much.  No argument from me here.
If my home directory was littered with a ton of files I might care,
but one file is no big deal.

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