Re: [fossil-users] Show time...

[Joseph R. Justice]

On Sun, Jun 3, 2018, 9:33 PM Richard Hipp  wrote:

> On 6/3/18, Richard Hipp  wrote:
> >
> > So, if anybody sees any last minute tidying up that we need to do...
>
> For example, on the front page
> (https://fossil-scm.org/index.html/doc/trunk/www/index.wiki), what if
> I add some text to item 8 to talk about how Fossil is "Independent and
> not beholden to venture capitalists".  Too snarky?
>

Neither is Git.

The Fossil-based competition to GitHub would be, for instance, Chiselapp
(IIRC).

I dare say that the greatest beneficiary of this stuff is likely to be
Gitlab.  Is anybody doing any serious for-profit Fossil repository hosting
yet?



Joseph
___
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] Extending Fossil with Lua?

[Joseph R. Justice]

[Response intentionally CC'd to the original poster, on the off chance he's
not already subscribed to the mailing list]


On Mon, Mar 19, 2018 at 7:42 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

This is just kind of a next semester project, but I would like to start
> exploring the options.
>
> I'm using Fossil mainly to store documentation (using the superb
> embedded documentation feature) for my Grafoscopio[1] project. I think
> that SQLite and Fossil are good examples of what I call pocket
> infrastructures (simple, self-contained and working well on-line and
> off-line) that can help to democratize fields like data visualization
> and storytelling[2]. But, despite its advantages, Fossil is starting to
> feel limited, particularly with the Yaml metadata blocks that the Pandoc
> Markdown variant uses[3]. So I would like to explore the possibility to
> use Lua (which is already integrated in Pandoc and easily integrable in
> other programs) to read such metadata y show it in a proper way. I also
> think that the support for Lua should open a lot of scriptability
> options and ecosystem, far beyond TH1 and Tcl, by using a more wide
> spread scripting language with a bigger ecosystem.
>
> [1] http://mutabit.com/grafoscopio/index.en.html
> [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1
> [3] https://pandoc.org/MANUAL.html#extension-yaml_metadata_block
>
> What should be done to explore such Lua extensions to Fossil? Where can
> I start?


Dear Mr. Cardenas (my apologies for misspelling your name, but I'm just Yet
Another Damned Monolingual Yankee),

I saw your question above when you first sent it to the fossil-users list,
and meant to respond to it, at least to give "one bystander's opinion".  My
apologies for taking so long to respond.  I *do* personally think it's an
interesting idea, but for reasons I'll give below, it might not be as
interesting to the core Fossil developers, at least at this point.

Before I continue, I need to emphasize to the utmost extent that I am *not*
a core Fossil developer or committer to this project; I am *not* an active
external developer for it submitting patches or modules to be integrated
with it; nor am I even just someone actively using it and perhaps
submitting bug reports, documentation, user feedback, etc.  (Perhaps I will
be some of these things at some point if I ever get around to getting
myself a real system suitable for development, but at this time I am not.)
I have, however, been following the project and this list for a fair while
as an outside bystander and observer.  The following should be taken with
that in mind; obviously, anything I say can and should be superseded by an
opinion by someone with more activity and status within this project.

For anyone reading this message who's not already aware of it, Lua (the
site https://www.lua.org/ is the canonical home for it) is a small,
relatively new (compared to others anyway) programming language originally
coming from academia in Brazil but now in use at least somewhat in
commercial and production environments internationally, especially in
certain niches.  It was intentionally designed to be embedded within larger
applications to serve as a scripting or programming language for those
applications, as I understand TCL was as well.  It is under active
development, and has significant existing documentation (including in dead
trees form) and a user community.  As such, it doesn't appear to me at
least at first glance (again, solely based from the viewpoint of an
external bystander / observer of the Fossil project) to be a completely
unreasonable notion to integrate Lua as an alternative scripting /
programming language for Fossil.



That being said, Mr. Cardenas, I have to warn you that in my opinion
there's going to be ... I won't say an active objection by the core Fossil
development team to doing this, but at the least a significant amount of
inertia and friction (*not* necessarily maliciously or consciously
intended!) to the idea.  I'd say much of this will have to do with the
history surrounding the creation and development of Fossil and of its
sister and Siamese twin project, the embedded database SQLite.  My
apologies if the following brief synopsis and analysis of said history is
incorrect or misleading; I eagerly welcome corrections or augmentations of
what I've written.

As I understand it, SQLite was originally created by Dr. D. Richard Hipp as
an add-on for the TCL programming language, and only later subsequently
became an independent entity in its own right able to be used without
reference to TCL.  Fossil then was developed by Dr. Hipp both as a tool for
use in the development of SQLite (presumably the version control systems
commonly available at the time Fossil was created were deemed by him to be
unsuitable) and also as an example of the use of SQLite by a third-party
active project, insofar as Fossil project repositories are created as
SQLite databases, 

Re: [fossil-users] Fossil-NG Bloat?

[Joseph R. Justice]

On Nov 28, 2017 11:08 AM, "Mike Burns"  wrote:

As much as I agree, software in general has moved on. You won't get
> Fossil/SQLite running on a Commodore 64 without a lot of work.
> With legacy platforms come legacy software that is either no longer
> supported by the vendor, or is supported just because the vendor was paid
> by that client to keep on supporting it.
> If drh receives such payment to continue supporting such legacy cases then
> fair enough.
>

What are the chances someone will take up take up this challenge, and have
a Commodore 64 or Apple II version of fossil up and running by the end of
the year?


Does SQLite run on these platforms yet?  If not, need to port that over
*first*, so it's available for Fossil's use ...



Joseph
___
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] Problem with compilation under MINGW

[Joseph R. Justice]

On Sat, Jan 11, 2014 at 1:24 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2014/1/4 James Turner ja...@calminferno.net:



  I won't begin to tell you how to develop fossil but I do want to throw
  out there that OpenBSD has been providing fossil with
  --disable-internal-sqlite via it's ports tree and packages fairly
  successfully (and with 'fossil sqlite3' support) for the last year+.

 I re-enabled fossil sqlite3 again in the branch-1.28 branch:
 My guess is that most package maintainers will re-enable
 it anyway. It's easy enough, but I want to make your
 work easier, not more difficult. For trunk, there's still
 more than enough time to think how this should be
 fixed the 'correct' way, which satisfies everyone (I hope).


I *still* haven't sent out that message / warning yet, but I'm getting
closer.  Have info now for:

CentOS (and Scientific Linux), Cygwin, Debian (and Ubuntu), Fedora,
FreeBSD, Gentoo (and Sabayon), NetBSD, OpenBSD (can be skipped however),
openSUSE, Slackware.

I haven't looked up the Solaris variants yet, nor the other Linux and BSD
distros (Linux: Arch, Mageia, Manjaro, Puppy; BSD: Dragonfly, Ghost,
PC-BSD).

The message will take into account that a 1.28 release will (apparently)
permit --disable-internal-sqlite, but that it is still subject to disabling
(and/or may already be disabled?) for development versions / trunk and
therefore for a future 1.29 release.  (I have to lookit the sources online
to verify this before I say it, however.)

