Re: [fossil-users] About to merge the forum-v2 branch
As far as I remember it's not possible to delete a user account in Fossil. We used to have a forum here with 65,000+ members and sometimes hundreds of fake users registering each day (not robots, humans who completed the captcha), so having to deal with that kind of thing with fossil sounds scary if you cannot delete content and users. I didn't read anything about the ability to plug in an antispam into that forum, or any kind of rate-limiting either? I'm also against the closure of this mailing list. I can't check out every web forum out there every now and then, especially if they can't keep track of what messages I've read or not and what threads I've subscribed to. But if the forum becomes the only place to discussion fossil it would at least require the ability to subscribe to it by email and get all the messages in your mailbox, including their full contents. All in all, it is also a nice feature to have in Fossil but I think it doesn't seem ready for real-world use yet. ___ 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] Ignoring files/directories in automated zip files?
Le 20/09/2017 10:04, Warren Young a écrit : On Sep 19, 2017, at 3:22 PM, BohwaZ wrote: But I'm not sure if I want to implement that in Fossil just because another unrelated piece of software makes bad decisions… I think you have *two* uses of zip/tarball here, not one: Fossil’s built-in mechanism for providing checkouts to people who can’t/won’t install Fossil, and your release distribution mechanism. If you want Fossil to be your HTTP file server for the latter case, use its unversioned files feature from within your “make dist” implementation. The Fossil project works this way: the Downloads page contents on fossil-scm.org are not dynamically built, they’re static unversioned files. In Fossil anyone could just create a make recipe to generate a proper ZIP file and sync it in the unversioned files instead. That’s the province of your build system. Fossil is not a release engineering tool. Fossil’s job stops when you tag the release. Everything after that belongs to someone else, like Automake. Fossil may then re-enter the picture with “fossil uv”, but that’s a separate matter. Yes I completely agree with you, this seems to be the right way of doing things, it just requires more work on my side to adapt to Composer ;) ___ 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] Ignoring files/directories in automated zip files?
On Sep 18, 2017, at 6:49 PM, BohwaZ wrote: I'm looking at ignoring some files when an archive (zip/tarball) is created by Fossil. What’s a good example where you’d want to do that? In PHP package manager, composer (equivalent to gem in Ruby), the complete package repository is cloned and included in the project. This means that a bunch of tests, docs etc. will be included in every project. This is bad as you have to download and store useless files, plus this means that security wise you might end up with unsafe code that can be run by the webserver. Not good. The only way to avoid that is having Composer use your dist zip and have that zip file only contain what should be required. Though I think this is a problem of Composer, but its authors are against letting the package author decide which directories/files should be ignored: https://github.com/composer/composer/issues/1750 So I was wondering if Fossil could do the same as Git to go around that Composer shortcoming, as that would have made my life much simpler. But I'm not sure if I want to implement that in Fossil just because another unrelated piece of software makes bad decisions… In Fossil anyone could just create a make recipe to generate a proper ZIP file and sync it in the unversioned files instead. I might end up just setting up my own Composer repository that would serve pre-packaged ZIP files eventually, seems more like a proper solution. Thanks for your help. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ignoring files/directories in automated zip files?
I'm looking at ignoring some files when an archive (zip/tarball) is created by Fossil. Git has the ".gitattributes" file (at the root of the checkout) where you can stash "export-ignore" like this: tests/* export-ignore doc/* export-ignore .gitignore export-ignore so that your tarball is created (using "git archive") without those files. Is there a way to do the same thing in Fossil? If not, would that be considered as a feature for Fossil? (I know you can use the "ex" webpage argument or -X with CLI, but that's a bit different as some random person downloading the zip/tarball won't have the files excluded.) ___ 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] Unversioned file replacement is broken?
Le 08/09/2017 12:11, Richard Hipp a écrit : On 9/7/17, BohwaZ wrote: I managed to reproduce it on a different repo, it works if you change the file (like you did), but if you just add a file that didn't change it fails: Thanks for the additional information. I think I have now found and fixed the problem. Try out the latest trunk check-in and let me know if you are still having issues. Thanks, it works! Cheers. ___ 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] Unversioned file replacement is broken?
Kia ora, I managed to reproduce it on a different repo, it works if you change the file (like you did), but if you just add a file that didn't change it fails: % echo one > test.txt % fossil uv add test.txt % fossil uv sync -v Bytes Cards Artifacts Deltas Sent: 127 1 0 0 Received: 142 4 0 0 Unversioned-file sent: test.txt Sent: 147 1 0 0 Received: 32 1 0 0 done, sent: 746 received: 593 ip: 5.135.xxx At this point everything is fine. Now I'm re-adding the exact same file, didn't touch it or edit it: % fossil uv add test.txt % fossil uv sync -v Bytes Cards Artifacts Deltas Sent: 127 1 0 0 UV-PUSH-MTIME-ONLY: test.txt Received: 212 5 0 0 Unversioned-file sent: test.txt Sent: 143 1 0 0 Received: 32 1 0 0 done, sent: 738 received: 631 ip: 5.135.xxx Now the file is 0 bytes in the remote repo. If I change the file contents it works. So the problem only happens when I overwrite a file that hasn't changed. I hope this is helpful. On 8/30/17, BohwaZ wrote: Hey, I'm trying to update an unversioned file in my repo, so I do: # first add fossil uv add file.zip fossil uv sync # updating the file fossil uv add file.zip fossil uv sync And now the file is 0 bytes? I'm having trouble reproducing the problem. When I followed the steps above it worked fine for me. Here is a copy/paste of my shell: drh@bella:~/fossil/m1/www$ echo one >test.txt drh@bella:~/fossil/m1/www$ fossil uv add test.txt drh@bella:~/fossil/m1/www$ fossil uv sync -v Bytes Cards Artifacts Deltas Sent: 127 1 0 0 Received:4842 72 0 0 Unversioned-file sent: test.txt Sent: 147 1 0 0 Received: 32 1 0 0 done, sent: 720 received: 1804 ip: 45.33.6.223 drh@bella:~/fossil/m1/www$ echo two >test.txt drh@bella:~/fossil/m1/www$ fossil uv add test.txt drh@bella:~/fossil/m1/www$ fossil uv sync -v Bytes Cards Artifacts Deltas Sent: 127 1 0 0 UV-PUSH: test.txt Received:4912 73 0 0 Unversioned-file sent: test.txt Sent: 147 1 0 0 Received: 32 1 0 0 done, sent: 719 received: 1842 ip: 45.33.6.223 And if you look at https://www.fossil-scm.org/fossil/uv/test.txt you can clearly see that it is the revised "test.txt" that got synced. Do you have any additional information on how to cause this problem? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Unversioned file replacement is broken?
Hey, I'm trying to update an unversioned file in my repo, so I do: # first add fossil uv add file.zip fossil uv sync # updating the file fossil uv add file.zip fossil uv sync And now the file is 0 bytes? This seems to work normally: # first add fossil uv add file.zip fossil uv sync # delete fossil uv rm file.zip fossil uv sync # re-add fossil uv add file.zip fossil uv sync But if you don't sync between removal and add, the 0 bytes bug is happening. Maybe we are not supposed to update unversioned files? In that case maybe fossil should say it instead of overwriting the existing file with an empty one. Cheers, BohwaZ ___ 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] Ability for user to edit the contact info?
Furthermore, the way I use Fossil, I don't want there to be such a mechanism, because I do not want users falsifying their contact information. You are welcomed to try to add the new capability, but make sure it is off by default and that some kind of new permission letter is required in order to enable it, please. Well they would falsify it when subscribing no? Ah maybe you mean that only you can create new user on your repo. On my setup, anyone can create an account, I have a python script that then sends emails when there's changes to their tickets, so it makes sense to be able to change your details, especially as I don't want to have to do that for the hundreds of users we have. But I get your point. If I find time to implement that I'll do it via a new capability that would be off by default. Cheers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ability for user to edit the contact info?
I couldn't find any way for a user to edit his/her own email address (contact info), doesn't seem to be in /my page. Is there a "hidden" way? If not it would be nice to add that :) Tell me if you need me to add a ticket. Cheers. ___ 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] PHP Composer support for Fossil
Just to tell you that the patch has been merged and the current Composer release allows you to use Fossil repos right now :) Cheers, -- bohwaZ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SublimeText plugin VCS Gutter support for Fossil
If you are using SublimeText (2 or 3), you can now see what you changed from the checkout using the VCS Gutter plugin, as I just patched it to include support for Fossil. The patch: https://github.com/bradsokol/VcsGutter/pull/36 Download link: https://github.com/bohwaz/VcsGutter/archive/fossil.zip Installation: cd ~/.config/sublime-text-2/Packages git clone -b fossil git://github.com/bohwaz/VcsGutter.git "VCS Gutter" Hope it will be useful to others :) Cheers. -- bohwaz ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Deleting user?
Hi, Is it possible to delete a user from the database? I've got quite a lot of ghost users (mainly spammers and hack attempts), that never posted or contributed anything and I want to delete their accounts but can't find any way to do that. -- BohwaZ ___ 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] Painful team interaction with fossil, how to improve?
Le Thu, 13 Feb 2014 20:44:43 +0400, Justin Forest a écrit : > I wrote a Python script that helps myself deal with this. It looks > at all tickets and emails all participants with all comments and > changes since their last reaction. > > It also emails users specified in the "responsible" ticket field > (which you can add in /tktsetup_tab), thus I can assign tickets to > users and they get emailed without having to comment first. > > It also sends all changes to an email address specified in the > FOSSIL_CC environment variable, for archiving purpose. > > I tried using the ticket hooks branch, but found it easier to just > query the repository every 5 minutes with a cron job (also, this > saves me from maintaining another web app that would handle the hook > requests). I run the script on the same machine that Fossil > databases are, so there are no performance or load issues. > > In case this sounds helpful, you can inspect the script here: > > <http://code.umonkey.net/fossil-extras/file/tip/fossil-ticket-notify.py> > > Or download it: > > <http://code.umonkey.net/fossil-extras/raw-file/tip/fossil-ticket-notify.py> That's awesome! Just what I needed. I actually only use the JSON API to get last tickets edits and send the change to a mailing list, but sending to ticket participants is what I was looking for, thanks! -- BohwaZ signature.asc Description: PGP signature ___ 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] RFC before trunking 'usage' command
Le Wed, 11 Sep 2013 22:58:56 +0200, Stephan Beal a écrit : > If you don't find the idea offensive/abusive, you needn't say > anything. If you do, please voice your concerns. If there is > sufficient outcry i'll drop that branch instead of integrating it. If > we do decide to add it, i will add a config option to toggle it on > and off (disabled by default). I don't think I have any use for that as my shell history already provides that, but it's ok as long as it's not turned on by default and we can clear the history, like before copying a repository file to publish it online. Logging arguments may pose some risk as if you do: $ fossil remote-url https://bohwaz:secretpassw...@fossil.dev.org/ (yes you can omit the password and fossil will ask you for it, I know) The password will be logged in cleartext fossil in that case, and that may be a problem. > PS: feel free to suggest a better command name than 'usage'. 'history' > would be the obvious choice (due to it's analog in Unix shells), but > that command name potentially has better uses in a future fossil > version, so i don't want to steal that one. 'cmdhist' seems fine for me, as I would think that 'history' provides the history of last checkins, and 'usage' would provide me with some help on fossil command line. -- BohwaZ ___ 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] Random thoughts on Fossil v2
Le Mon, 22 Jul 2013 10:02:47 +0200, Stephan Beal a écrit : > The problem is the interpreter. i am not aware of a small embedable JS > interpreter. SpiderMonkey/Jaegermonkey are complex and poorly > documented. Google V8 is nice but (A) huge, (B) C++, and (C) they > recently made drastic API changes which invalidated every single > v8-using client out there (breaking 4-5 years of accumulated code of > mine, and i'll never have the time to fix it), which means that very > few people outside of Google can actually use v8 at the moment. JS > _would_ also be my first choice, if we only had a small, > well-maintained interpreter.i don't know TCL, but the TCL and Fossil > communities seem to be cosmically bound to one another. There are > relatively few well-established small/embeddable interpreters. Lua, > TCL, ... none others come to mind (which are small). I heard one time of a small JS interpreter, probably from the Dillo browser project, called SEE or Simple ECMAScript Engine. It's also used in the hv3 web browser (TCL/Tk browser). Although it seems unmaintained (last release in 2009), I found a new project of a compact ECMAscript engine called duktape http://www.samivaarala.com/#duktape > Stable incremental numbers are literally not possible to solve for > DCVS systems, which is why the SHA's (geeky/unwieldy as they are) are > used. There is out there other encoding algorithms to replace hexa though, like Bubble Babble which produces pronouceable words (and includes a checksum), but it produces long strings. So I'm not sure it would be more practical to speak about ticket 'xesaf-lenaf-denyk-gisof-gosik-guxex' rather than ticket '07d2dd143d'. Although it would make your weekly meetings sound interesting :) -- BohwaZ| boh...@bohwaz.net | http://bohwaz.net/ --- .oO[ Une citation au hasard ... En amour, l'important c'est la rencontre et la rupture, entre les deux, ce n'est que du remplissage. ... http://bohwaz.net/misc/fortune ]Oo. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil Delta algorithm ported in PHP
Hi guys,
I have ported the Fossil delta algorithm to PHP from the C code.
I was looking for a usable and light delta algorithm for PHP without
having to install a PHP extension (like xdiff is available but only as
a PECL extension), because I have to ship PHP apps to people that can't
manage the installed extensions (they often use mass hosting providers).
And I have to admit that I found no PHP implementation of a delta
algorithm.
I looked at different delta algorithms and the one used in Fossil
seemed simple and powerful enough, as well as being well-documented,
and because I use Fossil and SQLite everyday and enjoy their
reliability I trust the algorithm to be as well-written and efficient
as they are.
So here it is:
http://fossil.kd2.org/kd2fw/artifact/35c4f172ad2977cc0c4f06e29b4b8e473bcdee37
A simple example of use:
create(
file_get_contents('orig.txt'),
file_get_contents('target.txt')
);
file_put_contents('delta.txt', $d);
?>
It's a first shot, trying to port directly from C to PHP, my first
hope was to have something that would work, and it actually works. But
it's probably not very efficient and it's quite slow with large binary
blobs. So there's probably a lot of room for improvement because I'm
not very familiar with C types and PHP has a very special way (some may
say a very PHP way) of handling integers so all the code concerning
integers might look a bit hacky, sorry for that. If you have any idea
on how to improve my bad handling of integers, feel free.
I wrote this to be able to store deltas between revisions of text
content for a PHP wiki, but if that may be of any use to anybody: just
use it.
Cheers,
--
BohwaZ
___
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] WYSIWYG editing
I tried to edit the sandbox page with my firefox browser (which have javascript disabled for security reasons), and it showed me the WYSIWYG interface, I was able to edit text but not use the toolbar. But when I saved, the page was emptied. I think you should default to Markup editor if javascript is disabled. A simple rule we use in web development is to use Javascript to enhance user experience but not as something mandatory, because there is so many reasons the javascript may be broken (disabled, old browser, recent browser with weird bug, slow internet connection, mobile phone browsing, visually impaired user, etc.). For example here the toolbar should be created on document load with javascript instead of being raw HTML. I'm also concerned about HTML code generated with WYSIWYG editor, is it cleaned before saving? Browsers are known to have very different HTML outputs (like IE using , and Firefox using ), and that result in awful code garbage when you want to edit the markup directly. Great that you thought about having an option to enable or disable the WYSIWYG editor :) -- BohwaZ ___ 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] Markdown engine integrated into fossil
Le Wed, 23 May 2012 12:18:52 -0400, Richard Hipp a écrit : > We appreciate your efforts on behalf of Fossil. However, let me be > very clear that any library with the name "libupskirt" has *zero* > chance of ever getting official support or recognition from the > Fossil project. Furthermore, even if you rename "libupskirt" to > something that is completely benign and inoffensive, it will be > difficult to rehabilitate the code. > > Note that after reading this far, and observing our choice of library > names, I have chosen to read no further in your post. Did you even check her branch? There is no mention of libupskirt in the code so far, so why the hell trolling on something irrelevant? -- BohwaZ ___ 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] Markdown engine integrated into fossil
Le Wed, 23 May 2012 17:59:32 +0200, Stephan Beal a écrit : > While i don't personally care for markdown's syntax, i'd be all for > seeing this make its way into the trunk just so we can finally move > past The Wiki Wars ;). Why not, as long as we still can use the actual wiki syntax alongside the markdown syntax :) I'm just waiting for the usual and stupid troll about the lib name... -- BohwaZ ___ 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] RFC: what do we do with the JSON docs?
Le Tue, 3 Apr 2012 12:54:24 +0200, Stephan Beal a écrit : > i can't promise to provide statically-generated copies. (A) i > wouldn't use them myself, so the maintenance involved would be 100% > time sink for me, (B) the nature of a JSON API excludes any clients > which cannot process JSON (e.g. static web pages), so i don't feel > compelled to make any extra effort for such clients. You can generate static pages from JSON using server-side scripts ;) That's what I do: http://dev.kd2.org/fotoo/ is using https://fossil.kd2.org/fotoo/wiki?name=about with the JSON API and generates a static page. Personally I have a smartphone with Opera Mini (so no JS), because data is very expensive here, and Opera Mini is the most widely used mobile browser in the world I think. As a web developer I can say that nobody should ever rely on JS for web. JS should enhance the experience, but not keep the user from accessing the content, which is the main stuff you want from a web page. > That simply means i can't tie in to fossil's built-in mechanism for > help. i have considered adding such a feature to the JSON API, and > even experimented with it, but (A) the help results would have to be > in JSON form (making them quite unreadable from the command line) and > (B) the API changes all the time, so maintaining the help text would > be a PITA at this point. OK I get it that's kind of a pity but ok. Another point, you're saying that the API is changing all the time, but don't you plan to make it stable at one point? We can't build anything on top of the API if it's not stable and can be changed anytime. -- BohwaZ http://bohwaz.net/ ___ 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] RFC: what do we do with the JSON docs?
Le Tue, 27 Mar 2012 18:35:03 +0200, Stephan Beal a écrit : > As most of you certainly know by now, the JSON docs have been under > active development in Google Docs since September: > > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view > > That they're in GDocs, as opposed to fossil, has always simply been a > matter of convenience. i like to write docs when i get bored and i > can do that from anywhere with gdocs. The long-term plan has always > been to port them into fossil (somewhere) once they settle down a bit. I would be happy to see them somewhere I can actually read them. I often program on my laptop, using a slow 3G connection, and Google Docs is an incredible pain to use, it never works (sometimes the IP address is blocked, sometimes the javascript doesn't load, sometimes the website doesn't load...). I'd really prefer a static wiki as I don't enable javascript as long as it's possible (it's slow), and I always need to have my programming references at hand, where they can load very fast to not interrupt my work. So whatever you plan to use to edit the doc (personally I hate all those wiki syntaxes, and markdown is even worse), please keep a standard static html copy online. I think that the best option would be to integrate some basics into fossil itself so that you can do: $ fossil help json wiki get And have a more complete reference documentation online. Because it would be coherent with the rest of Fossil. BTW thanks for the JSON API that I now use for my projects to have a simple public website which fetches a default home wiki page :) -- bohwaz ___ 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] Supporting markwon syntax for wiki
Le Fri, 13 Jan 2012 07:10:44 -0500, Jeremy Cowgar a écrit : > That is standard w/about any markup language, for example what you > typed in HTML would also appear as First line Second line. The > reasoning is that line breaks are not normal in text. Paragraph > breaks are. Thus you take the norm and make it easy, the abnormal (or > the exception) is the one that requires you do to something > differently. Who decides line breaks are abnormal? They are natural in any text processing software, like when writing emails, word processing, text editors and so on. I don't see why a markup language should ignore them. HTML is kind of a special case as it is not really similar to plain text. Markdown is meant to be similar to plain text so this line break handling is quite disturbing. And other markup languages like Textile, txt2tags and BBCode all parse line breaks naturally, so that isn't standard either. -- BohwaZ| boh...@bohwaz.net | http://bohwaz.net/ --- .oO[ Une citation au hasard ... Le travail est un meurtre en série, un génocide. Le travail tuera, directement ou directement, tous ceux qui lisent ces lignes. Dans ce pays, le travail fait chaque année entre 14 000 et 25 000 morts, plus de deux millions d'handicapés, 20 à 25 millions de blessés. C'est bien ce qui s'appelle un meurtre ! -+- Bob BLACK -+- ... http://bohwaz.net/misc/fortune/ ]Oo. ___ 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] Supporting markwon syntax for wiki
Le Fri, 13 Jan 2012 06:49:19 -0500, Jeremy Cowgar a écrit : > Fantastic. Hopefully this makes it into the trunk version of Fossil. I personally prefer the github flavored markdown because some things in Markdown are really counter-intuitive, like typing : First line Second line Displays as : First line Second line This "feature" is also present in actual Fossil wiki syntax, and I dislike it very much as users don't get why a line break doesn't display as a line break. -- BohwaZ ___ 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] compile error
Le Thu, 22 Dec 2011 15:22:50 + (UTC), urban a écrit : > Hi, > > when compiling [feed6232af], gcc 4.2.2 gives this error: > > bld/http_ssl.o: In function `ssl_open': > /mnt/sda6/Fossil-feed6232af207151/./src/http_ssl.c:215: undefined > reference to `SSL_set_tlsext_host_name' Seems that your OpenSSL lib is too old. Maybe we should put that in the source code: #if (SSLEAY_VERSION_NUMBER >= 0x00908070)&& !defined(OPENSSL_NO_TLSEXT) SSL_set_tlsext_host_name(handle,hostname); #endif (took from the W3M source code) But also make a compile warning if it's not available, and display a warning when trying to make a SSL connection without tlsext_host_name as this connection might fail because of this. -- BohwaZ ___ 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] Different rendering of wiki
Le Thu, 22 Dec 2011 01:29:41 -0600, Taylor Everding a écrit : > The rendering of the exact same wiki (same artifact number) renders > differently. As seen in the link above. > The source can be seen below the screen in the inspector. (I could > explicitly point out the differences, but I think you can see them.) > > Wiki Source: http://pastebin.com/XpuMdZT3 > > I am out of ideas for the cause of the different rendering. > Can anyone help? You should provide HTML code generated on the two different pages so that we can see if there's something different there. Or maybe there is a difference in your CSS files? -- BohwaZ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Translation
I'm wondering if there is way to translate the Fossil web interface? Is it planned? That would be nice for us, non-english speaking users. -- BohwaZ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SSL SNI support
Hi there, I tried to setup my first repository on a remote server today and I had quite a few problems with Fossil and SSL. First I had doubts about binary integrity, because it was way larger than usual, but hashs seemed to match so I tried and then I had this error: Server:https://boh...@fossil.kd2.org/garradin/ Bytes Cards Artifacts Deltas Sent: 279 4 0 0 waiting for server...fossil: relocation error: /lib/libnss_mdns4_minimal.so.2: symbol strlen, version GLIBC_2.0 not defined in file libc.so.6 with link time reference Strange... Then I tried to compile my own fossil binary and this is what happened: Server:https://boh...@fossil.kd2.org/garradin/ Bytes Cards Artifacts Deltas Sent: 279 4 0 0 waiting for server... SSL verification failed: certificate has expired Certificate received: commonName= kd2.org ... Wait, what? OK so I figured it out, my webserver uses SNI (great feature, see http://en.wikipedia.org/wiki/Server_Name_Indication ) to match the hostname to the right vhost. So if the certificate CN seen by the client is not fossil.kd2.org but kd2.org it means that the client doesn't have SNI and hits the default vhost with the default certificate. So it appears that Fossil doesn't support SNI. I did a small patch in src/http_ssl.c and it seems to work, but maybe it's not the best code for that purpose as I usually don't work in C: 214a215 > SSL_set_tlsext_host_name(ssl, g.urlName); Thanks. -- bohwaz ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
