Re: [fossil-users] howto `grep' through old revisions
On Mon, Jan 28, 2013 at 5:37 PM, Richard Hipp d...@sqlite.org wrote: I haven't yet figure out the right syntax for doing a grep of files in the repository. The implementation should be relatively easy once the right interface is designed. Suggestions are welcomed. My 2 cents: fossil grep [--type [w][ci][tk][tm]] [--from VERSION] [--to VERSION] [--branch BRANCH] [--first|--last|--change] [FILE_GLOB ...] SEARCH_PATTERN Explanation: type - what type of artifacts to search (e.g. wcitk = wiki, file, tickets) default: ci from/to - limit the search to artifacts from this range (dates, checkins, etc.) default: only the currently checked out version (but the clean one, not the dirty state) branch - only search this branch/tag first - only show the earliest match last - only show the latest match (default) change - show every commit that changed this (either added or removed it) Not sure the --change option is possible. Also, I only use fossil for regular source control, not wiki/ticket stuff, and I have never needed the grep option, so I am just suggesting what I think may make sense, but someone who uses all this may say that this type of searching doesn't make sense to some types of content. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Latest stable release or dev release does not compile with option: --static
Hello everyone, Can't we use GnuTLS instead of openSSL ? Wget decided to use GnuTLS instead of openSSL... Best Regards K. D. Richard Hipp wrote: K. Fossil user wrote: People would like to use a DVCS everywhere with any distro with the SAME binary, not the one specific to a distro. I concur. Unfortunately, this is a function of the distro more than of the application. For example, OpenSSL seems to not support static linking and is also highly distro-dependent, so a universal binary needs to omit HTTPS support. So there are tradeoffs. Fossil has traditionally worked great on all systems, directly from sources. And the binaries are highly portable (module OpenSSL issues). Have you seen otherwise?___ 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] Latest stable release or dev release does not compile with option: --static
Hello all of you, 1/ Jan Nijtmans wrote: I agree with others' remarks, that --static doesn't make sense on modern systems any more. I do not agree with such statement. Static is important because mostly we do use two or more systems. (debian and centos for example) Darcs is static and runs everywhere... (at least for me) 2/ serious issue I've downloaded today's timeline trunk: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --static \ --json \ --markdown $ make ## all seems ok ! $ sudo make install $ fossil open fossil.fossil $ fossil update Autosync: http://www2.fossil-scm.org/ Segmentation faultrtifacts sent: 0 received: 0 $ fossil close fossil.fossil ## delete all the files... $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --json \ --markdown $ make make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. ## delete all the files... ## install OpenSSL... $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --json \ --markdown $ make ## ... HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. If someone could explain me it would be great. I've seen these issues yesterday, however I decided to wait today for another more recent source. (fossil update) Best Regards K. Jan Nijtmans wrote: 2013/1/30 Jan Nijtmans jan.nijtm...@gmail.com: The $tclconfig(TCL_LIBS) contains the -ldl, but $tclconfig(TCL_STUB_LIB_SPEC) does not, which is OK. (the stub library doesn't use dlopen, fossil does) Somehow, fossil should add -ldl here, such that the --with-tcl-stubs option works in combination with --static. Regards, Jan Nijtmans Fix committed. On most platforms --static should work again. I still have problems on Ubuntu AMD64, when using --static in combination --with-tcl-stubs option (even with the fossil_strcmp macro), but I really wonder who would want this: A static fossil binary with dynamically loading libtcl I agree with others' remarks, that --static doesn't make sense on modern systems any more. 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___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 9:35 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: I've downloaded today's timeline trunk: ...$ fossil open fossil.fossil $ fossil update Autosync: http://www2.fossil-scm.org/ Segmentation faultrtifacts sent: 0 received: 0 Can you give us more info on that, e.g. the version hash and perhaps a stacktrace? i've been using several builds from today, built with both tcc and gcc, on i386 and x64 platforms with no such problems (also updating from the same source as you). make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. That one i haven't seen in such a long time that i don't recall what caused it nor how to fix it :/. If someone could explain me it would be great. The following is from a very old post by Joe Mistachkin: --- A temporary workaround for this issue is to clone (or update) the Fossil source code and update to the release tag: fossil update release Then, while still in the Fossil source code directory, run: fossil set manifest on This should give you the correct manifest and manifest.uuid files needed to build the source code. -- I've seen these issues yesterday, however I decided to wait today for another more recent source. (fossil update) That one with manifest.uuid has come up several times before, but i thought it had long since been solved. i unfortunately don't remember what causes it, though. Ooops... but now i've got my tree in that same state (and, even worse, my only fossil binary is (was) the one from that tree, so i've got a chicken/egg problem here). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Latest stable release or dev release does not compile with option: --static
Hello, copy error in my last mail: correct copy is below : $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ## ... HTTPS support enabled Checking for readline/readline.h...not found Checking for editline/readline.h...not found Checking libs for gethostbyname...none needed Checking libs for socket...none needed Checking libs for iconv...none needed Checking for getpassphrase...not found Checking libs for getpass...none needed Checking libs for dlopen...-ldl Created Makefile from Makefile.in Created autoconfig.h make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. Best Regards K.___ 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] Latest stable release or dev release does not compile with option: --static
$ fossil update ba86c859df checkout: ba86c859dff83e89640091ea18dec5571630af2a 2013-01-31 18:12:54 UTC tags: trunk comment: Added an extern to work around a duplicate-definition linking error with the tcc compiler. (user: stephan) changes: None. Already up-to-date $ fossil set manifest on $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ## all compiles correctly, but next is a new issue: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=none \ --static \ --json \ --markdown $ make ## ... cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0 -DSQLITE_DEFAULT_FILE_FORMAT=4 -DSQLITE_ENABLE_STAT3 -Dlocaltime=fossil_localtime -DSQLITE_ENABLE_LOCKING_STYLE=0 -c ./src/sqlite3.c -o bld/sqlite3.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -Dmain=sqlite3_shell -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ./src/shell.c -o bld/shell.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/th.c -o bld/th.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/th_lang.c -o bld/th_lang.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -I. -I./src -Ibld -c ./src/cson_amalgamation.c -o bld/cson_amalgamation.o cc -DFOSSIL_ENABLE_JSON -DFOSSIL_ENABLE_MARKDOWN -g -O2 -DHAVE_AUTOCONFIG_H -o fossil bld/add.o bld/allrepo.o bld/attach.o bld/bag.o bld/bisect.o bld/blob.o bld/branch.o bld/browse.o bld/captcha.o bld/cgi.o bld/checkin.o bld/checkout.o bld/clearsign.o bld/clone.o bld/comformat.o bld/configure.o bld/content.o bld/db.o bld/delta.o bld/deltacmd.o bld/descendants.o bld/diff.o bld/diffcmd.o bld/doc.o bld/encode.o bld/event.o bld/export.o bld/file.o bld/finfo.o bld/glob.o bld/graph.o bld/gzip.o bld/http.o bld/http_socket.o bld/http_ssl.o bld/http_transport.o bld/import.o bld/info.o bld/json.o bld/json_artifact.o bld/json_branch.o bld/json_config.o bld/json_diff.o bld/json_dir.o bld/json_finfo.o bld/json_login.o bld/json_query.o bld/json_report.o bld/json_tag.o bld/json_timeline.o bld/json_user.o bld/json_wiki.o bld/leaf.o bld/login.o bld/main.o bld/manifest.o bld/markdown.o bld/markdown_html.o bld/md5.o bld/merge.o bld/merge3.o bld/moderate.o bld/name.o bld/path.o bld/pivot.o bld/popen.o bld/pqueue.o bld/printf.o bld/rebuild.o bld/regexp.o bld/report.o bld/rss.o bld/schema.o bld/search.o bld/setup.o bld/sha1.o bld/shun.o bld/skins.o bld/sqlcmd.o bld/stash.o bld/stat.o bld/style.o bld/sync.o bld/tag.o bld/tar.o bld/th_main.o bld/timeline.o bld/tkt.o bld/tktsetup.o bld/undo.o bld/unicode.o bld/update.o bld/url.o bld/user.o bld/utf8.o bld/verify.o bld/vfile.o bld/wiki.o bld/wikiformat.o bld/winhttp.o bld/wysiwyg.o bld/xfer.o bld/xfersetup.o bld/zip.o bld/sqlite3.o bld/shell.o bld/th.o bld/th_lang.o bld/cson_amalgamation.o -static -lz -ldl bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Best Regards K. Stephan Beal wrote: I've downloaded today's timeline trunk: ...$ fossil open fossil.fossil $ fossil update Autosync: http://www2.fossil-scm.org/ Segmentation faultrtifacts sent: 0 received: 0 Can you give us more info on that, e.g. the version hash and perhaps a stacktrace? i've been using several builds from today, built with both tcc and gcc, on i386 and x64 platforms with no such problems (also updating from the same source as you). make: *** No rule to make target `src/../manifest.uuid', needed by `bld/VERSION.h'. Stop. That one i haven't seen in such a long time that i don't recall what caused it nor how to fix it :/. If someone could explain me it would be great. The following is from a very old post by Joe Mistachkin: --- A temporary workaround for this issue is to clone (or update) the Fossil source code and update to the release tag: fossil update release Then, while still in the Fossil source code directory, run: fossil set manifest on This should give you the correct manifest and manifest.uuid files needed to build the source code. -- I've seen these issues yesterday, however I decided to wait today for another more recent source. (fossil update) That one with manifest.uuid has come up several times before, but i thought it had long since been solved. i unfortunately don't remember what causes it, though. Ooops... but now i've got my tree in that same
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 3:19 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere. ___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking These we warned you about at the start of this thread - they are platform-specific limitations which we can do nothing to get rid of. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] TortoiseFossil to BSD license
Hello all, I was wondering how important it would be to have TortoiseFossil BSD-licensed? Right now I stuck a GPL license as a path of least resistance simply because all the other Tortoise are GPL. I've noticed since that Veracity's is Apache licensed so I figure why not make this permissively licensed as well. Currently I can go either way, I believe, since it is so far written from scratch, but BSD and permissive licenses looks to be the preferred license in the Fossil community. There are parts of TortoiseFossil that are currently taken from the TortoiseSVN project which are: TortoiseOverlays which its license allows permissively with acknowledgement, that I can do for this. The menu icons (the ones in the popup menu, etc) seems to not allow for this as they're dual licensed GPL and the TortoiseSVN Icon License. http://code.google.com/p/tortoisesvn/source/browse/trunk/src/Resources/license.txt?spec=svn23734r=22442 My reading of the icon license is that only subversion clients can use the icons unless they are GPL so its pretty likely I'll need to look around for separate icons. And then there is the Charlie turtle which I'll have to find out more about. Thanks, Edward Blake ___ 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] TortoiseFossil to BSD license
On Thu, Jan 31, 2013 at 10:28 PM, Edward Blake edward.bl...@rovoscape.comwrote: Right now I stuck a GPL license as a path of least resistance simply because all the other Tortoise are GPL. I've noticed since that Veracity's is Apache licensed so I figure why not make this permissively licensed as well. Currently I can go either way, I believe, since it is so far written from scratch, but BSD and permissive licenses looks to be the preferred license in the Fossil community. My 0.02 Euros: in my experience people don't tend to get too riled up about specific licenses for _apps_ (provided the license in question is open), but do tend to get religious about them over _libraries_. For example, i can't imagine there would be a split in the fossil community if it suddenly went GPL (whereas there would be a huge split if sqlite3, being a widespread library, did that). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 3:28 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 31, 2013 at 10:19 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking These we warned you about at the start of this thread - they are platform-specific limitations which we can do nothing to get rid of. Wel, you could use getenv(USER) and LOGNAME instead of getpwuid(), or fork/exec/spawn id(1) to get the username. And you could use a DNS library to resolve the hostname without the benefit of local caching (unless there's a local caching server). The bigger problem is that this is something you'd risk having to do again and again every time something else in glibc ends up needing dlopen(). It's a losing battle, and even if it isn't (maybe nothing else in glibc will ever need dlopen()), philosophically it is a losing battle. So you have to build an executable per-distro -- welcome to Linux. 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] Latest stable release or dev release does not compile with option: --static
1/ GLibc and linux symbols versionning issue then... OK, thanks. 2/ runs everywhere: I mean, it should run in every plateform... but not cross platform of course. It is not about java bytecode thing... :D For example, if someone do fossil compilation with i386, then ALL i386 linux should be able to run fossil with no changes. However, as you said it, we can't deal with that... Just too bad... Best Regards K. Nico Williams wrote: $ ./configure --prefix=/usr --sysconfdir=/etc \ --with-openssl=auto \ --json \ --markdown $ make ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Well yes, using gethostbyname() and getpwuid() mean using dlopen() because that's what the name service switch in glibc does. If glibc were to always use nscd instead then this wouldn't happen. Anytime you need dlopen() you need all the run-time linker/loader machinery, and you need to be prepared to load libraries that need pthreads, and so on. Static linking is only really going to work well if you avoid dlopen() altogether. I don't understand the appeal of a binary that runs everywhere. Or, I do, but that's not easy anymore (and if you need multiple processor architectures then you really can't have this, not on Linux). On Solaris you can achieve that because of the ABI compatibility guarantee, as long as interfaces don't get EOFed on you. On Linux it ought to be the same, but because Linux depends on symbol versioning instead of direct binding, and because symbol versioning is typically added to libraries by the distros rather than by the open source projects themselves... you're at the mercy of the distros. If Linux were to adopt direct binding then all you'd need is common run-paths and SONAMEs, which you basically already get, and then it'd be a lot easier to build a single dynamic-linked executable that runs close enough to everywhere.___ 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] Latest stable release or dev release does not compile with option: --static
So you have to build an executable per-distro -- welcome to Linux. Is it the same with *BSD systems ? (Thank you for your tought: it's really appreciated !) Best Regards K. Nico Williams wrote: bld/shell.o: In function `find_home_dir': ./src/shell.c:2739: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bld/http_socket.o: In function `socket_open': ./src/http_socket.c:148: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking These we warned you about at the start of this thread - they are platform-specific limitations which we can do nothing to get rid of. Wel, you could use getenv(USER) and LOGNAME instead of getpwuid(), or fork/exec/spawn id(1) to get the username. And you could use a DNS library to resolve the hostname without the benefit of local caching (unless there's a local caching server). The bigger problem is that this is something you'd risk having to do again and again every time something else in glibc ends up needing dlopen(). It's a losing battle, and even if it isn't (maybe nothing else in glibc will ever need dlopen()), philosophically it is a losing battle. So you have to build an executable per-distro -- welcome to Linux. 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] Latest stable release or dev release does not compile with option: --static
On Wed, Jan 30, 2013 at 01:33:24PM -0500, Richard Hipp wrote: For example, OpenSSL seems to not support static linking. OpenSSL only needs dynamic linkage for additional engines, e.g. to interact with hardware acceleration devices. Otherwise it is perfectly fine to statically link it. Joerg ___ 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] I suggest a lite release of fossil so --static could be used
On Thu, Jan 31, 2013 at 11:02 PM, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? That's like asking, why not have a fossil which has no networking support? and the answer is, because it would be nearly useless. On modern Linuxes the networking libraries require dynamically libraries at runtime (they will link but will emit a warning while linking and may or may not work at runtime). The static limitations have NOTHING to do with fossil itself and EVERYTHING to do with the platform you are building it on. Along with the other links people have provided you about this topic, i recommend reading: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib.compatibility.static.html (read the first sentence) http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead (especially read the first/most highly-rated answer) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] I suggest a lite release of fossil so --static could be used
On Thu, Jan 31, 2013 at 10:02:59PM +, K. Fossil user wrote: in another word it is not possible to link staticly... For little project, no hardware acceleration devices does not hurt. But, for projects that need secure connections with numerous users, it will be crucial. Let imagine accountants that need speed secure connections ... Eh. No. Fact checking, have you *seen* crypto acceleration hardware lately? Most people having enough load to require them would switch to a separate web server first (like nginx), which provides SSL session caching. That alone is removes the majority of PK cryptography and in turn, the need for specialised hardware. Joerg ___ 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] Latest stable release or dev release does not compile with option: --static
On Thu, Jan 31, 2013 at 08:34:13PM +, K. Fossil user wrote: Can't we use GnuTLS instead of openSSL ? Wget decided to use GnuTLS instead of openSSL... The only real improvement GNU TLS provides over OpenSSL is GPL compatibility for Linux distributions. Otherwise it is just as messy as OpenSSL. Whether GPL compatibility is useful is a separate question and shouldn't be discussed on this list. Joerg ___ 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] I suggest a lite release of fossil so --static could be used
1/ RedHat is a company that needs to earn money. If static compiling is used then few people may need to buy their products. If you read what is written, it is not said IMPOSSIBLE. It is said DISCOURAGED, which is TOTALLY not the same. As I said, it should be possible to dynamically linking, but I NEVER said that it must be possible. What RedHat said is a commercial discuss which have nothing to do with my discuss. Most people do not need a total secure software because it is not relevant in most software. if it is not commercial discuss for you, then tell me why I ALWAYS compile static EVERY TIME it is possible with EVERY software ? Why does fsck have a static binary ? Why do I see static binary in some official package ? portableapps.org have binary that runs everywhere with windows plateform... Why ? 2/ I do compile with static option ON when it is possible. This is evidence that RedHat is untrue. Is it important that the binary is less bigger, less slower at startup and so on ? NO. What is important for users is that it should run everywhere. Not in a special distro which release is X.Y.Z-i786DX. What people need is that you just open the package every where in a folder and do: ./commandtorunbinaryenter and that's it. 3/ CVS is used by few people because in the past they forget to meet people's need. SVN takes over them... Now I do use git, because it is far better than subversion... 4/ We don't always need network support with SSL... I can create the fossil file locally and then send my work via SSH (sFTP, etc.)... Best Regards K. Stephan Beal wrote : Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? That's like asking, why not have a fossil which has no networking support? and the answer is, because it would be nearly useless. On modern Linuxes the networking libraries require dynamically libraries at runtime (they will link but will emit a warning while linking and may or may not work at runtime). The static limitations have NOTHING to do with fossil itself and EVERYTHING to do with the platform you are building it on. Along with the other links people have provided you about this topic, i recommend reading: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/lib.compatibility.static.html (read the first sentence) http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead (especially read the first/most highly-rated answer) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] I suggest a lite release of fossil so --static could be used
Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? That's like asking, why not have a fossil which has no networking support? and the answer is, because it would be nearly useless. On modern Linuxes the networking libraries require dynamically libraries at runtime (they will link but will emit a warning while linking and may or may not work at runtime). I'm not sure if I understand what's being said, but if I do, I would disagree that Fossil sans networking support would be nearly useless. I use Fossil locally exclusively. I may be in the minority. I do not know. ^K ___ 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] I suggest a lite release of fossil so --static could be used
You do understand what Stephan said. It is not what I've said, it is what Stephan said... I agree with you. I do not use network either... However, my discuss is more about the fact that people do care about the way how they may use it without dependencies... Less dependencies means less installs and less issue because some dependencies are not found or are hard to find... Best Regards K. De : k...@lightpowered.org k...@lightpowered.org À : fossil-users@lists.fossil-scm.org Envoyé le : Vendredi 1 février 2013 0h49 Objet : Re: [fossil-users] I suggest a lite release of fossil so --static could be used Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? That's like asking, why not have a fossil which has no networking support? and the answer is, because it would be nearly useless. On modern Linuxes the networking libraries require dynamically libraries at runtime (they will link but will emit a warning while linking and may or may not work at runtime). I'm not sure if I understand what's being said, but if I do, I would disagree that Fossil sans networking support would be nearly useless. I use Fossil locally exclusively. I may be in the minority. I do not know. ^K ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] I suggest a lite release of fossil so --static could be used
on Jan 31, 2013, K. Fossil user ticketpersonnal-fos...@yahoo.fr wrote: You do understand what Stephan said. It is not what I've said, it is what Stephan said...I agree with you. P.S.: Next time you received a mail from Fossil just click on the button called [reply to all], otherwise I [or someone else] will the only guy that may receive the mail... :-) Best Regards K. Yes, my mistake apology. :) I was confused by the similarity in our name configuration of email. :P ^K ps: I just did it again. The name similarity masked the real problem; your email address comes in the from field. I'm used to fossil-users@ being in the from address of mailing list emails. De : K k...@lightpowered.org À : ticketpersonnal-fos...@yahoo.fr Envoyé le : Vendredi 1 février 2013 0h45 Objet : Re: [fossil-users] I suggest a lite release of fossil so --static could be used Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? That's like asking, why not have a fossil which has no networking support? and the answer is, because it would be nearly useless. On modern Linuxes the networking libraries require dynamically libraries at runtime (they will link but will emit a warning while linking and may or may not work at runtime). I'm not sure if I understand what's being said, but if I do, I would disagree that Fossil sans networking support would be nearly useless. I personally use Fossil locally exclusively. ^K ___ 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] TortoiseFossil to BSD license
On Thu, Jan 31, 2013 at 4:35 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Jan 31, 2013 at 10:28 PM, Edward Blake edward.bl...@rovoscape.com wrote: Right now I stuck a GPL license as a path of least resistance simply because all the other Tortoise are GPL. I've noticed since that Veracity's is Apache licensed so I figure why not make this permissively licensed as well. Currently I can go either way, I believe, since it is so far written from scratch, but BSD and permissive licenses looks to be the preferred license in the Fossil community. My 0.02 Euros: in my experience people don't tend to get too riled up about specific licenses for _apps_ (provided the license in question is open), but do tend to get religious about them over _libraries_. For example, i can't imagine there would be a split in the fossil community if it suddenly went GPL (whereas there would be a huge split if sqlite3, being a widespread library, did that). Fossil *was* GPL before you came on the scene, Stephen. But there was pushback on this, and so I tracked down all the contributors, got each one to sign copyright releases (or in the cases where I could track them down, removed their contributions) and converted Fossil over to BSD. BSD seems to cause fewer problems than GPL with corporate lawyers. The problem with BSD is that you really should get a signed form from each contributor stating that their contribution is BSD. This is automatic with GPL, since releasing your contributions under a compatible license is a prerequisite for viewing the code in GPL. This makes GPL great for a highly collaborative environment, with lots of contributors. BSD is more permissive (less burdensome) for readers, but that makes it a little tougher for writers since they now have to send in some paperwork. As readers tend to outnumber writers by a high multiple, I tend to go with the license that is easiest on readers: BSD. But opinions vary on this. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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 ___ 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] I suggest a lite release of fossil so --static could be used
On 1/31/2013 2:02 PM, K. Fossil user wrote: in another word it is not possible to link staticly... For little project, no hardware acceleration devices does not hurt. But, for projects that need secure connections with numerous users, it will be crucial. Let imagine accountants that need speed secure connections ... Why don't fossil create a lite version that could be static and the full one which will forbid the static option ? Isn't that a good idea ? I think that for static linking on Linux you may need to look at what the embedded Linux folks are doing. I think the alternate libc libraries (musl libc, uclibc, dietlibc, etc.) have static linking as an explicit design goal. -- Edward Berner ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