Just a heads up that no, I haven't forgotten or given up.  I'm just slow.



Joseph
___
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] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Tue, Jan 7, 2014 at 4:37 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014/1/7 Joseph R. Justice jayare...@gmail.com:



  May I ask why that run-time check cannot or should not be made in the
  release version of Fossil 1.28, rather than immediately after it is
 tagged
  such that it will only take effect in a release version for Fossil 1.29?

 It's fully up to the Fossil-devs what should be the minimum SQLite
 version Fossil is supposed to work with, and when this minimum
 is updated to higher SQLite versions. My proposal is based on
 a SQLite 3.8.3 release in February 2014. If that changes or if
 the Fossil developers want to move forward faster than that,
 it is very well possible. For Cygwin that wouldn't be a problem, as
 SQLite 3.8.2 is already available now as Cygwin package. For
 other OS distributions I don't know, I'll leave it to others to comment on
 that.


I fully agree that it's up to the Fossil upstream devs as to what should be
the minimum version of SQLite supported with any given release version of
Fossil, and also as to when the minimum version of SQLite supported should
be changed (and what it should be changed to).

My thought here was that the devs (or at least Dr. Hipp as the architect)
seem to desire to make the minimum supported version of SQLite be 3.8.2
*now*.  If that's so, why make them wait for a full release version of
Fossil (e.g. until development begins for Fossil 1.29) before they can make
that change?  After all, it's the distributions' problem to provide the
SQLite library version Fossil upstream requires, or else to patch Fossil to
work with whatever version of SQLite the distribution is willing to
provide.  (But...  See below for a countervailing point.)



Ummm...  As a sort of aside, I'd like to point out one thing here for the
benefit of the Fossil upstream devs, on the off chance they have not yet
considered it.  It's something I think is a sort of corollary / consequence
of what we're talking about that's obvious when you think about it
carefully, but which might be easy to overlook at a first quick glance.
(Ron Wilson's message kind of refers to this, but does not state it
explicitly.)  I'd like to explicitly state it for the record.

Okay.  Again, Fossil upstream devs ARE NOT REQUIRED to support using a
given release version of Fossil with any random old version of SQLite a
end-user (or distribution) wishes to use.  The upstream devs have the right
to say We only support using this release version of Fossil with at least
version XY.ZZ.Y of SQLite, and will not support using this version of
Fossil with any older version of SQLite.  The upstream devs are (in
general) all unpaid volunteers, and as such have the right to set whatever
limit on support they want to set.

However...  Just as are the Fossil upstream devs, the developers /
packagers of a given FOSS Unix/Linux distribution *are* *also* (in general)
unpaid volunteers, and as such *do* *also* have the right to set whatever
limit on support *they* (the distribution developers / packagers) want to
set!

In particular, *they* have the right to say We only support SQLite with a
maximum release version of BL.EG.H, and any software which requires a
version of SQLite more recent than this version is not supportable by us
and we will not package and distribute it in our current version of the
distribution.  The distributions ARE NOT REQUIRED to support or distribute
software which needs any random new version of SQLite a developer wishes to
use!

This means that if the minimum supported version of SQLite the Fossil
upstream devs require for their new release version is XY.ZZ.Y, and the
maximum supported version of SQLite the distribution developers will
provide for their current release version of the distro is BL.EG.H, and
XY.ZZ.Y  BL.EG.H, then the new release version of Fossil will not be made
available for that version of the distribution (at least until they raise
their maximum supported version of SQLite), and the new release version of
Fossil may not even be *useable* on that version of the distribution!

Insofar as the Fossil upstream devs *desire* their current version of
Fossil to be packaged and distributed by the various distributions (as
opposed to requiring end-users to compile / install Fossil on their own),
*this* is the problem of Fossil upstream -- to limit themselves to using
only versions of libraries which are actually available within the various
distributions (the major ones anyway) they want to have distribute their
software.

Now, I'll grant that Fossil, by its intrinsic nature and primary intended
target audience (e.g. that it is a software development tool intended for
use by software developers), isn't as constrained by this as would be an
application intended for use by typical non-technical end-users, such as
say an office productivity application or a financial / bookkeeping
application, or a game, or whatever.  Fossil can say you're a developer,
you know how to compile

Re: [fossil-users] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014/1/4 Richard Hipp d...@sqlite.org:




 (3)  After SQLite 3.8.3 is released, release fossil 1.28 with
   the EXACT SQLite 3.8.3 amalgamation included.


I assume you do not mean here that Fossil v 1.28 should be released
concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28
should be released when it is ready on or after the moment that SQLite
release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such
that the source for the SQLite release v 3.8.3 can be incorporated within
the source for Fossil v 1.28.



(4) Immediately after the fossil 1.28 release, add a runtime-check
  for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add
  WITHOUT ROWID to whatever SQL statement it is useful.
  Unconditionally!


I assume here (and below) you mean SQLite 3.8.2, not 2.8.2 (and 3.8.3
instead of 2.8.3).  I also assume you mean here that it be a runtime check
requiring that *at* *least* SQLite 3.8.2 is available to Fossil (e.g.
SQLite 3.8.2 *or later*), rather than a runtime check requiring that
SQLite 3.8.2 *exactly* be available to Fossil.  (Otherwise, Fossil builds
using the embedded code copy of SQLite would fail at runtime, because
you've just specified the embedded code copy of SQLite for this version of
Fossil is 3.8.3 and not 3.8.2.)

May I ask why that run-time check cannot or should not be made in the
release version of Fossil 1.28, rather than immediately after it is tagged
such that it will only take effect in a release version for Fossil 1.29?
Sure, it means that distributions cannot distribute Fossil 1.28 (as
released by Fossil upstream) using a system-provided shared library version
of SQLite until they have updated that system-provided shared library
version of SQLite to 3.8.2 from whatever version they currently have (call
it v XY.ZZY), but so what?  Distributions are used to this sort of thing,
applications requiring a version of a system-provided library more recent
than the version they currently make available.

The distributions will just have to (1) provide a new version of the
system-provided shared library version of SQLite that is sufficiently
recent for Fossil v 1.28's needs (presumably either SQLite 3.8.2 or 3.8.3
at their discretion); (2) make sure that all the other applications they
distribute that depend on SQLite, which currently work with SQLite v
XY.ZZY, will work properly with the new version of SQLite whatever it ends
up being, and patch or update those other applications as necessary; (3)
make Fossil 1.28, the new version of SQLite, and any new versions of other
apps available to their end-users, which the end-users can update to if and
as they see fit to.  (Well, unless  the distributions patch their copy of
Fossil v 1.28 to use their copy of SQLite v XY.ZZY, but they do that at
their own risk and are responsible for all support of that combination.
Fossil upstream devs will not support that combination of software.)

This will require all end-users to update their copy of SQLite and possibly
other applications depending on SQLite if they want to use the new release
version of Fossil, but again so what?  That's what distribution packaging,
and distribution software update tools, are all about; to make sure that
sort of thing works, everything is consistent and supported, etc.




 (5) Future official fossil release should contain an official released
   SQLite amagalmation as well, but less frequent: There is
  no need to make a new Fossil release after each SQLite
  release.


