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

2014-01-12 Thread Ron Wilson
On Sat, Jan 11, 2014 at 5:32 PM, Alek Paunov a...@declera.com wrote:

 ...
 (yum: The Fedora family (CentOS, RHEL, etc) package manager is SQLite
 based).


Richard,  Belated congratulations.
___
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

2014-01-11 Thread Jan Nijtmans
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).

Thanks!
Jan Nijtmans
___
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

2014-01-11 Thread 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] Problem with compilation under MINGW

2014-01-11 Thread Alek Paunov

On 11.01.2014 20:44, Joseph R. Justice wrote:

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

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


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).



Once you have collected the leading packagers contacts already, what 
about new, low-traffic list *packag...@lists.sqlite.org* intended for:


 * coordinating packaging of SQLite and Fossil
 * help potential new packagers working for non yet covered distributions

My rationale is that the packagers often are busy with supporting few 
dozen packages and for some could turn out difficult to follow the whole 
users@l.f.o.


IMHO in general, some form of packagers forum should be beneficial for 
any wide adopted project.


Kind Regards,
Alek

P.S. I am trying to follow the Fedora development. As Josef pointed in a 
previous mail, Fedora is the main upstream of the whole family (RHEL, 
CentOS, etc) so most packaging decisions happen there.


The Fedora Packaging Guidelines explicitly _prohibit_ bundling 
practices. Every single bundling exception should be proved 
inevitable/temporary and specifically granted by FPC (Fedora Packaging 
Committee).


There are zero exceptions for SQLite bundling at the moment, and it 
would be hard to impossible one to be granted for such important system 
library (yum: The Fedora family (CentOS, RHEL, etc) package manager is 
SQLite based).


___
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

2014-01-04 Thread Richie Adler
Joe Mistachkin escribió:

 A clean build from Fossil trunk compiles fine here.  Can you please run make
 clean and try again?

That did the trick. I'll make sure to include this in my troubleshooting
before reporting a problem again -- sorry for the noise.



___
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

2014-01-04 Thread 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

2014-01-04 Thread Richard Hipp
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.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


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

2014-01-04 Thread James Turner
On Fri, Jan 03, 2014 at 10:17:47PM -0500, James Turner wrote:

[snip]

 I'll check with others but I'm not sure reliability is really the
 concern. We imported SQLite into our base tree. Because of this we try,
 when possible, to limit duplicating libraries in ports to reduce having
 to patch multiple versions of the same libraries.
 
 A good example of this is Firefox and newer software that uses WebKit.
 These projects like to ship their own copies of libraries to make their
 building process easier. For us, it just increases our headaches when
 it comes to maintaining required patches.
 
 SQLite is clearly a different case. I believe the only major patch we
 have in our tree relates to adding arc4random(3) support. If fossil
 removes --disable-internal-sqlite I highly doubt I'll be asked to
 maintain this feature in our ports tree (again I'll check with others
 and get back with you).
 
 -- 
 James Turner

I didn't get a strong outcry from other OpenBSD porters. We understand
embedding SQLite is the typical way it's used and therefor somewhat of
a different case.

We would prefer --disable-internal-sqlite to remain but again you are
the maintainers and of course must make the final decision.

-- 
James Turner
___
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

2014-01-04 Thread 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] Problem with compilation under MINGW

2014-01-03 Thread Joe Mistachkin

Richie Adler wrote:
 
 After checkin [bd1151126a], compilation under MINGW produces the following
