Re: [fossil-users] Problem with compilation under MINGW
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/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
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
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
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
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
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
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
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
[fossil-users] Problem with compilation under MINGW
After checkin [bd1151126a], compilation under MINGW produces the following error: wbld/sqlite3.o:sqlite3.c:(.text+0xe244): undefined reference to `_fossil_localtime' Previous checkins from trunk work properly. -- o-= Marcelo =-o ___ 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
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
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
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
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
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