I would agree that, unless part of the purpose (either explicit or
implicit) for Fossil's existence is to act as a showcase and testbed for
the latest and greatest available version of SQLite, there is no need to
tie releases of Fossil to releases of SQLite.  Release versions of Fossil
should be made when they are appropriate and when they are ready, which
does not necessarily have anything to do with the release schedule of
SQLite.

Further, release versions of Fossil should not necessarily require using
the latest and greatest release version of SQLite, unless features and
bug-fixes only available in that version of SQLite are required by the
release version of Fossil to be made.  Instead, release versions of Fossil
should only require using the oldest version of SQLite providing the
features that version of Fossil needs which the Fossil devs *are* *willing*
*to* *support* for that version of Fossil.  (If the Fossil devs say We
only support using the latest and greatest release version of SQLite
available at the time we made this release version of Fossil, well then so
be it.  The Fossil devs are volunteers, presumably not being paid (in
general) to develop and support Fossil, and are not required to do anything
they do not want to do.)

In particular...  If Fossil version M requires using SQLite version N, and
if Fossil version M+1 does not require any 

Re: [fossil-users] Problem with compilation under MINGW

[Joseph R. Justice]

On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp d...@sqlite.org wrote:

 OK, so I propose the following fix:


[...]


  (2) Remove the --disable-internal-sqlite option on trunk.  Require the
 use of the built-in SQLite only, since SQLite needs to be built with
 non-standard compile-time options to fully meet the needs of Fossil.


[...]


 (4) When distributions complain, we simply explain that we tried using an
 external SQLite but it introduced too many complications and bugs and that
 we now require statically linking SQLite for reasons of security and
 reliability.


Just to make sure I understand...  You intend to eliminate the capability
of --disable-internal-sqlite for Fossil not only for tip-of-trunk of
Fossil, and not only for development snapshots (although you don't really
have that, do you?), but *also* for future *release* versions of Fossil as
well.  Correct?

In other words, on http://www.fossil-scm.org/download.html , if and when
there is a Version 1.28 (and also for later versions beyond that one),
the distributed source code for that version (or later) of Fossil will no
longer support --disable-internal-sqlite, and any distribution wishing to
package that version of Fossil such that it will use their system-provided
shared library version of SQLite (which presumably will or at least may be
different from the version provided with Fossil as an embedded code copy)
will be entirely on their own to implement that capability.

And further, presumably, the fossil-scm.org devs will not accept patches
from external contributors (such as distribution packagers of Fossil) to be
applied to the source code for the released version of Fossil to re-add
this capability.



Thanks for your time.



Joseph
___
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] Problem with compilation under MINGW

[Joseph R. Justice]

On Sat, Jan 4, 2014 at 11:04 AM, Richard Hipp d...@sqlite.org wrote:

 On Sat, Jan 4, 2014 at 10:59 AM, Joseph R. Justice jayare...@gmail.comwrote:

 On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp d...@sqlite.org wrote:



  OK, so I propose the following fix:


 [...]


  (2) Remove the --disable-internal-sqlite option on trunk.  Require the
 use of the built-in SQLite only, since SQLite needs to be built with
 non-standard compile-time options to fully meet the needs of Fossil.


 [...]


  (4) When distributions complain, we simply explain that we tried using
 an external SQLite but it introduced too many complications and bugs and
 that we now require statically linking SQLite for reasons of security and
 reliability.


 Just to make sure I understand...  You intend to eliminate the capability
 of --disable-internal-sqlite for Fossil not only for tip-of-trunk of
 Fossil, and not only for development snapshots (although you don't really
 have that, do you?), but *also* for future *release* versions of Fossil as
 well.  Correct?

 In other words, on http://www.fossil-scm.org/download.html , if and when
 there is a Version 1.28 (and also for later versions beyond that one),
 the distributed source code for that version (or later) of Fossil will no
 longer support --disable-internal-sqlite, and any distribution wishing to
 package that version of Fossil such that it will use their system-provided
 shared library version of SQLite (which presumably will or at least may be
 different from the version provided with Fossil as an embedded code copy)
 will be entirely on their own to implement that capability.

 And further, presumably, the fossil-scm.org devs will not accept patches
 from external contributors (such as distribution packagers of Fossil) to be
 applied to the source code for the released version of Fossil to re-add
 this capability.


 That is my proposal, yes.

 The rational is that --disable-internal-sqlite adds no new capabilities to
 the program, but it does add complexity and risk.


Okay.



I intend (from the perspective of an interested bystander both of
fossil-scm and of Unix/Linux distributions, wishing them to cooperate and
coexist as happily as possible), to contact the package maintainers of
Fossil within the various major Unix/Linux distributions (for some
definition of the word major, for distributions which provide Fossil as
part of their distribution *and* which actively package it (as opposed to
just using some other distribution's package without changes), and where I
can identify and contact the applicable package maintainer), to inform them
of this proposed change to future release versions of Fossil, and to
encourage them to comment here on this list if they wish to speak up
concerning this proposal before it is implemented by the fossil-scm devs.

I will also encourage them to subscribe to this list if they have not yet
done so, so that they can do a better job of representing their
distribution to the fossil-scm.org devs (who are the upstream for Fossil).

I will notify this list of the distributions and package maintainers I
contact (and of any distributions which should be contacted but where I
cannot manage to identify or contact the maintainer).

At a minimum, I expect/hope to contact the applicable packager for the
following distributions (subject to their packaging Fossil as part of the
distribution; if they do not, there is no reason for me to contact them):

(1) Debian (Ubuntu derived from Debian and has the same maintainer, Linux
Mint derived from Ubuntu and/or Debian may use the same package, many
others derived from Debian and/or Ubuntu)

(2) Fedora (CentOS and Scientific derived from RHEL which is largely
derived from Fedora, note that Fedora provides EPEL which is Fedora
packages compiled for RHEL, CentOS, Scientific; might be good to contact
CentOS and Scientific anyway)

(3) openSUSE ()

(4) Gentoo (Sabayon derived from Gentoo)

(5) Slackware ()

(6, 7, 8) The BSDs: FreeBSD, NetBSD, OpenBSD (NOTE: The packager for Fossil
for OpenBSD is already a participant in this discussion and does not need
to be contacted!)

(9, 10) The Solaris variants: OpenIndiana, SmartOS

I may also contact: Arch (Manjaro derived from Arch), Mageia (), Puppy (),
DragonFly BSD, GhostBSD, MidnightBSD, PC-BSD (all these BSDs derived from
FreeBSD), but will not worry about them as much as the 10 I've identified
above.



Proposed message, *please* comment if you disagree with any of it or wish
me to add any information, I will not send this message before the evening
(East Coast USA time) of Tues, 7 Jan 2014 (possibly later if it takes me
longer to identify a maintainer):

==
Hello.

I am an interested bystander of the Fossil SCM project (www.fossil-scm.org).
I am *not* a developer within this project, nor do I have any other
authority or responsibility within it than any random bystander and member
of the peanut gallery might have.

I have identified you as the person within

Re: [fossil-users] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Thu, Jan 2, 2014 at 9:52 PM, Nico Williams n...@cryptonector.com wrote:

More generally, trying to ensure that a) there's only one copy of
 every library in the distro/OS, b) all version dependencies match up,
 is *super* hard, if not impossible.  Eventually there are some very
 commonly used libraries where the simplest thing to do is to just ship
 multiple versions, but first the distro maintainer ought to make sure
 that the POSIX file locking disaster you mention can't happen as a
 result.