error:
 
 wbld/sqlite3.o:sqlite3.c:(.text+0xe244): undefined reference to
 `_fossil_localtime'
 

A clean build from Fossil trunk compiles fine here.  Can you please run make
clean
and try again?

--
Joe Mistachkin

___
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

2014-01-03 Thread Richard Hipp
On Fri, Jan 3, 2014 at 9:14 PM, Richie Adler richiead...@gmail.com wrote:

 After checkin [bd1151126a], compilation under MINGW produces the following
 error:



Yes, it fails for me too

OK, so I propose the following fix:

(1) Move [bd1151126a] into a branch.
(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.
(3) Cherry-pick check-ins after [bd1151126a] onto the trunk.
(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.

Comments?


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


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

2014-01-03 Thread James Turner
On Fri, Jan 03, 2014 at 09:28:52PM -0500, Richard Hipp wrote:
 On Fri, Jan 3, 2014 at 9:14 PM, Richie Adler richiead...@gmail.com wrote:
 
  After checkin [bd1151126a], compilation under MINGW produces the following
  error:
 
 
 
 Yes, it fails for me too
 
 OK, so I propose the following fix:
 
 (1) Move [bd1151126a] into a branch.
 (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.
 (3) Cherry-pick check-ins after [bd1151126a] onto the trunk.
 (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.
 
 Comments?
 
 
 -- 
 D. Richard Hipp
 d...@sqlite.org

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 am the maintainer if you have any questions.

-- 
James Turner
___
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

2014-01-03 Thread Richard Hipp
On Fri, Jan 3, 2014 at 9:33 PM, James Turner ja...@calminferno.net wrote:


 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 am the maintainer if you have any questions.



How much push-back are we going to get from the OpenBSD community if
--disable-internal-sqlite goes away due to reliability concerns?

I appreciate the desire to keep libraries like libz and libjpeg as shared
libraries so that if security problems are encountered they can be fixed in
one place.  But those libraries are dealing with unvetted input from
untrusted sources.  SQLite does not work that way.  Any application that
allows unvetted SQL text through from untrusted sources has way worse
problems than any bugs in SQLite.  For this reason, while there have been
many bugs reported against SQLite from the field in its 14 year history, no
security vulnerabilities have ever been reported.  Not one.  This in spite
of SQLite being using in over 1 million different applications with over 2
billion deployments.  Security vulnerabilities are just not an issue like
they are with libraries that process raw user input.

Fossil also uses libz, but we have no issue with using a shared library for
that.  A version of libz is included in the Fossil source tree, but that is
merely to simplify compilation on windows systems which do not commonly
have libz handy.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


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

2014-01-03 Thread James Turner
On Fri, Jan 03, 2014 at 10:04:25PM -0500, Richard Hipp wrote:
 On Fri, Jan 3, 2014 at 9:33 PM, James Turner ja...@calminferno.net wrote:
 
 
  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 am the maintainer if you have any questions.
 
 
 
 How much push-back are we going to get from the OpenBSD community if
 --disable-internal-sqlite goes away due to reliability concerns?
 
 I appreciate the desire to keep libraries like libz and libjpeg as shared
 libraries so that if security problems are encountered they can be fixed in
 one place.  But those libraries are dealing with unvetted input from
 untrusted sources.  SQLite does not work that way.  Any application that
 allows unvetted SQL text through from untrusted sources has way worse
 problems than any bugs in SQLite.  For this reason, while there have been
 many bugs reported against SQLite from the field in its 14 year history, no
 security vulnerabilities have ever been reported.  Not one.  This in spite
 of SQLite being using in over 1 million different applications with over 2
 billion deployments.  Security vulnerabilities are just not an issue like
 they are with libraries that process raw user input.
 
 Fossil also uses libz, but we have no issue with using a shared library for
 that.  A version of libz is included in the Fossil source tree, but that is
 merely to simplify compilation on windows systems which do not commonly
 have libz handy.
 
 -- 
 D. Richard Hipp
 d...@sqlite.org

I'll check with others but I'm not sure reliability is really the
concern. We imported SQLite into our base tree. Because of this we try,
when possible, to limit duplicating libraries in ports to reduce having
to patch multiple versions of the same libraries.

A good example of this is Firefox and newer software that uses WebKit.
These projects like to ship their own copies of libraries to make their
building process easier. For us, it just increases our headaches when
it comes to maintaining required patches.

SQLite is clearly a different case. I believe the only major patch we
have in our tree relates to adding arc4random(3) support. If fossil
removes --disable-internal-sqlite I highly doubt I'll be asked to
maintain this feature in our ports tree (again I'll check with others
and get back with you).

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