Re: [fossil-users] cannot handle R records, use --full-tree error when importing from bzr
Well, it looks like i have to round trip through git anyhow, as a lot of the repos created by direct bzr fast-export | fossil import come up empty past the initial commit. Curious and curiouser. On 10 September 2014 17:47, Richard Hipp d...@sqlite.org wrote: On Wed, Sep 10, 2014 at 11:38 AM, Dömötör Gulyás dognot...@gmail.com wrote: I wish to migrate several bzr repos to fossil 1.29, and have gotten stuck at fossil telling me cannot handle R records, use --full-tree trying to import the fast-import dumps. Is there a workaround for this issue? I have seen only one reference to this issue on this ML, from last May, but no solution was offered. What can I do to solve this, short of creating an intermediate git repo? This is the first report of the issue, as far as I am aware. So there is no work-around. If you want to try to hack the Fossil import logic so that it is able to handle R (rename) records, you are welcomed to try. Be warned: The documentation for the fast-import file format is fuzzy, so you'll need to have a number of examples to figure out how it is suppose to work. Probably part of the reason that R records are not currently supported is that we never could figure out their semantics. -- 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 ___ 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] Going insane with symlinks
On 11 September 2014 01:06, Andy Bradford amb-sendok-1413003970.hefagogaedafkffga...@bradfords.org wrote: Thus said David Mason on Thu, 11 Sep 2014 00:42:09 -0400: : Daves-MacBook-Retina-784 ; cat .fossil-settings/allow-symlinks yes : Daves-MacBook-Retina-784 ; fs ci -m test New_Version: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698 I could be wrong, but I don't think the .fossil-settings apply until *after* they have been committed. So, either explicitly set: fossil settings allow-symlinks yes Prior to adding any files/links to your repository. Then add your files and make your commit. After that, the versioned setting will apply (you can remove the setting). Or, instead, commit the .fossil-settings directory before adding any other files/links. Then add your files/links and commit them. Yes, explicitly interactively setting fossil settings works... committing .fossil-settings/allow-symlinks first doesn't. This looks like a bug to me... what is the point of version-able allow-symlinks? In fact, it doesn't seem to override the interactive settings (even though it says it is), as shown in the following transcript. I also include my experiment script so you can try various versions. Note it also warns about version-able setting *int* the unset command. ../Dave --- transcript --- : Daves-MacBook-Retina-784 ; ./experiment + fossil version This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC + mkdir foo-dir + touch foo-dir/foo-file + ln -s foo-dir foo-link + mkdir .fossil-settings + echo yes + ls -ld experiment foo-dir foo-link .fossil-settings/allow-symlinks -rw-r--r-- 1 dmason staff4 Sep 11 10:11 .fossil-settings/allow-symlinks -rwxr-xr-x 1 dmason staff 593 Sep 11 10:11 experiment drwxr-xr-x 3 dmason staff 102 Sep 11 10:11 foo-dir lrwxr-xr-x 1 dmason staff7 Sep 11 10:11 foo-link - foo-dir + cat .fossil-settings/allow-symlinks yes + rm -f /Users/dmason/Fossils/foo.fossil + fossil new /Users/dmason/Fossils/foo.fossil project-id: 14926592e2d77b4a33328b87abc9149b404d0660 server-id: d771c5744b37b04889f4fac897c802366dbf7167 admin-user: dmason (initial password is b95b00) + fossil open /Users/dmason/Fossils/foo.fossil project-name: unnamed repository: /Users/dmason/Fossils/foo.fossil local-root: /Users/dmason/fs/foo/ config-db:/Users/dmason/.fossil project-code: 14926592e2d77b4a33328b87abc9149b404d0660 checkout: b20418887533f98e6af0b7f763a46f74e4754e3d 2014-09-11 14:11:29 UTC leaf: open tags: trunk comment: initial empty check-in (user: dmason) checkins: 1 + fossil settings allow-symlinks yes + fossil add .fossil-settings setting allow-symlinks has both versioned and non-versioned values: using versioned value from file .fossil-settings/allow-symlinks (to silence this warning, either create an empty file named .fossil-settings/allow-symlinks.no-warn or delete the non-versioned setting with fossil unset allow-symlinks) ADDED .fossil-settings/allow-symlinks + fossil ci -m settings setting allow-symlinks has both versioned and non-versioned values: using versioned value from file .fossil-settings/allow-symlinks (to silence this warning, either create an empty file named .fossil-settings/allow-symlinks.no-warn or delete the non-versioned setting with fossil unset allow-symlinks) New_Version: 8f913889590943e610cf58a8700c5d01ad4103d5 + fossil unset allow-symlinks setting allow-symlinks has both versioned and non-versioned values: using versioned value from file .fossil-settings/allow-symlinks (to silence this warning, either create an empty file named .fossil-settings/allow-symlinks.no-warn or delete the non-versioned setting with fossil unset allow-symlinks) + fossil add experiment foo-dir foo-link ADDED experiment ADDED foo-dir/foo-file ADDED foo-link + fossil ci -m test New_Version: c492ec888d31e96a14109cff65310ac4a2a301e9 + rm -rf ../foo-alt + mkdir ../foo-alt + cd ../foo-alt + fossil open /Users/dmason/Fossils/foo.fossil .fossil-settings/allow-symlinks experiment foo-dir/foo-file foo-link project-name: unnamed repository: /Users/dmason/Fossils/foo.fossil local-root: /Users/dmason/fs/foo-alt/ config-db:/Users/dmason/.fossil project-code: 14926592e2d77b4a33328b87abc9149b404d0660 checkout: c492ec888d31e96a14109cff65310ac4a2a301e9 2014-09-11 14:11:29 UTC parent: 8f913889590943e610cf58a8700c5d01ad4103d5 2014-09-11 14:11:29 UTC leaf: open tags: trunk comment: test (user: dmason) checkins: 3 + ls -l total 16 -rwxr-xr-x 1 dmason staff 593 Sep 11 10:11 experiment drwxr-xr-x 3 dmason staff 102 Sep 11 10:11 foo-dir -rw-r--r-- 1 dmason staff7 Sep 11 10:11 foo-link : Daves-MacBook-Retina-784 ; #! /bin/sh FOSSIL=~/Fossils/foo.fossil rm -rf foo* *~ .fossil* .fslckout $FOSSIL set -x fossil version mkdir foo-dir touch foo-dir/foo-file ln -s foo-dir foo-link mkdir .fossil-settings echo yes .fossil-settings/allow-symlinks ls -ld * .fossil*/* cat
Re: [fossil-users] how to use git to lose data
On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote: On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote: git branch -D name Eh, filesystems let you delete files. Unlike most filesystems, git lets you restore your deleted branches (yes, provided you don't gc the repo). Then just use a file system and various command line tools! But seriously, it's a philosophical difference between those who want to be able to rewrite their history to what they should have done and those who want to keep the history around to see what they did. I can understand for personal projects people might want stuff to disappear. And I can understand vandals want to make stuff disappear when they attack a system. But in a serious, large project there are often requirements for an audit trail. There is no downside to this given the cheapness of backing storage. And it can prevent all sorts of problems. In the places I work the problem tracking system entries are immutable. And while a lot of those places don't use source control for various reasons when they do use them the source changes and history of who did what and when he did it are also immutable. /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 ___ 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] How to do branching with new major versions
On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote: On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote: Sometimes we will make a check-in to trunk then later decide it doesn't belong there, so then move it into a branch. ( Isn't this only possible if no further commits have been made on the trunk? I suppose one possible fix if there have been additional commits is to reverse cherrypick out the change but that leaves the timeline without a clear visible trace of the actions. A similar option would be to cherrypick the post-goof commits to a new trunk and rename the goof + downstream commits as branch goof and then close (and maybe hide) it. Do you have a better way to do this? On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) More seriously, rebasing the upstream generally means that downstreams need some instructions on how to recover. I've been thinking that any VCS with first-class support for rebasing ought to have an option to record in a merge-like commit what has been done in a rebase operation. Something like a commit with subject Rebase, the rebase script in the message body, and, crucially, two parent commits listed: the pre-rebase head commit, and the base commit for the rebase. This would provide everything a downstream needs to recover, and it would record what happened. And it would retain live references to dead branches, thus preventing garbage collection commits that would not be reachable but for Rebase commits. I wonder if something like that could make rebase more acceptable as a concept elsewhere than git. 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] How to do branching with new major versions
On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams n...@cryptonector.com wrote: On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) Except that the original sequence of changes is preserved in the tree, not discarded at the next GC. That's an important difference. -- 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] how to use git to lose data
On Thu, Sep 11, 2014 at 10:18 AM, John Long codeb...@inbox.lv wrote: On Sat, Sep 06, 2014 at 06:05:33PM -0600, Scott Robison wrote: On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote: git branch -D name Eh, filesystems let you delete files. Unlike most filesystems, git lets you restore your deleted branches (yes, provided you don't gc the repo). Then just use a file system and various command line tools! But seriously, it's a philosophical difference between those who want to be able to rewrite their history to what they should have done and those who want to keep the history around to see what they did. I can understand for personal projects people might want stuff to disappear. And I can understand vandals want to make stuff disappear when they attack a system. But in a serious, large project there are often requirements for an audit trail. There is no downside to this given the cheapness of backing storage. And it can prevent all sorts of problems. If you want a secure audit trail then you have to send the audit records elsewhere (preferably replicate the trails too). And you have to commit the audit records to their destinations before (or otherwise atomically as) commits are incorporated into a repo. Refusing to modify history doesn't make history unmodifiable -- Merkle hash chains alone only provide integrity protection for the past, but not if the attacker controls it and the present. An attacker can always edit the history directly via SQLite3 access to the repo. Of course, anyone who has fetched the pre-edit history will notice the re-write, which is why pushing and pulling often is helpful. Alternatively you can sign commits. Then editing history breaks the signatures, thus requiring re-signing of edited commits or a signature by some authority describing what history editing took place and why. In the places I work the problem tracking system entries are immutable. And [...] Nothing can really be made immutable, but you can detect mutation. That has nothing to do with whether a VCS permits mutation, and everything to do with using Merkle hash chaining and replicating (auditing, if you wish) the chains to secure storage as soon as possible so as to make mutation detectable. Whether to permit mutation for all, some, or no branches, is a policy decision to be made. I don't think one size fits all. 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] How to do branching with new major versions
On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams n...@cryptonector.com wrote: On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) Except that the original sequence of changes is preserved in the tree, not discarded at the next GC. That's an important difference. Right, and I very much agree with that. But you're doing this without first-class support for rebase; it's a very manual process :( ___ 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] how to use git to lose data
On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams n...@cryptonector.com wrote: Nothing can really be made immutable, but you can detect mutation. No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6 release) cannot be modified in any way without changing its hash value, thus making it something different. (Unless you can mount a pre-image attack against SHA1 - let's assume that is impossible.) Object 9491ba7d738528f168657adb43a198238abde19e is immutable because changing it also changes its name, creating a new object. -- 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] how to use git to lose data
On Thu, Sep 11, 2014 at 11:18 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 11, 2014 at 12:07 PM, Nico Williams n...@cryptonector.com wrote: Nothing can really be made immutable, but you can detect mutation. No. Version 9491ba7d738528f168657adb43a198238abde19e (the SQLite 3.8.6 release) cannot be modified in any way without changing its hash value, thus making it something different. (Unless you can mount a pre-image attack against SHA1 - let's assume that is impossible.) But the repo containing it can be mutated to, for example, no longer have that commit. This can only be detected. It can't be prevented. Merkle hash chains are only one part of the detection story. Digital signatures and/or replication are another. ___ 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] how to use git to lose data
On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal sgb...@googlemail.com wrote: No, he can't. Well, he can, but he will break the hashes of other records, so any tamping will be noticed. Specifically, the Z- and R-cards detect any sort of tampering. Right. He can. If you've not pushed the commits anywhere else before the attack, and if you've not signed them, and if no one has pulled the commits elsewhere before the attack, then you can't detect it. ___ 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] how to use git to lose data
On Thu, Sep 11, 2014 at 6:33 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Sep 11, 2014 at 11:19 AM, Stephan Beal sgb...@googlemail.com wrote: No, he can't. Well, he can, but he will break the hashes of other records, so any tamping will be noticed. Specifically, the Z- and R-cards detect any sort of tampering. Right. He can. If you've not pushed the commits anywhere else before the attack, and if you've not signed them, and if no one has pulled the commits elsewhere before the attack, then you can't detect it. i'd have to see it to believe it. Hashing is not the only hurdle there. He'd have to get past Fossil's internal deltification, as well, which allows any given artifact to be used as the basis for a delta for any other (semantically unrelated) artifact (and undoing that rat's tail is largely what makes popping the top-most commit so very difficult). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 1:23 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote: Is it not possible to define an open-ended list of name-value pairs? Sure we can, but then we've got a data format nobody can predict, which doesn't sit well with me (at the API level). Projects A and B might both define the custom field foo and give them different semantics: one being a list and one being a free-form text field. The JSON API cannot know what semantics to apply to them, like it can with well-defined (non-custom) fields. As best I can determine, Fossil already demands that whomever adds custom fields take responsibility for the customized New Ticket, View Tick and Edit Ticket pages and associated TH1 apply the semantics correctly and consistently. More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. Which the JSON API has to then understand, and confirm that your customized fossil schema can deal with. That flexibility is a huge burden, in terms of implementation effort, for the JSON bits. Not impossible, just more effort than i ever felt like putting into it (because i so rarely use the ticket system). I think that the most the JSON API would not need to do more than to limit string lengths, map a JSON Query into a SQLite query and a JSON Update into a SQLite update. Then map the SQLite results into a suitable JSON response. For the query and update operations, I suggest the mapping only because it would limit what commands could be presented to SQLite. I would NOT expose Fossil to raw SQLite commands via any web interface. For the response, simply returning the raw SQLite response would be acceptable. Any integration that required more than this would allow should either interact with the Fossil CLI or use libfossil. ___ 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] fossil - JIRA hooks
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit Ticket pages and associated TH1 apply the semantics correctly and
consistently.
But the JSON API has no mechanism for the user to take over.
I think that the most the JSON API would not need to do more than to
limit string lengths, map a JSON Query into a SQLite query and a JSON
Update into a SQLite update. Then map the SQLite results into a suitable
JSON response.
That kind of thing is easy to do in a script language, but not much fun in
C :/.
For the query and update operations, I suggest the mapping only because it
would limit what commands could be presented to SQLite. I would NOT expose
Fossil to raw SQLite commands via any web interface.
What, like this?
[odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from user'
{
fossil:d600c9f85421c0972231561560cb8410589c9606,
timestamp:1410455421,
command:query,
procTimeUs:5000,
procTimeMs:5,
payload:{
columns:[count(*)],
rows:[{count(*):5}]
},
g:{
...
(Reminder to self: bug: the 'g' object in the result should not be
happening without the flag which enables it. Aha... this is almost
certainly another signed vs unsigned char/overflow bug, as the odroid has
unsigned char.)
;)
Any integration that required more than this would allow should either
interact with the Fossil CLI or use libfossil.
So far i've been punting on the ticket problem in libfossil too because
of the tight connection between tickets and th1. i really don't want
libfossil to have _any_ built-in scripting language, because no language is
a perfect fit. Still not yet sure what's going to happen in that corner of
the code.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
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] Going insane with symlinks
Thus said David Mason on Thu, 11 Sep 2014 10:14:02 -0400: committing .fossil-settings/allow-symlinks first doesn't. This looks like a bug to me... what is the point of version-able allow-symlinks? Actually, it does work. The problem isn't with the versionable setting. There is a bug, but its in fossil open, not the setting. After you open the fossil, delete the link (which is actually now a file) and then do fossil update. It should come back as a link. Andy -- TAI64 timestamp: 40005411e106 ___ 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] How to do branching with new major versions
On Thu, Sep 11, 2014 at 12:09 PM, Nico Williams n...@cryptonector.com wrote: On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams n...@cryptonector.com wrote: On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp d...@sqlite.org On the few cases when this has happened to me, I've moved goof into a new branch (typically mistake) then cherry pick the follow-on check-ins back over to trunk, assuming there are not to many of them. Eh?? That's rebasing! ;) (really) Except that the original sequence of changes is preserved in the tree, not discarded at the next GC. That's an important difference. Right, and I very much agree with that. But you're doing this without first-class support for rebase; it's a very manual process :( I would call Richard's procedure move with iterated reverse merging. Although I would generally support automation, I would still want to test the result of each merge before committing and continuing. That said, I wonder if git's rebase command makes rebasing too easy. ___ 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] how to use git to lose data
On Thu, Sep 11, 2014 at 12:18 PM, Richard Hipp d...@sqlite.org wrote: (Unless you can mount a pre-image attack against SHA1 - let's assume that is impossible.) FYI, FWIW, SHA1 seems to be deprecated. There was a summary on slashdot.org about Google planning to change Chrome's default setting for SHA1 warnings to on in an attempt to encourage websites to switch to a more secure hash algorithm. (The summary also mentioned the risk to Google in doing this, claiming that users might be inclined to switch web browsers when their current browser starts complaining about their favorite web sites.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fwd: fossil server --basename ... apparent bug
Hi, I would expect, having started a server with basename (say) http://localhost/fossil to be able to proxy URLs of the form 'GET /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename) from the URL, and respond with the logo. I understand that --basename modifies the links generated by the fossil server, but I would expect the fossil server to strip away the basename before dispatching to the code which handles each URL. I think this is a bug. Colin. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Getting configure to find openssl on FreeBSD
'Lo. The fossil build scripts seem to be unable to find openssl on FreeBSD 9.2. It has a choice of the version included with the base system (in /usr) or the version available from FreeBSD ports (/usr/local), but it can't seem to find either of them. Is there any way to get it to give more information about why it's failing to find them? $ ./configure --with-openssl=auto Host System...x86_64-unknown-freebsd9.2 Build System...x86_64-unknown-freebsd9.2 C compiler... cc -g -O2 C++ compiler... c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok Checking for uint32_t...ok Checking for uint16_t...ok Checking for int16_t...ok Checking for uint8_t...ok Checking for pread...ok Checking for tclsh...no Checking for system ssl...no Checking for ssl in /usr/sfw...no Checking for ssl in /usr/local/ssl...no Checking for ssl in /usr/lib/ssl...no Checking for ssl in /usr/ssl...no Checking for ssl in /usr/pkg...no Checking for ssl in /usr/local...no Checking for ssl in /usr...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options $ ./configure --with-openssl=/usr ... Checking for ssl in /usr...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options $ ./configure --with-openssl=/usr/lib ... Checking for ssl in /usr/lib...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options $ ./configure --with-openssl=/usr/local ... Checking for ssl in /usr/local...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options $ ./configure --with-openssl=/usr/local/lib ... Checking for ssl in /usr/local/lib...no Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options $ ls /usr/local/lib/libssl.so* /usr/local/lib/libssl.so /usr/local/lib/libssl.so.8 $ ls /usr/lib/libssl.so* /usr/lib/libssl.so /usr/lib/libssl.so.6 ... and so on. M ___ 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] Fwd: fossil server --basename ... apparent bug
On Thu, Sep 11, 2014 at 2:55 PM, Colin McCormack mcc...@gmail.com wrote: Hi, I would expect, having started a server with basename (say) http://localhost/fossil to be able to proxy URLs of the form 'GET /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename) from the URL, and respond with the logo. Why would you expect this? And what do you mean by the verb to proxy? -- 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] fossil - JIRA hooks
On Thu, Sep 11, 2014 at 1:14 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit Ticket pages and associated TH1 apply the semantics correctly and
consistently.
But the JSON API has no mechanism for the user to take over.
I do not expect the JSON API to have such a mechanism.
If I write a client program that uses the JSON API to access tickets in
Fossil, it is my responsibility to make sure my program handles my custom
fields correctly.
No different than my TH1 code being my responsibility to make sure it
handles my custom fields correctly.
The only expectations of the JSON API would be to limit the length of
strings delivered to the rest of Fossil and map queries/updates
appropriately (see below).
So, the JSON API would not need to know or care about correct use of the
custom fields. The client using the JSON API would be responsible for using
the custom fields correctly.
What, like this?
[odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from user'
{
fossil:d600c9f85421c0972231561560cb8410589c9606,
timestamp:1410455421,
command:query,
procTimeUs:5000,
procTimeMs:5,
payload:{
columns:[count(*)],
rows:[{count(*):5}]
},
g:{
Is this possible through the web interface? If so, can it be disabled?
Any integration that required more than this would allow should either
interact with the Fossil CLI or use libfossil.
So far i've been punting on the ticket problem in libfossil too because
of the tight connection between tickets and th1. i really don't want
libfossil to have _any_ built-in scripting language, because no language is
a perfect fit. Still not yet sure what's going to happen in that corner of
the code.
It just means that any app (or other library) using libfossil to access
tickets will have to be held responsible for using the custom fields
correctly. libfossil would only provide the means to access the tickets and
their fields. No validation beyond limiting string lengths. Nor any mapping
of queries or updates.
(From above) By appropriate mapping, I suggest something like:
Query JSON message: Payload is 2 lists: One of name/value pairs designating
the fields to search and describing the values to match. The other a list
of fields to return in the results.
Update/Add JSON message: Payload is a list of name value pairs designating
the fields and their values.
The response could be either just a string containing the raw response,
or a list of name/value pairs.
___
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] Getting configure to find openssl on FreeBSD
org.fossil-scm.fossil-us...@io7m.com wrote: 'Lo. The fossil build scripts seem to be unable to find openssl on FreeBSD 9.2. It has a choice of the version included with the base system (in /usr) or the version available from FreeBSD ports (/usr/local), but it can't seem to find either of them. Is there any way to get it to give more information about why it's failing to find them? I skimmed through the configure code. Looks like you need to have the subdir and file 'openssl/ssl.h' beneath the dir you specify, and the subdir and files 'lib/libssl.so' and 'lib/libcrypto.so' beneath the dir you specify. Furthermore, one of those libraries has to provide the symbol SSL_new. My (very quick and possibly wrong) read of the code is that those are exactly the pass criteria for deciding that SSL is supported on the build box using the dir your specify. Did you confirm that all those are true in your case? -- Eric A. Rubin-Smith ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Manually deleting users
I know that this goes against the philosophy of Fossil, and I realize that I am entering dirty hack territory. Nevertheless, I am wondering how I can remove a user that has made no commits, no ticket updates/additions, and no wiki updates/additions whatsoever. Is it enough to say: delete from user where login='somebody'; The reasoning is that when I converted my old repos from SVN, the script automatically added a user called root because I happened to be logged in as root at the time. This user is unnecessary and I don't want it there. I tried the above sQL and the user disappeared, but I am a bit worried about unintentionally breaking things so I reverted back to a repository backup. Any thoughts on this? Kind regards, Philip Bennefall ___ 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] Getting configure to find openssl on FreeBSD
On 2014-09-11T16:09:42 -0400 Eric Rubin-Smith eas@gmail.com wrote: I skimmed through the configure code. Looks like you need to have the subdir and file 'openssl/ssl.h' beneath the dir you specify, and the subdir and files 'lib/libssl.so' and 'lib/libcrypto.so' beneath the dir you specify. Furthermore, one of those libraries has to provide the symbol SSL_new. My (very quick and possibly wrong) read of the code is that those are exactly the pass criteria for deciding that SSL is supported on the build box using the dir your specify. Think that may be partly wrong, as that'd mean that if I specified /usr, then the following would have to exist: /usr/openssl/ssl.h ... and that's obviously not true of any of the other platforms upon which I've built fossil. I do have (where → indicates a symlink): /usr/include/openssl/ssl.h /usr/lib/libssl.so → /usr/lib/libssl.so.6 /usr/lib/libssl.so.6 /usr/lib/libcrypto.so → /lib/libcrypto.so.6 /lib/libcrypto.so.6 /usr/local/include/openssl/ssl.h /usr/local/lib/libcrypto.so → /usr/local/lib/libcrypto.so.8 /usr/local/lib/libcrypto.so.8 /usr/local/lib/libssl.so → /usr/local/lib/libssl.so.8 /usr/local/lib/libssl.so.8 The /usr/lib/*.so libraries are stripped, so doesn't appear to have any symbols, but the /usr/local/lib/*.so libraries aren't, and the ssl library definitely contains SSL_new. M ___ 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] Manually deleting users
On Thu, Sep 11, 2014 at 4:21 PM, Philip Bennefall phi...@blastbay.com wrote: I know that this goes against the philosophy of Fossil, and I realize that I am entering dirty hack territory. Nevertheless, I am wondering how I can remove a user that has made no commits, no ticket updates/additions, and no wiki updates/additions whatsoever. Is it enough to say: delete from user where login='somebody'; I think that will work fine. -- 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] Going insane with symlinks
On 11 September 2014 13:50, Andy Bradford amb-sendok-1413049836.aenikllhaaeaihnhp...@bradfords.org wrote: Actually, it does work. The problem isn't with the versionable setting. There is a bug, but its in fossil open, not the setting. After you open the fossil, delete the link (which is actually now a file) and then do fossil update. It should come back as a link. Quite right! Unfortunately, this makes it kind of difficult. And the kind of thing you'd never remember when it finally bites you. I'm sure the fix is fairly straightforward, but I can't look at it today. Fortunately, in the short term just using the setting is fine. There's also the minor bug that fossil unset allow-symlinks gives you a warning and tells you to run exactly that command! Thanks for your help... now on to figure out how to clone over ssh. ../Dave --- script follows -- #! /bin/sh FOSSIL=~/Fossils/foo.fossil rm -rf foo* *~ .fossil* .fslckout $FOSSIL set -x fossil version mkdir foo-dir touch foo-dir/foo-file ln -s foo-dir foo-link mkdir .fossil-settings echo yes .fossil-settings/allow-symlinks ls -ld * .fossil*/* cat .fossil-settings/allow-symlinks rm -f $FOSSIL fossil new $FOSSIL fossil open $FOSSIL fossil settings allow-symlinks yes fossil add .fossil-settings fossil ci -m settings #fossil settings allow-symlinks no fossil unset allow-symlinks fossil add * fossil ci -m test rm -rf ../foo-alt mkdir ../foo-alt cd ../foo-alt fossil open $FOSSIL ls -l rm foo-link fossil update ls -l ___ 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] Fwd: fossil server --basename ... apparent bug
(sorry for the funky formatting, Mailman) I wrote: I would expect, having started a server with basename (say) http://localhost/fossil to be able to proxy URLs of the form 'GET /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename) from the URL, and respond with the logo. To which Richard Hipp d...@sqlite.org replied: Why would you expect this? Well, it's more that I would expect the following to work: 1) fossil server --port 8080 --localhost --baseurl http://localhost:8080/fossil . 2) fossil server --port 8080 --localhost --baseurl http://localhost:8080/fossil H.fossil (given a cwd with an H.fossil in it) And I would expect them to work exactly as fossil server --port 8080 --localhost . does. What I find, instead, is that (2) produces a page with internal links which the fossil server itself can't follow, and that (1) produces only 404 pages. There is, as far as I can ascertain, no construction of --baseurl which will produce a workable website in conjunction with the fossil server verb. And what do you mean by the verb to proxy? By 'to proxy' I mean the act of 'going between', 'mediating between' or 'standing between' the subject and the object of another verb, in this case the verb 'to access' as in: 'I would like to access an HTML representation of an interaction with fossil by means of the HTTP protocol, without having to dedicate a port and ip address to the task'. I note that this common usage may not be consistent with the specialised usage of 'to proxy' as is found in the HTTP specs. Colin. ___ 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] Fwd: fossil server --basename ... apparent bug
I see this is essentially a duplicate of this bug: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg11051.html which was reported about 18 months ago, with a patch. On Thu, Sep 11, 2014 at 3:18 PM, Colin McCormack mcc...@gmail.com wrote: (sorry for the funky formatting, Mailman) I wrote: I would expect, having started a server with basename (say) http://localhost/fossil to be able to proxy URLs of the form 'GET /fossil/logo ...' and have fossil strip the /fossil prefix (ie: basename) from the URL, and respond with the logo. To which Richard Hipp d...@sqlite.org replied: Why would you expect this? Well, it's more that I would expect the following to work: 1) fossil server --port 8080 --localhost --baseurl http://localhost:8080/fossil . 2) fossil server --port 8080 --localhost --baseurl http://localhost:8080/fossil H.fossil (given a cwd with an H.fossil in it) And I would expect them to work exactly as fossil server --port 8080 --localhost . does. What I find, instead, is that (2) produces a page with internal links which the fossil server itself can't follow, and that (1) produces only 404 pages. There is, as far as I can ascertain, no construction of --baseurl which will produce a workable website in conjunction with the fossil server verb. And what do you mean by the verb to proxy? By 'to proxy' I mean the act of 'going between', 'mediating between' or 'standing between' the subject and the object of another verb, in this case the verb 'to access' as in: 'I would like to access an HTML representation of an interaction with fossil by means of the HTTP protocol, without having to dedicate a port and ip address to the task'. I note that this common usage may not be consistent with the specialised usage of 'to proxy' as is found in the HTTP specs. Colin. ___ 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] Getting configure to find openssl on FreeBSD
On 12 Sep 2014, at 5:06 am, org.fossil-scm.fossil-us...@io7m.com wrote: 'Lo. The fossil build scripts seem to be unable to find openssl on FreeBSD 9.2. It has a choice of the version included with the base system (in /usr) or the version available from FreeBSD ports (/usr/local), but it can't seem to find either of them. Is there any way to get it to give more information about why it's failing to find them? ./configure --debug ... And then look at config.log Cheers, Steve -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