If I may ask, because I'm confused...

Is your position on distributions trying to ensure that there is only one
copy of every library in the distribution by desiring (or even requiring
mandatory) use by distribution-distributed applications of shared
system/distribution-provided versions of libraries (instead of allowing
applications to have and use private copies of libraries) that they need
that:

(a) it is generally a good or desirable thing (albeit a super hard task);

(b) it is generally a bad or undesirable thing;

(c) you have no position either way on whether it is good or bad, you are
merely noting for the record that to do it is a super hard or even
impossible task for the distributions; and/or

(d) something else altogether (and if so what if you are willing to say)?



Also, I'm curious about your claim that there are some very commonly used
libraries where the simplest thing to do is to just ship multiple
versions.  I am *not* saying this is not the case, because I simply do not
know!  I haven't even attempted to do the research (nor am I sure how or if
the research could be easily done).  I'm certainly willing to accept that
what you say on this is true.

I am wondering however if you could identify some of these libraries and/or
the distributions which ship multiple copies of them, at least if there are
any that spring quickly to your mind.  (Note, I do *not* consider that if
you do or can not identify any such libraries or distributions that this
means your claim about them is not true!  It just means that while you
might have encountered them in the past you haven't done so recently enough
to recall them easily in response to a casual request.)



Thanks for giving me a moment of your time.  Hope this is of some use,
interest.  I look forward to seeing any response to this query you might
care to make.



Joseph
___
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] Export artifact to archive?

[Joseph R. Justice]

On Fri, Jan 3, 2014 at 12:26 PM, Roy Marples r...@marples.name wrote:

 On 03/01/2014 16:41, Lluís Batlle i Rossell wrote:

 On Fri, Jan 03, 2014 at 04:36:26PM +, Roy Marples wrote:



  Can fossil create an archive (tarball, zip file, etc) from a given
 artifact id WITHOUT using the web interface?
 Something like this is what I need:
 $ fossil archive ?ID | bzip2  distribution-version.tar.bz2


 Hi,

 fossil tarball.


 This works well, thanks.
 To use an alternate compression I can simply gunzip | bzip2 as this
 Makefile snippet shows

 FOSSILID?= current

 dist:
 fossil tarball --name ${DISTPREFIX} ${FOSSILID} ${DISTFILEGZ}
 gunzip -c ${DISTFILEGZ} | bzip2 ${DISTFILE}
 rm ${DISTFILEGZ}


Two comments, reading the documentation from
http://fossil-scm.org/index.html/help?cmd=tarball :



(1) It would be nice if fossil tarball could write to stdout as well as to
a specified output file; this way, the creation of $(DISTFILEGZ) as an
explicit temporary file could be avoided.  (I'm pretty sure gunzip provides
for accepting input from stdin as well as from an explicit file.)

Not having looked at the code or used fossil, I'm not sure if it would be
safe to gave fossil tarball behave this way if the value for OUTPUTFILE was
simply ommitted, or if you would have to specify that a flag (say
--to-stdout perhaps) must be specified if OUTPUTFILE was missing (this, to
avoid breaking existing scripts).



(2) It would be nice if fossil tarball could either (a) output a file only
in .tar format, either in addition to or instead of (tho this latter change
would be backwards incompatible) the existing specified *presumably*
.tar.gz format behavior, and/or (b) if you could specify a compression file
format to be used (for instance, .gz, .bzip2, .7z, etc) and perhaps in some
cases a compression level (some file formats offer multiple compression
levels along a range of fastest and least compressive to slowest and
most compressive).

If you could output in only .tar format, then the use of gunzip could be
avoided.  (And if you could output in only .tar format *and* output to
stdout, then you could pipe fossil tarball to bzip2 and avoid the creation
of an explicit temporary file.)

If you could output directly to a specified compression file format, then
the use of bzip2 could be avoided as well; fossil tarball could do it all
itself.



I note that some of these suggestions (2b at a minimum) are obviously
less-traditionally-Unix-natured.  However, they'd probably be seen as
desirable by users (or at least less programmer-type users) of other
platforms (e.g. MS Windows, Mac OS/X) where I believe the use of a command
line, etc is far less ingrained.



Thanks for your time.  Hope this is of some use, interest.



Joseph
___
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] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Fri, Jan 3, 2014 at 1:22 PM, Ron Wilson ronw.m...@gmail.com wrote:

 On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice jayare...@gmail.comwrote:



 

 Further, in the embedded software world at least, I expect it is often
 difficult or even impossible to update software in the first place to patch
 bugs or provide new functionality, so there is no need much less desire to
 worry about making it *easier* to update software; if you can't update it
 at all, or can only update it in the first place with the very greatest of
 effort for only the most critical of reasons (such as bugs which are
 potentially life-threatening or would cost untenable financial losses if
 they are not fixed), who cares if it's a only a little more difficult,
 relatively speaking, to update a library.


 Speaking as an embedded SW developer, I can tell you that the actual SW
 changes, and preparing the release package is easy. Actually making the
 release, though, is a big deal. After preparing the release package, we do
 regression testing. While a lot of this is automated, changes to physical
 inputs (switches, sensor, etc) and checking of physical outputs
 (indicators, motors, etc) is done manually, so these tests can take many
 hours. Once those tests have passed, we turn the release package over to
 the validation team, who preform their own (independently created) suite of
 tests. Once validation gives a pass, we send copies of the package to
 manufacturing and to our customer service organization. There is also
 documentation to prepare, which we can mostly complete in parallel with
 validation. (The validation team has access to the issue tickets, so we
 only need to give them a list of the ticket numbers applicable to the
 release.)

 We do use 3rd party libraries. The difference is that we have full control
 over what versions of each library are used. There is no one downstream
 from us repackaging our SW. The binaries we release are exactly what goes
 into the devices we created the SW for.


Actually...  What I was thinking of here was not anything related to
preparation of the software changes or release package, but instead the
actual deployment of the software itself into the field, and particularly
into devices which cannot be reasonably expected to be ubiquitously
networked and remotely upgradeable.  How does one update embedded software
in a VCR or DVD player, or a refrigerator, or a vehicle (car / ship /
aircraft)?  Or, for that matter, update embedded software used in an
important industrial process, such as a power plant (nuclear or otherwise),
a chemical manufacturing or processing facility, etc where failure of the
process can potentially be catastrophic so you don't *want* it to be easy
to update the software (to avoid malicious changes by third parties)?

