Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/1 Andy Bradford amb-fos...@bradfords.org: ...I get this because I configure with --disable-internal-sqlite on OpenBSD. Fixed here: http://fossil-scm.org/index.html/info/c3211392da The branch timeline-utc contains another --disable-internal-sqlite - related fix (making the timeline-utc option work). Before merging this to trunk I would like some more pairs of eyes having a look at it. Anyone? Many 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] New Tree-View feature requires newer sqlite.
2014/1/2 Richard Hipp d...@sqlite.org: 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. Thanks! Actually, I agree that it's madless, but I learned to live with it. And since the solution is just one line, it's not that bad. My advice: The option --disable-internal-sqlite should only be used by package maintainers, which have exact control on which SQLite version their system has. But since the SQLite version might lag somewhat behind, requiring SQLite 3.8.2 for fossil just was a little bit too soon. But I'm happy to remove this workaround in a year or so, it shouldn't be kept forever (added a note on that). Every Fossil version should be clear on which minimum SQLite version it supports. I'm assuming 3.8.0. Regards, 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] password manager support
On Mon, Dec 30, 2013 at 5:10 PM, David Rush northwoodlo...@gmail.comwrote: If ssh-agent can work it's probably the way to go. It seems to be the most standardized amongst all the popular pass-phrase managers, at least on non-[apple|microsoft] platforms. But, as far as I can tell it only stores decrypted private keys and not any pass phrases and I don't have the resources to investigate. This is true, but assuming it actually delivers the decrypted key to its client (as opposed to performing the authentication based on information received from its client), then pass phrases could be packaged to look like keys. I know this is a sideway approach, but as best I can determine, ssh-agent is the most multi platform tool. (Last week, I came across a link to a proposed standard protocol for client applications to communicate with a pass phrase manager, but I lost it and have not been able to find it, again - at least not in the few minutes I've trying) Otherwise, I'd say to try to find the least platform specific, open source pass phrase manager and interface to that. Then, hopefully, anyone who needs it on a not-yet-supported platform could reasonably port the manager to that platform. Happy New Year ___ 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.
_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. -bch 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. On Thu, Jan 2, 2014 at 10:33 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/1 Andy Bradford amb-fos...@bradfords.org: ...I get this because I configure with --disable-internal-sqlite on OpenBSD. Fixed here: http://fossil-scm.org/index.html/info/c3211392da The branch timeline-utc contains another --disable-internal-sqlite - related fix (making the timeline-utc option work). Before merging this to trunk I would like some more pairs of eyes having a look at it. Anyone? Many 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 -- D. Richard Hipp d...@sqlite.org -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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.
[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.
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] New Tree-View feature requires newer sqlite.
* Richard Hipp: 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. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? ___ 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.
On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: 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. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it does not. But what does that have to do with static vs. dynamic linkage? -- 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] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: 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. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it doesn't. If you're using multiple copies of libsqlite3 to access the same DB file in the same process concurrently then you'll get corruption. In practice this just doesn't happen, but it's important to be on the lookout for this. Consider how that might happen by accident (as opposed to just for demonstration purposes). I imagine a plugin API for some library (think PAM) with multiple plugins... wanting to access the same DB -- or maybe the DB is the interface. That wouldn't happen, one hopes, and by and large it doesn't. Now imagine [wu]tmpx being replaced with a SQLite3 DB file... If [wu]tmpx were accessed using an in-process libsqlite3 and the library providing the [wu]tmpx functionality were itself available for static linking (or if the DB *were* the interface) *then* we'd have a situation ripe for this accident. But one could foresee this problem (hopefully) and act to head it off [various designs elided]. 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. It's fortunate, for example, that OpenSSL doesn't use POSIX file locking at all. Imagine it using SQLite3 for an OCSP response, CRL, and other caching! It's not such a stretch. Heimdal has an option to use SQLite3 for Kerberos ticket caching, and when used this happens in a library, which is itself used from a pluggable API (GSS) that is used in various operating system moving parts (e.g., LDAP). The problem with POSIX file locking and something like SQLite3 is that it's easy for all the pieces of such an accident to come to exist... by accident. The problem is that POSIX file locking is insane. Nico -- ___ 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.
On Thu, Jan 2, 2014 at 8:50 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. [...] Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it does not. But what does that have to do with static vs. dynamic linkage? Pluggable interfaces + layered software. A perfect example would be nscd (the name service cache daemon), which is pluggable (see the nsswitch.conf man page). One or more plugins might need to share some common resource (e.g., Kerberos ticket caches). If that resource is a SQLite3 DB file... and if each plugin statically links with libsqlite3... and if the nsswitch dlopen()s those plugins... then bad things may happen. Things like the nsswitch generally support loading plugins at run-time, via dlopen(). There's quite a few such plugin interfaces: PAM, nsswitch, SASL, GSS, and probably many more. All it takes is for a confluence of design events to bring two SQLite3s (or other library that uses POSIX file locking) into the same process via such plugin interfaces, locking around the same files. With respect to SQLite3 the simplest thing for you to do is to advise people to... not do that. I.e., what you're already doing. The obvious workaround for anyone wanting to use SQLite3 for things like the examples I gave is to use IPC, having a separate process just for this purpose serving access to the DB. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