If you have to send an actual technician out to perform an update of the
software, or perhaps worse yet expect an *end user* to do it (or even
merely enable a setting to allow it to be done remotely over a network) and
then deal with all the resulting support calls, well...  I have to think
the expense of *that* at least equals, if not easily exceeds, the expense
of preparing the update in the first place.  (All the expenses mind you,
including specifically all the ones you mention above.)  Which means you're
not going to do an update casually, or without a damn good reason to go to
the expense of getting it deployed.

I'll note however that I do not *think* this is an issue for FOSS
Unix/Linux distributions in general.  (There are distributions which have
an embedded flavor derived from them; for example, Debian has an embedded
software variant called Emdebian, see http://www.emdebian.org/ for more
information, but I highly doubt that in these cases the embedded flavor
derived distribution tail wags the primary mainstream distribution dog.)

Thanks for responding.



Joseph
___
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] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

[Top-posting considered harmful.  *cough*]

On Thu, Jan 2, 2014 at 12:40 PM, B Harder brad.har...@gmail.com wrote:
 On 1/2/14, Richard Hipp d...@sqlite.org wrote:

 The silly requirement of some distributions that *everything* must be a
 shared library irks me beyond words.  I hate having to support
 --disable-internal-sqlite, and I hate having to add silly work-arounds in
 the code to accommodate distributions trying to use an older SQLite with
a
 newer Fossil.  This impedes progress and introduces bugs.  It's a
lose-lose
 situation.  And yet the distributions are dogmatic on this point.

 It's maddening.  It makes my hair turn gray.  It irks me more than seeing
 the noun data used as a plural.  Utter madness!

 But we live in a fallen world.  We have to do it.  Please go ahead and
 merge.


 _WHY_ does --disable-internal-sqlite (and the unknown versions of
 SQLite that follow) have to be supported ?

 If package/OS maintainers insist on hacking in alien shared-lib
 SQLite, let them own their hacks and the repercussions.

 Call it a major version# bump, and remove that support.


I never did research this for y'all.  I should do that...

Again...  My understanding, as an external observer of some FOSS Linux/Unix
distributions (primarily / especially Debian), e.g. *not* as someone
currently actively involved in maintaining a distribution, packaging
software for it, etc, is that distributions want to minimize the number of
different and distinct source-code copies of a given chunk of software (a
library for instance) found amongst all the pieces of software they
distribute.

They want to minimize the number of source-code copies to make it easier
for them to maintain all the different software packages in the
distribution, by insuring that if a given piece of software needs to change
(say to update it to a new version to provide new functionality, or to
patch a bug (especially a security-related bug!) in an existing version
that causes the software or something depending on / using the software to
malfunction), they (ideally at least) only have to change the software in
one place, and then update as necessary any and all other software
depending on the newly-changed software to use that newly-changed version.
(If the newly-changed software maintains the same ABI as the previous
version of it, this might require no changes at all, or at most a change in
the packaging meta-information; if there is an ABI change but the API stays
the same this will probably require a re-compilation and re-linking; if
there is an API change this might require changes to the source code of the
other software to accommodate the API changes.)

One way they minimize the number of source-code copies of software,
particularly of software that is used by other software (e.g. such as a
library like SQLite), is to require the shared software to be linked in as
a shared (e.g. not a binary or source-code embedded) library to all the
other software making use of it.

I think that, if I were ever to do the required research (which, again, I
have not done to date), I would find that most major FOSS Linux/Unix
distributions, and quite likely many of the commercial / closed-source
distributions (I speak here not merely of RHEL, SUSE, etc but also of
Solaris, HP-UX, AIX, etc), are ... I won't say dogmatic about this point,
but quite serious at the least about it, precisely because it makes their
lives easier and because they see it as a benefit to their end-users.  I
think it is not a point they would give up lightly.

I realize this is likely to be a quite different viewpoint / world view
than those coming from the embedded software world or from the MS Windows
(and probably also Apple OS/X) world have, and I suspect also commercial /
closed-source software provided for various FOSS and non-FOSS Unix/Linux
distributions, because in those worlds it is common for every piece of
application software to ship its own private copy of any library it
requires (other than libraries which can be guaranteed to be provided by
the OS vendor).

Further, in the embedded software world at least, I expect it is often
difficult or even impossible to update software in the first place to patch
bugs or provide new functionality, so there is no need much less desire to
worry about making it *easier* to update software; if you can't update it
at all, or can only update it in the first place with the very greatest of
effort for only the most critical of reasons (such as bugs which are
potentially life-threatening or would cost untenable financial losses if
they are not fixed), who cares if it's a only a little more difficult,
relatively speaking, to update a library.

Anyway.  Insofar as SQLite intends and desires to be capable of use as a
shared non-embedded library *as well as* a non-shared embedded library for
software running on Unix/Linux platforms, I expect this policy (as I've
asserted it to be) of the FOSS Unix/Linux distributions will affect SQLite
and 

Re: [fossil-users] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice jayare...@gmail.comwrote:

 [Top-posting considered harmful.  *cough*]

 On Thu, Jan 2, 2014 at 12:40 PM, B Harder brad.har...@gmail.com wrote:
  On 1/2/14, Richard Hipp d...@sqlite.org wrote:

  The silly requirement of some distributions that *everything* must be a
  shared library irks me beyond words.  I hate having to support
  --disable-internal-sqlite, and I hate having to add silly work-arounds
 in
  the code to accommodate distributions trying to use an older SQLite
 with a
  newer Fossil.  This impedes progress and introduces bugs.  It's a
 lose-lose
  situation.  And yet the distributions are dogmatic on this point.
 
  It's maddening.  It makes my hair turn gray.  It irks me more than
 seeing
  the noun data used as a plural.  Utter madness!
 
  But we live in a fallen world.  We have to do it.  Please go ahead and
  merge.
 

 _WHY_ does --disable-internal-sqlite (and the unknown versions of

 SQLite that follow) have to be supported ?

 If package/OS maintainers insist on hacking in alien shared-lib
 SQLite, let them own their hacks and the repercussions.

 Call it a major version# bump, and remove that support.


 I never did research this for y'all.  I should do that...

 Again...  My understanding, as an external observer of some FOSS
 Linux/Unix distributions (primarily / especially Debian), e.g. *not* as
 someone currently actively involved in maintaining a distribution,
 packaging software for it, etc, is that distributions want to minimize the
 number of different and distinct source-code copies of a given chunk of
 software (a library for instance) found amongst all the pieces of software
 they distribute.

 They want to minimize the number of source-code copies to make it easier
 for them to maintain all the different software packages in the
 distribution, by insuring that if a given piece of software needs to change
 (say to update it to a new version to provide new functionality, or to
 patch a bug (especially a security-related bug!) in an existing version
 that causes the software or something depending on / using the software to
 malfunction), they (ideally at least) only have to change the software in
 one place, and then update as necessary any and all other software
 depending on the newly-changed software to use that newly-changed version.
 (If the newly-changed software maintains the same ABI as the previous
 version of it, this might require no changes at all, or at most a change in
 the packaging meta-information; if there is an ABI change but the API stays
 the same this will probably require a re-compilation and re-linking; if
 there is an API change this might require changes to the source code of the
 other software to accommodate the API changes.)

 One way they minimize the number of source-code copies of software,
 particularly of software that is used by other software (e.g. such as a
 library like SQLite), is to require the shared software to be linked in as
 a shared (e.g. not a binary or source-code embedded) library to all the
 other software making use of it.

 I think that, if I were ever to do the required research (which, again, I
 have not done to date), I would find that most major FOSS Linux/Unix
 distributions, and quite likely many of the commercial / closed-source
 distributions (I speak here not merely of RHEL, SUSE, etc but also of
 Solaris, HP-UX, AIX, etc), are ... I won't say dogmatic about this point,
 but quite serious at the least about it, precisely because it makes their
 lives easier and because they see it as a benefit to their end-users.  I
 think it is not a point they would give up lightly.

 I realize this is likely to be a quite different viewpoint / world view
 than those coming from the embedded software world or from the MS Windows
 (and probably also Apple OS/X) world have, and I suspect also commercial /
 closed-source software provided for various FOSS and non-FOSS Unix/Linux
 distributions, because in those worlds it is common for every piece of
 application software to ship its own private copy of any library it
 requires (other than libraries which can be guaranteed to be provided by
 the OS vendor).

 Further, in the embedded software world at least, I expect it is often
 difficult or even impossible to update software in the first place to patch
 bugs or provide new functionality, so there is no need much less desire to
 worry about making it *easier* to update software; if you can't update it
 at all, or can only update it in the first place with the very greatest of
 effort for only the most critical of reasons (such as bugs which are
 potentially life-threatening or would cost untenable financial losses if
 they are not fixed), who cares if it's a only a little more difficult,
 relatively speaking, to update a library.

 Anyway.  Insofar as SQLite intends and desires to be capable of use as a
 shared non-embedded library *as well as* a non-shared embedded library

Re: [fossil-users] Anecdote regarding permissions tracking in Fossil

[Joseph R. Justice]

On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym
ala...@snell-pym.org.ukwrote:


 I've written a backup/archival tool based on content-addressible
 storage, and a common question people ask is So why don't I just put my
 home directory/entire filesystem in git, then?, and I have to raise
 this aspect of the quite different goals between backup and source
 control :-)


I note that there are people who *do* put their home directories, .rc
files, etc under source control.  (IIRC, I've read stories in, like, Linux
Journal, lwn.net, blog stories, etc.)  I have the distinct impression that,
often, at least part of the reason for doing this is that the user has
multiple systems they regularly use, and they wish to keep the personal
configuration details and I suppose also the personal data stored on/for
for each system as consistent between systems as is reasonably achievable
to achieve.



Joseph
___
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 running out of memory

[Joseph R. Justice]

On Fri, Aug 2, 2013 at 11:55 AM, Richard Hipp d...@sqlite.org wrote:

 On Fri, Aug 2, 2013 at 11:51 AM, Benedikt Ahrens 
 benedikt.ahr...@gmx.netwrote:


 Hello,

 I am having trouble with a fossil repository containing many binary files.

 The fossil version is the one packaged in Debian Wheezy:

 $ fossil version
 This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC

 Any hints what I could try to better debug the problem, or to even solve
 it?


 Version 1.22 is pretty old.  I suspect that this problem is already
 solved.  Just upgrade and you should be fine.


[I have intentionally CC'd the original poster with this response, on the
off-chance he is not subscribed to fossil-users.]

Debian Wheezy (a.k.a. 7.0) is the current stable version of Debian Linux.
He is using the version provided by the distribution (specifically
1:1.22.1+dfsg-0.1 -- the +dfsg-0.1 presumably refers to modifications made
by the packager to the original source code as provided by the Fossil
Project to make it acceptable for distribution in the main (as opposed to
contrib or non-free) section of Debian Linux).  Debian Wheezy was
officially released on 4 May 2013, with its first point release update on
15 Jun 2013.  (It looks like Wheezy started to be frozen in terms of
adding new software or new versions of software, so as to stabilize it for
release as the next stable version of Debian Linux, around Apr 2012, tho
not all of it was frozen at that time.)

The current version of fossil in Debian Testing (which will become the next
stable version of Debian Linux in due time) is 1:1.24+dfsg-0.1, entering
Testing on 5 May 2013, which is still two point releases behind the current
stable release of Fossil as distributed by the Fossil Project itself.



Assuming the correct / easiest way to fix the problem is to upgrade the
version of fossil being used, and assuming the original poster wishes to
continue using fossil as provided by Debian (which allows it to be managed
by the package management system, the bug tracking system, etc), he could
either:

1: Upgrade his version of fossil to the version available through Debian
Testing, which might involve changes to his system configuration -- how to
do this is outside the scope of the fossil-users mailing list, and he
should probably contact / use one or more of the resources available for
support of Debian Linux if he needs help (which is the *point* of using a
distribution-provided binary, after all).  Good places to look at would
include:

1.1: http://www.debian.org/support (talks about many different points of
contact for support, including IRC, wikis, bug reports, mailing lists, etc);

1.2: http://www.debian.org/MailingLists/ (talks about the many Debian
mailing lists for end-user support and other purposes); and specifically

1.3: http://lists.debian.org/debian-user/ (Help and discussion among users
of Debian / Support for Debian users who speak English. (High-volume
mailing list.))

2: Request that the version of fossil available in Debian Testing be
backported to Debian Wheezy, where it will be found in the
wheezy-backports repository, and then install it from wheezy-backports.
See http://www.debian.org/News/2013/20130320.en.html - Backports
integrated in the main archive for more information.

3. Request that the version of fossil in Debian Testing be upgraded to the
most recent stable version of fossil as released by the Fossil Project,
which appears to be 1.26 (per http://www.fossil-scm.org/download.html), and
then (if applicable) request this updated version be backported to
wheezy-backports.  The easiest way to do this would be to file a wishlist
bug against fossil in the Debian bug tracking system requesting the new
version be packaged and/or backported.



Alternatively, the original poster could resend the bug and/or ask for help
directly to Debian (by filing a bug against fossil in the BTS, sending a
mail message requesting help to debian-user, etc).  This might result in a
version upgrade as mentioned above, or might result in just this bug being
fixed (which fix hopefully would be sent upstream to the Fossil Project).
Since Debian is providing the binary the original poster is using, Debian
(and not the Fossil Project) is responsible for first-tier end-user
support.  (Debian presumably would forward upstream bugs and/or patches for
them which were bugs in the original source code as distributed by the
Fossil Project.)



Unfortunately, I am not currently using Debian (or any) Linux, nor am I
actively using fossil, so I myself cannot be of more direct help.  But,
that's my advice for the original poster, assuming they wish to continue to
use fossil as provided by Debian (as opposed to fossil as provided by the
Fossil Project).



Thanks for giving me some of your time by reading this response.  I hope it
is of some use, interest.  Be well.



Joseph
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

Re: [fossil-users] Q: What Unix / Linux _DISTRIBUTIONS_ Does The Fossil Project Care About?

[Joseph R. Justice]

On Wed, Jul 31, 2013 at 1:05 AM, B Harder brad.har...@gmail.com wrote:

 I'd suggest: fossil is happy to run wherever it can, and strives for
 portability wherever it can, whenever it makes sense.

 Any OS is welcome to modify/redistribute fossil in the terms described in
 the license.

Well, sure.  Portability is important; it's pretty much a necessary
prerequisite for the sort of thing I'm talking about.  And a distribution
having the *right* to redistribute fossil (or whatever software) is
necessary also, else it simply can't take the risk of redistributing it.
(And right to modify is necessary if only so the distribution can repair
bugs, etc without having to go back to the upstream author for every little
change.)

What I'm talking about is more the sort of things that make it more
difficult or less difficult for a distribution to package an application
which it can then provide to the distribution's users and support for its
users.  Some of these things might be trivial for the Fossil Project to do,
but make a big impact for distributions.  Other things might require more
effort, or even be a significant change in workflow or practice for the
Project; the Project might decide that a given change is sufficiently
beneficial that it's worth the cost to the Project of making the change,
while other things might be insufficiently helpful (or too difficult for
the Project to change) such that the Project decides to not change that
thing and require distributions using what the Project provides (in terms
of released software, etc) to just suck it up and deal.

This is all ultimately something the Fossil Project and its constituent
developers have to decide upon; no one outside the Project can force the
Project to make any given change in what the Project does or what it
provides.  The most any distribution outside the Project can do is simply
decline to package the Project's software for that distribution.  *shrug*




 It sounds to me (correct me if I'm wrong) you are asking what (or how
 many?) operating systems are going to get special consideration? Likely,
 the answer will be (as is the case with most open source software): Where
 the interests of the developers lie.

Kinda semi...  I think I'd phrase it more as (1) *if* there are any
particular distributions the developers collectively and/or individually
care about, and if so (2) *which* distributions these are.

I can do a Generally Accepted Best Practices For Upstream Authors Of
Software Being Packaged In Major Unix / Linux Distributions, which would
likely focus on the distributions I mentioned and perhaps a few more (maybe
some source-intensive distributions like Gentoo, for instance).  But I was
hoping to find out if there were any distributions that people did (or did
not) specifically care about, and which they were, so that I could be sure
to make a point of addressing those distributions in specific along with
things which apply to distributions in general and/or to most or many (if
not all) distributions.

I'll fully agree with your answer -- it usually *is* where the interests
of the developers lie.  I'm trying to find out what (if any) interests
there are, along these lines.  (It may well turn out that there isn't any
interest.  I think that'd be regrettable, but if that's what it is, so be
it.)




 For example, I'm interested in BSD (NetBSD specifically), and so I pay
 attention to how fossil behaves on it. In terms of fixes then, when I
 supply patches or bug reports, they are considered, and then appropriate
 actions are taken (patches applied or rejected, changes made, or not). I
 suspect most any other OS you're thinking of would receive the same
 consideration.

That's precisely the sort of information I'm trying to elicit!  Now I know
that there is (presumably) at least a little interest amongst the active
developers (or at least the active users -- I haven't investigated to see
if you are a developer) of Fossil for NetBSD, so that's a distribution
which probably should be covered.




With respect to Stephen Beal's followup to your response...  It's useful
(albeit in a negative way) information to know that to the best of his
recollection developers in general have not expended efforts on behalf of
any specific distribution.

I'd be curious to know what sorts of distribution-specific packages have
been distributed in the past, what distributions they were for, if they're
still available (or even perhaps still maintained by the developers in
question), etc.  Is there a list or wiki page for this somewhere?  If not,
I guess I can search the back mailing list archives for any information
available there if I have to.



I appreciate the time you and Stephan took to respond to my original
message.  Thank you both.  I also look forward to receiving any other
responses anyone might care to make.

Be well.



Joseph
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

Re: [fossil-users] Random thoughts on Fossil v2

[Joseph R. Justice]

My apologies for taking so long to respond myself, I've been a little under
the weather the last couple of days.  I appreciate the time you took in
responding to my first message on this thread.


On Tue, Jul 23, 2013 at 4:54 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice jayare...@gmail.comwrote:





 ...Some random thoughts on Fossil v2 as a library (call it libfossil2)
 and as a default client / server binary which makes use of the library
 (call it fossil2client or fossil2scm, I seem to have used both names),
 which I realize you might already know about or have thought of but just in
 case... (if only because I have a terminal case of Male Answer Syndrome)
 (and, wow, this got longer than I expected, and I apologize in advance for
 telling you in detail all about everything you Probably Already Knew and
 moreover Knew Far More About Than I Do...):


 Rabid rants are in no way excluded from participation, provided they
 remain polite ;).




 * Fossil2client should *not* expect or require libfossil2 to be compiled
 into it statically, or have an embedded copy of the source for libfossil2
 within the source of fossil2client.


 Right. My goal here is a normal library/client relationship. Static
 linking is an important option for fossil (because it's popular with users)
 but is not a requirement.


 Debian, which is the Linux distro I am most familiar with, already does
 this (or appears to anyway) with fossil v1, see
 http://packages.debian.org/jessie/fossil where the fossil binary depends
 on libsqlite3-0 (= 3.7.11 at this instant).  I don't know if fossil v1
 ships with an embedded code copy of sqlite (I haven't looked),


 Strange. Yes, fossil embeds its own. That dependency was probably
 automatically determined by a script which looks for common symbol names in
 the resulting binary.


 but if it does they're stripping it in favor of sqlite as an independent
 library object and making their binary for fossil v1 dependent on that
 independent sqlite library object.


 i suspect it's only a bookkeeping error, and that (ld fossil) on that
 system will reveal that it does not link against /usr/lib/libsqlite3.so


 I fully expect they would / will do the same with fossil2scm as a
 dependency of libfossil2.


 They'll probably do what's easiest - if it's distributed as a package
 which builds everything together (as i suspect it will be) then they'll
 probably just 'make; make install'.


I'm responding to all these together as they're related.

I fully agree that, for binaries (and sources) distributed by The Fossil
Project (e.g. via www.fossil-scm.org) for the MS Windows platform, and
likely MacOS/X, etc, static linking (modulo libraries known to be provided
by the platform itself) and providing all the necessary auxiliary libraries
(either as embedded sources or as a separate tar ball) is the way things
are done.  I also fully agree that, for binary distribution by TFP to
Unix/Linux platforms, static linking is the way things are done (especially
since I see pretty much only one generic For Linux binary being
distributed), and that for source distribution by TFP again providing all
the necessarily auxiliary libraries via one means or another is done if
only as a convenience to the person downloading so that they don't have to
try to find all the necessary parts, figure out if they have parts that are
compatible, etc.

However.  I do sincerely believe that in general, for binary (and source)
distribution of the Fossil application by independent Unix and Linux
distributions to end-users of those distributions (e.g. where an end-user
is not receiving Fossil directly from TFP but from the creator of the
distribution that end-user is using), static linking of the binary Fossil
application to the libraries it uses (and in particular to sqlite3) is not
done, and distribution of any library sources embedded within the source to
the Fossil application is not done.  Instead, the binary Fossil application
as compiled by the distribution is configured to link dynamically to a
system copy also provided by the distribution of any libraries it needs
(and in particular to the system copy of the library for sqlite3), and the
source for the Fossil application has any embedded copies of library
sources stripped out (in particular the source for the sqlite3 library) in
favor of the source to the system copy of any libraries it needs (again in
particular the sqlite3 library).  Furthermore, it is possible at least in
principle for the version of the binary Fossil application to be updated
independently of the versions of the libraries it uses (again in particular
sqlite3); the system copy of sqlite3 that is available might be an older
version or a newer version then the version of sqlite3 which TFP ships with
the source to fossil as an embedded source.

Under these circumstances, it is not possible for the Fossil binary as
distributed by an independent Unix / Linux

Re: [fossil-users] Random thoughts on Fossil v2

[Joseph R. Justice]

[Effing GMail sent this before it was fully responded to.  My fault for
writing my response using the GMail web interface instead of composing it
in a text editor like a Real Programmer would have done.]


On Thu, Jul 25, 2013 at 9:17 PM, Joseph R. Justice jayare...@gmail.comwrote:

 My apologies for taking so long to respond myself, I've been a little
 under the weather the last couple of days.  I appreciate the time you took
 in responding to my first message on this thread.


 On Tue, Jul 23, 2013 at 4:54 AM, Stephan Beal sgb...@googlemail.comwrote:

 On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice 
 jayare...@gmail.comwrote:





 ...Some random thoughts on Fossil v2 as a library (call it libfossil2)
 and as a default client / server binary which makes use of the library
 (call it fossil2client or fossil2scm, I seem to have used both names),
 which I realize you might already know about or have thought of but just in
 case... (if only because I have a terminal case of Male Answer Syndrome)
 (and, wow, this got longer than I expected, and I apologize in advance for
 telling you in detail all about everything you Probably Already Knew and
 moreover Knew Far More About Than I Do...):


 Rabid rants are in no way excluded from participation, provided they
 remain polite ;).




  * Fossil2client should *not* expect or require libfossil2 to be compiled
 into it statically, or have an embedded copy of the source for libfossil2
 within the source of fossil2client.


 Right. My goal here is a normal library/client relationship. Static
 linking is an important option for fossil (because it's popular with users)
 but is not a requirement.


 Debian, which is the Linux distro I am most familiar with, already does
 this (or appears to anyway) with fossil v1, see
 http://packages.debian.org/jessie/fossil where the fossil binary
 depends on libsqlite3-0 (= 3.7.11 at this instant).  I don't know if
 fossil v1 ships with an embedded code copy of sqlite (I haven't looked),


 Strange. Yes, fossil embeds its own. That dependency was probably
 automatically determined by a script which looks for common symbol names in
 the resulting binary.


 but if it does they're stripping it in favor of sqlite as an independent
 library object and making their binary for fossil v1 dependent on that
 independent sqlite library object.


 i suspect it's only a bookkeeping error, and that (ld fossil) on that
 system will reveal that it does not link against /usr/lib/libsqlite3.so


 I fully expect they would / will do the same with fossil2scm as a
 dependency of libfossil2.


 They'll probably do what's easiest - if it's distributed as a package
 which builds everything together (as i suspect it will be) then they'll
 probably just 'make; make install'.


 I'm responding to all these together as they're related.

 I fully agree that, for binaries (and sources) distributed by The Fossil
 Project (e.g. via www.fossil-scm.org) for the MS Windows platform, and
 likely MacOS/X, etc, static linking (modulo libraries known to be provided
 by the platform itself) and providing all the necessary auxiliary libraries
 (either as embedded sources or as a separate tar ball) is the way things
 are done.  I also fully agree that, for binary distribution by TFP to
 Unix/Linux platforms, static linking is the way things are done (especially
 since I see pretty much only one generic For Linux binary being
 distributed), and that for source distribution by TFP again providing all
 the necessarily auxiliary libraries via one means or another is done if
 only as a convenience to the person downloading so that they don't have to
 try to find all the necessary parts, figure out if they have parts that are
 compatible, etc.

 However.  I do sincerely believe that in general, for binary (and source)
 distribution of the Fossil application by independent Unix and Linux
 distributions to end-users of those distributions (e.g. where an end-user
 is not receiving Fossil directly from TFP but from the creator of the
 distribution that end-user is using), static linking of the binary Fossil
 application to the libraries it uses (and in particular to sqlite3) is not
 done, and distribution of any library sources embedded within the source to
 the Fossil application is not done.  Instead, the binary Fossil application
 as compiled by the distribution is configured to link dynamically to a
 system copy also provided by the distribution of any libraries it needs
 (and in particular to the system copy of the library for sqlite3), and the
 source for the Fossil application has any embedded copies of library
 sources stripped out (in particular the source for the sqlite3 library) in
 favor of the source to the system copy of any libraries it needs (again in
 particular the sqlite3 library).  Furthermore, it is possible at least in
 principle for the version of the binary Fossil application to be updated
 independently of the versions of the libraries it uses (again

Re: [fossil-users] Random thoughts on Fossil v2

[Joseph R. Justice]

On Mon, Jul 22, 2013 at 5:21 AM, Konstantin Khomoutov 
flatw...@users.sourceforge.net wrote:

 On Sun, 21 Jul 2013 17:01:02 -0700 (PDT) Clark Christensen 
 cdcmi...@yahoo.com wrote:



  Scripting language: I understand the Tcl roots, and I hope you would
  consider Javascript as a target.  JS seems more universal these days.
 [...]

 Please, don't.  JS is a wart right from the start -- supposedly the
 only popular programming language these days for which a book titled
 JavaScript: the good parts has been written, which actually devoted
 to teaching the prospective developers how to *not* use the
 language.


FWIW, there appear to be at least three other Xyzzy: The Good Parts books
out there now, all by O'Reilly  Associates, for PHP, Java, and HTML 
CSS.  (Of course, given the history of these particular programming
languages and technologies, the fact of this isn't necessarily doing
Javascript any favors, I admit.)

I do believe there's also a number of more recent programming languages out
there which are supposed to be nicer / better than Javascript but compile
into it, or are supposed to be safer / better subsets of full Javascript,
or whatever.  Admittedly, because these *are* more recent languages,
they're less mature and likely more unstable / likely to change and perhaps
even change non-trivially.

All this isn't to disparage your charges against Javascript.  I don't
nevessarily disagree with them.  I just think that, perhaps, things are a
little more nuanced or grey than a straight, black and white,
uncompromising stance of Javascript BAD!

And, remember, JSON (which I do believe people here are attempting to
incorporate into Fossil) stands for JavaScript Object Notation (see
http://www.json.org/ ).  Now, it's not a programming language in and of
itself, but...  *shrug*



Thanks got giving me a moment of your time by reading this.  Hope it's of
some use, interest.  Be well.



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