date:20130820

On Tue, Aug 20, 2013 at 10:25 PM, Stephan Beal wrote:

> # cat .htaccess
> Options +ExecCGI +Indexes
> 
>  IndexOptions FancyIndexing NameWidth=*
> 
> # doesn't work on my hoster :( AddHandler cgi-script .html
> DirectoryIndex index.cgi index.php index.html
>

And...

# cat index.cgi
#!/path/to/fossil
repository: /path/to/f2.fsl

i keep all of my repos in a directory under my home, outside the webroot so
they cannot be browsed (.htaccess rules could do that, but why bother?). On
my hoster CGIs run as me, so i have that freedom. i don't know that all
shared hosters run CGIs as the account holder (but suspect that most do).

-- 
- 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] non-cgi path for CGI-based Fossil hosting

On Tue, Aug 20, 2013 at 10:10 PM, Chad Perrin  wrote:

> Given a shared hosting account where you want to host a Fossil
> repository, where following the directions for CGI-based Fossil hosting
> gives you access to the web UI via example.com/cgi-bin/access_name, I
> would like to know what techniques people use to make it available via
> something like one of the following:
>
> * example.com
> * example.com/access_name
> * access_name.example.com



# cat .htaccess
Options +ExecCGI +Indexes

 IndexOptions FancyIndexing NameWidth=*

# doesn't work on my hoster :( AddHandler cgi-script .html
DirectoryIndex index.cgi index.php index.html

Hope that helps,

-- 
- 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] non-cgi path for CGI-based Fossil hosting

2013-08-20 Thread Chad Perrin

Given a shared hosting account where you want to host a Fossil
repository, where following the directions for CGI-based Fossil hosting
gives you access to the web UI via example.com/cgi-bin/access_name, I
would like to know what techniques people use to make it available via
something like one of the following:

* example.com
* example.com/access_name
* access_name.example.com

Obviously, in the cgi-bin/access_name example, script that refers to the
fossil binary would be called "access_name".

Any help would be appreciated.

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] commit signing

On Tue, Aug 20, 2013 at 9:03 PM, John Long  wrote:

> is called gpgme (gpg made easy) IIRC. I think it's not something you have
> to
> link and you should be able to tell if it's present or not.
>

i can't personally commit to it, but maybe someone who's listening can.

> My understanding is you already compute checksums on commits.

At a lot of places. "Blob content" is referenced by its content SHA1, so
any change there invalidates it. A commit contains two checksums: one is
the checksum of the content of the checkin manifest (basically: the formal
list of changes, but not the changes themselves, similar to a PGP
signature). The second one is a checksum of the names/sizes/content of each
file in the commit manifest (basically: each file that changed). Fossil
ignores/skips over/elides the PGP wrapper for purposes of checksums.

Fossil only does PGP plaintext signing, btw, unless i'm sorely mistaken.

If that's
> true I would say if you verify any signed commit (and again it's not clear
> how multiple files are handled unless every file is signed individually)
>

The signing happens at the commit level, and a commit contains N files.

> then you should not have to do anything further, maybe not even note that
> it's PGP signed. The PGP signing is about authenticating that some user X
> is
> really the guy who did this update. Once that has been established it goes
> into the repo and nothing more has to happen.
>

There's the problem for the current architecture: "when it goes in the
repo." Let's say for a second that one of the signed commits in Fossil's
repo is currently invalid. Now we add this feature. The next time fossil is
rebuilt, it would have to reject that commit, which would break the whole
rebuild, effectively leaving us with a repo we can't upgrade because PGP
decided we shouldn't. Fossil has no useful recovery strategy there other
than to not let you rebuild the db (==update its schema to a newer version,
which also rebuilds all derivable/calculable data contained in the repo). i
think "flag and accept" would be the best Fossil could sanely do.

What i can envision is, assuming validation has hypothetically been added:

a) show yellow/green/red in the timeline, and something similar in CLI
b) a 'pgp' command which takes a list of UUIDs to verify.

But i don't think Fossil is capable of rejecting failures without seriously
endangering backwards compatibility in the case of an age-old signature
(==predating this feature) which is invalid. Maybe it could, or maybe it
could offer an option/flag to allow failed sigs or not. i'm not in any way,
shape, or form a cryptographer, i'm just thinking out loud 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

[fossil-users] Improved Git import

2013-08-20 Thread Isaac Jurado

Hello,

Now that I found a free Fossil hosting I can publish the changes I had
been experimenting with:

https://chiselapp.com/user/etanol/repository/fossil-better-import/timeline?r=git-better-import

What began as a way to correctly handle copies and renames, has ended
supporting delta manifests too.  I used two git repositories for
testing: SQLAlchemy [1] and Django [2].

[1] https://github.com/zzzeek/sqlalchemy
[2] https://github.com/django/django

The Django repository turned out to be a surprisingly complete test
subject, as it helped revealin some rename cases such as renaming or
copying a file to an already existing one, or to a file that was deleted
recently.  It also contains some paths with UTF-8 sequences in them,
which are exported as octal escape sequences by Git.

I also took the chance to compare the generated repositories, with and
without using delta manifests.  The command used to convert was:

  git fast-export --all -M -C --signed-tags=strip | fossil --delta --force 
../f-repo.fossil

After converting, each fossil repository was compacted again with:

  fossil rebuild --cluster --compress --vacuum ../f-repo.fossil

The resulting stats for SQLAlchemy, without delta manifests are:

  repository-size:   29233152 bytes (29.2MB)
  artifact-count:40045 (stored as 1079 full text and 38966 delta blobs)
  artifact-sizes:39969 average, 776048 max, 1600535301 bytes (1.6GB) total
  compression-ratio: 54:1
  checkins:  9266
  files: 1066 across all branches
  wikipages: 0 (0 changes)
  tickets:   0 (0 changes)
  events:0
  tagchanges:99
  project-age:   2973 days or approximately 8.14 years.
  project-id:06b4b25ccddefde7bfc5723a4c88f5de83281f6f
  fossil-version:2013-06-18 21:09:23 [c9cb6e7293] [1.26] (gcc-4.8.1)
  sqlite-version:2013-05-15 18:34:17 [00231fb012] (3.7.17)
  database-stats:28548 pages, 1024 bytes/pg, 0 free pages, UTF-8, delete 
mode

With delta manifests:

  repository-size:   29512704 bytes (29.5MB)
  artifact-count:40045 (stored as 1742 full text and 38303 delta blobs)
  artifact-sizes:35472 average, 776048 max, 1420465350 bytes (1.4GB) total
  compression-ratio: 48:1
  checkins:  9266
  files: 1066 across all branches
  wikipages: 0 (0 changes)
  tickets:   0 (0 changes)
  events:0
  tagchanges:99
  project-age:   2973 days or approximately 8.14 years.
  project-id:9d1199e3635399dcc0e7dc844483721069413cea
  fossil-version:2013-06-18 21:09:23 [c9cb6e7293] [1.26] (gcc-4.8.1)
  sqlite-version:2013-05-15 18:34:17 [00231fb012] (3.7.17)
  database-stats:28821 pages, 1024 bytes/pg, 0 free pages, UTF-8, delete 
mode

Which is not much of an improvement.  However, the Django case is more
impressive:

  repository-size:   92678144 bytes (92.7MB)
  artifact-count:87593 (stored as 6213 full text and 81380 delta blobs)
  artifact-sizes:64983 average, 464143 max, 5692046471 bytes (5.7GB) total
  compression-ratio: 61:1
  checkins:  21693
  files: 8153 across all branches
  wikipages: 0 (0 changes)
  tickets:   0 (0 changes)
  events:0
  tagchanges:83
  project-age:   2961 days or approximately 8.11 years.
  project-id:d8e5a69659a85d8abc2405190086a10fca66c6fb
  fossil-version:2013-06-18 21:09:23 [c9cb6e7293] [1.26] (gcc-4.8.1)
  sqlite-version:2013-05-15 18:34:17 [00231fb012] (3.7.17)
  database-stats:90506 pages, 1024 bytes/pg, 0 free pages, UTF-8, delete 
mode

And, with delta manifests:

  repository-size:   93489152 bytes (93.5MB)
  artifact-count:87593 (stored as 6862 full text and 80731 delta blobs)
  artifact-sizes:16365 average, 460946 max, 1433448191 bytes (1.4GB) total
  compression-ratio: 15:1
  checkins:  21693
  files: 8153 across all branches
  wikipages: 0 (0 changes)
  tickets:   0 (0 changes)
  events:0
  tagchanges:83
  project-age:   2961 days or approximately 8.11 years.
  project-id:7bd14b77e1396b5851bb1b3c2affaf948f01b9d0
  fossil-version:2013-06-18 21:09:23 [c9cb6e7293] [1.26] (gcc-4.8.1)
  sqlite-version:2013-05-15 18:34:17 [00231fb012] (3.7.17)
  database-stats:91298 pages, 1024 bytes/pg, 0 free pages, UTF-8, delete 
mode

The curiousity here is that when using delta manifests, the compression
ratio is lower.  Furthermore, the disk size of the repository increases
slightly.  Still, the difference in the sum of artifact sizes is huge:
5.7GB vs 1.4GB.

Anybody interested, please test to see if there are more hidden bugs to
be fixed.  But beware that the import process can be lengthy.  The
Django repository took around twenty minutes to be imported.  I
previously tried importing the glibc repository in a machine with 16GB
of RAM but, after a couple of hours, I interrumped the process.

So if any of you is considering importing th

Re: [fossil-users] commit signing

2013-08-20 Thread John Long

On Tue, Aug 20, 2013 at 08:43:36PM +0200, Stephan Beal wrote:
> On Tue, Aug 20, 2013 at 8:39 PM, John Long  wrote:
> 
> > If you're working on flagging PGP commits then it would be really nice to
> > say PGP in red if the signature doesn't verify or green if it does or
> > something like that. Otherwise saying "PGP" on a commit does more harm than
> > good imho. Personally for hosted projects I'd like to see a feature that
> > has an option to verify the signature on commits before committing them as
> > a
> > protection against unauthorized access to the repo (weak passwords, http
> > instead of https etc.)
> >
> 
> Yeah, i left the word "signed" in the hopes that it didn't apply
> "approved". Patches are of course welcomed for validation, provided they
> don't require 3rd-party deps (extern deps mean the feature must be
> optional, e.g. SSL).

I don't code in C, not even with a gun held to my head or I would be glad to
try to help. fossil is a fantastic project.

I believe there is a library put out by the gnupg project that is used
specifically for stuff like email clients to interface to gpg (the open
source version of PGP) that should have a very simple interface. I think it
is called gpgme (gpg made easy) IIRC. I think it's not something you have to
link and you should be able to tell if it's present or not.

If a commit is signed and can't be verified, it could be highlited in PGP
yellow. Green verified, red doesn't verify. That would be amazing.

> What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is
> seen at checkin or on rebuild)?

I haven't used gpg/pgp with fossil but I use gpg a lot. Thinking out loud one
workflow would be something like:

get a commit ready and sign each piece of code/whatever
push or commit
fossil sees the signature field (easily detected by standard header):

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Stephen Beal!
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSE7rJAAoJEPh15eraZbwERKIIAMG6gup+QX0s5of4ovxqjuQA
IME1rUexfBxVbi5CQGLuk/SvZYotPzbVPcWBsCVS9FW4kaP/19zP1Wpgm+SGU88/
+yOHrn7QBXNeti7lmyhFFCOoV4PqpNhlklTqASz1Ga9pm4ZhjJ1YYUfPXV0V2LDM
0VugnJCYq/QDLXZXI0z9F2/FULjgv7OfUN0dCsjwRwyzBip1tOoWIseG13en1uLm
exm8RLUNbzjE7LcYV/jUwrOzCmnFjIqSb3l6CfhPuBeLonKzO0W+jVy/QHKxY2bE
hS4dMu3vM6Op7cOfiB4bdT1jMWyIntyOBvZK0+18jRmfKRHJaSzNeSd5noZrCUI=
=xA6W
-END PGP SIGNATURE-

verifies it and commits or fails it and doesn't commit. There are two kinds
of signatures, clearsigned like above or detached (separate file). To
process a clearsigned object you strip the headers. Otherwise you validate
each file in the commit against filename.asc.

That would make things a lot simpler because once the commit hits the repo
it is a known-good commit. If it gets corrupted it's the same big problem as
any corrupted commit. But this is on a single-file level. I do not know how
you can sign commits that contain more than one file.

> Should it then reject the whole db? i don't think we have a recovery
> strategy if they fail. The best we could do is flag them in the timeline
> as passed/failed/unchecked, i think.

My understanding is you already compute checksums on commits. If that's
true I would say if you verify any signed commit (and again it's not clear
how multiple files are handled unless every file is signed individually)
then you should not have to do anything further, maybe not even note that
it's PGP signed. The PGP signing is about authenticating that some user X is
really the guy who did this update. Once that has been established it goes
into the repo and nothing more has to happen.

/jl

___
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] commit signing

On Tue, Aug 20, 2013 at 8:39 PM, John Long  wrote:

> If you're working on flagging PGP commits then it would be really nice to
> say PGP in red if the signature doesn't verify or green if it does or
> something like that. Otherwise saying "PGP" on a commit does more harm than
> good imho. Personally for hosted projects I'd like to see a feature that
> has an option to verify the signature on commits before committing them as
> a
> protection against unauthorized access to the repo (weak passwords, http
> instead of https etc.)
>

Yeah, i left the word "signed" in the hopes that it didn't apply
"approved". Patches are of course welcomed for validation, provided they
don't require 3rd-party deps (extern deps mean the feature must be
optional, e.g. SSL).

What should happen if a sign check fails? e.g. on a rebuild of a db (PGP is
seen at checkin or on rebuild)? Should it then reject the whole db? i don't
think we have a recovery strategy if they fail. The best we could do is
flag them in the timeline as passed/failed/unchecked, i think.

-- 
- 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] commit signing

2013-08-20 Thread John Long

On Tue, Aug 20, 2013 at 08:32:21PM +0200, Stephan Beal wrote:
> On Tue, Aug 20, 2013 at 8:07 PM, John Long  wrote:
> 
> > I need to go back in the archives and see where I can find an example of
> > this but in the meantime to ask the obvious, is fossil verifying the
> > signatures as part of the commit process or does fossil simply carry the
> > data so the signature can be verified manually?
> >
> 
> It simply carries them over and accounts for them while parsing manifests.
> If there is code to verify them, i haven't seen it yet.

If you're working on flagging PGP commits then it would be really nice to
say PGP in red if the signature doesn't verify or green if it does or
something like that. Otherwise saying "PGP" on a commit does more harm than
good imho. Personally for hosted projects I'd like to see a feature that
has an option to verify the signature on commits before committing them as a
protection against unauthorized access to the repo (weak passwords, http
instead of https etc.)

/jl
___
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] commit signing

On Tue, Aug 20, 2013 at 2:32 PM, Stephan Beal  wrote:

> On Tue, Aug 20, 2013 at 8:07 PM, John Long  wrote:
>
>> is fossil verifying the
>> signatures as part of the commit process or does fossil simply carry the
>> data so the signature can be verified manually?
>>
>
> It simply carries them over and accounts for them while parsing manifests.
> If there is code to verify them, i haven't seen it yet.
>
>
I don't remember ever writing any PGP signature verification code.

-- 
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] commit signing

On Tue, Aug 20, 2013 at 8:07 PM, John Long  wrote:

> I need to go back in the archives and see where I can find an example of
> this but in the meantime to ask the obvious, is fossil verifying the
> signatures as part of the commit process or does fossil simply carry the
> data so the signature can be verified manually?
>

It simply carries them over and accounts for them while parsing manifests.
If there is code to verify them, i haven't seen it yet.


-- 
- 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] commit signing

On Tue, 20 Aug 2013 18:41:39 +0200
Stephan Beal  wrote:

> However... i don't want to move this to the trunk until i hear some
> feedback from the devs whether this is the optimal solution or whether
> something like a simple "PGP" would do.

Sure, let's hear what others can say...


Sincerely,
Gour

-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] commit signing

2013-08-20 Thread John Long

I need to go back in the archives and see where I can find an example of
this but in the meantime to ask the obvious, is fossil verifying the
signatures as part of the commit process or does fossil simply carry the
data so the signature can be verified manually?


On Tue, Aug 20, 2013 at 08:00:41PM +0200, Gour wrote:
> On Tue, 20 Aug 2013 18:41:39 +0200
> Stephan Beal  wrote:
> 
> > However... i don't want to move this to the trunk until i hear some
> > feedback from the devs whether this is the optimal solution or whether
> > something like a simple "PGP" would do.
> 
> Sure, let's hear what others can say...
> 
> 
> Sincerely,
> Gour
> 
> -- 
> As a strong wind sweeps away a boat on the water, 
> even one of the roaming senses on which the mind 
> focuses can carry away a man's intelligence.
> 
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
> 
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

-- 
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] getting fossil timeline to show time offsets

On Tue, Aug 20, 2013 at 6:25 PM, j. van den hoff
wrote:

> On Tue, 20 Aug 2013 17:59:11 +0200, Benedikt Ahrens <
> benedikt.ahr...@gmx.net> wrote:
>
>  Hello,
>>
>> the fossil timeline command shows UTC time rather than observing the
>> system setting (UTC+02:00, in my case).
>> Is there anything I can do to change this?
>>
>
> you can switch off UTC (so that it uses local time) in the web interface
> (admin -> timeline). don't know whether there is a command line way to do
> this.
>

in parallel i've been looking for one and haven't found it. i assume there
isn't one.

TODO += add 'localtime' config setting (boolean)

IIRC the internal infrastructure is there, it just seems to be missing from
the CLI settings comment (?).

-- 
- 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] window opened by `diff --tk' is editable

On Tue, Aug 20, 2013 at 6:22 PM, j. van den hoff
wrote:

> indeed, things are moving fast with fossil ;-)
>

This year is turning out to be one of the busier ones:

http://fossil-scm.org/index.html/reports?view=byyear

and recent activity has been pretty high:

http://fossil-scm.org/index.html/reports?view=byweek

> however, regarding the _new_ Tk window (as of fossil version 1.26
> [13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues:
>

LOL! i'll stay out of this one, except to say that i would like to see a
commit button directly in the tk diff. And a way to map that to the
gdiff-command, so that (f gdiff) becomes (f diff --tk). But this netbook is
too slow for further hacking on fossil tonight...

-- 
- 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] commit signing

On Tue, Aug 20, 2013 at 6:19 PM, Gour  wrote:

> Yeah, functionality is there, some cosmetic is required...link can point
> to http://some-domain/artifact/id, but the link title can be e.g. just
> *PGP-SIGNED* ?
>

i don't see a way to do that without hard-coding the link into the comment
(which would go against the patterns in similar places in the code). That
link-generation a side-effect of a downstream step where the wiki links are
produced.

> Thanks a lot for working on it...
>

My pleasure. By coincidence i recently worked near the PGP-related code
(all 8 or 10 lines of it) so knew what needed to be done there.

However... i don't want to move this to the trunk until i hear some
feedback from the devs whether this is the optimal solution or whether
something like a simple "PGP" would do. i tried to make it stand out, but
i'm not sure that's necessary. @others: feel free to patch it.

-- 
- 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] getting fossil timeline to show time offsets

2013-08-20 Thread j. van den hoff

On Tue, 20 Aug 2013 17:59:11 +0200, Benedikt Ahrens  
 wrote:



Hello,

the fossil timeline command shows UTC time rather than observing the
system setting (UTC+02:00, in my case).
Is there anything I can do to change this?


you can switch off UTC (so that it uses local time) in the web interface  
(admin -> timeline). don't know whether there is a command line way to do  
this.


j.



fossil version is 1.26.

Thanks.
Benedikt
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] window opened by `diff --tk' is editable

2013-08-20 Thread j. van den hoff


On Tue, 20 Aug 2013 17:31:24 +0200, Richard Hipp  wrote:

On Tue, Aug 20, 2013 at 10:57 AM, j. van den hoff  

wrote:



not a big deal but slightly irritating:

the tk-window opened by `diff --tk' is "editable", i..e one can modify  
the
displayed diff text (w/o any real effect, of course). I don't know Tk,  
but
maybe there's an option to make the window readonly in order to avoid  
any

potential confusion (since many graphical diff/merge tools _do_ allow to
edit such diffs)?

I don't presume this info is relevant here, but it happens on a current
mac with fossil 1.26


I just tried it here and couldn't get it to "edit".  Maybe this has  
already

been fixed?


you are right. it happenend with fossil version 1.26 [c9cb6e7293]  
2013-06-18 21:09:23 UTC
but current leaf revision produces a quite differently looking Tk window  
not exhibiting the reported problem anymore.

indeed, things are moving fast with fossil ;-)

however, regarding the _new_ Tk window (as of fossil version 1.26  
[13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues:


compared to the "old" one, font size now is at the limit of comfortable  
readability, i.e. is too small (I could send you a screen shot offline, if  
you are interested...) and the new central "Files" drop-down menu (I  
presume that's what it should be?) is broken does in fact _not_ drop down  
but opens a new small Tk window about the size of the menu button itself,  
containing the file name and three inactive close/minimize/maximize  
buttons. it disappears when clicking somewhere else in the first Tk window  
but not when releasing/clicking the menu button.


so apart from the spurious "edit" feature I find the alt variant more  
usable (the font issue alone leads to this) and also cleaner (the black  
horizontal and vertical bars are distracting in my view and the bare bones  
`sdiff' look of the old variant was more in accord with my taste).


j.






 j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
__**_
fossil-users mailing list
fossil-users@lists.fossil-scm.**org 
http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] commit signing

On Tue, 20 Aug 2013 16:10:05 +0200
Stephan Beal  wrote:

> Please do an update, 'make', fossil rebuild, and try again. i'm not
> terribly happy with how the link looks, but that seems to be the way
> those links are supposed to be displayed in the timeline.

Yeah, functionality is there, some cosmetic is required...link can point
to http://some-domain/artifact/id, but the link title can be e.g. just
*PGP-SIGNED* ?


Thanks a lot for working on it...


Sincerely,
Gour

-- 
One who works in devotion, who is a pure soul, and who controls 
his mind and senses is dear to everyone, and everyone is dear to 
him. Though always working, such a man is never entangled.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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 fossil timeline to show time offsets

2013-08-20 Thread Benedikt Ahrens

Hello,

the fossil timeline command shows UTC time rather than observing the
system setting (UTC+02:00, in my case).
Is there anything I can do to change this?

fossil version is 1.26.

Thanks.
Benedikt
___
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 running out of memory

On Tue, Aug 20, 2013 at 5:56 PM, Benedikt Ahrens wrote:

> It works fine with 1.26.
>

:)



> BTW, is there any chance the Debian packaging could happen in a debian
> branch of the fossil development repository, i.e. that the Debian fossil
> maintainer get write access to that repo?
>

@that maintainer: if you're reading this, please speak up :).

-- 
- 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] fossil running out of memory

2013-08-20 Thread Benedikt Ahrens

> On Mon, Aug 5, 2013 at 10:15 PM, Richard Hipp  wrote:
> 
>> On Mon, Aug 5, 2013 at 3:55 PM, Benedikt Ahrens 
>> wrote:
>>
>>> is not feasible in my situation.
>>>
>>
>> packages or libraries or deal with package managers.  Just copy *one file*
>> into your $PATH on each machine where it matters.
>>
> 
> @Benedikt: the easiest thing to do is to edit your $PATH to include
> $HOME/bin and drop fossil in $HOME/bin. If you need help with setting the
> PATH, google for "ubuntu edit path" (bzw. "ubuntu path bearbeiten") and
> several useful answers are there.

Thanks. However, my objection to upgrading to newer fossil was not
motivated by a lack of know-how, but rather by the fact that this
solution comes with a complexity of O(number of affected machines).
Also, not all of the affected machines are mine.

>>My question was intended to be "Can I do something to the
>>
>>> repository---and not to fossil---in order to get things working again,
>>> with version 1.22?"
>>>
>>
> We don't know, and that version is old enough for us to justify suggesting
> you try a newer version before we pursue it further.

It works fine with 1.26.

BTW, is there any chance the Debian packaging could happen in a debian
branch of the fossil development repository, i.e. that the Debian fossil
maintainer get write access to that repo?

Thanks for your help and patience.
Benedikt

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718812
___
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] window opened by `diff --tk' is editable

On Tue, Aug 20, 2013 at 10:57 AM, j. van den hoff  wrote:

> not a big deal but slightly irritating:
>
> the tk-window opened by `diff --tk' is "editable", i..e one can modify the
> displayed diff text (w/o any real effect, of course). I don't know Tk, but
> maybe there's an option to make the window readonly in order to avoid any
> potential confusion (since many graphical diff/merge tools _do_ allow to
> edit such diffs)?
>
> I don't presume this info is relevant here, but it happens on a current
> mac with fossil 1.26
>
>
I just tried it here and couldn't get it to "edit".  Maybe this has already
been fixed?



>  j.
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> __**_
> 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

[fossil-users] window opened by `diff --tk' is editable

2013-08-20 Thread j. van den hoff


not a big deal but slightly irritating:

the tk-window opened by `diff --tk' is "editable", i..e one can modify the  
displayed diff text (w/o any real effect, of course). I don't know Tk, but  
maybe there's an option to make the window readonly in order to avoid any  
potential confusion (since many graphical diff/merge tools _do_ allow to  
edit such diffs)?


I don't presume this info is relevant here, but it happens on a current  
mac with fossil 1.26


j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] commit signing

On Tue, Aug 20, 2013 at 4:02 PM, Gour  wrote:

> On Tue, 20 Aug 2013 15:42:19 +0200
> Stephan Beal  wrote:
>
> > To the raw manifest, you mean?
>
> Yes, to the one e.g. showed by Richard:
>
> http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44

Please do an update, 'make', fossil rebuild, and try again. i'm not
terribly happy with how the link looks, but that seems to be the way those
links are supposed to be displayed in the timeline.

-- 
- 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] commit signing

On Tue, 20 Aug 2013 15:42:19 +0200
Stephan Beal  wrote:

> To the raw manifest, you mean?

Yes, to the one e.g. showed by Richard:

http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44


Sincerely,
Gour

-- 
One who is not disturbed in mind even amidst the threefold 
miseries or elated when there is happiness, and who is free 
from attachment, fear and anger, is called a sage of steady mind.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] commit signing

On Tue, Aug 20, 2013 at 3:34 PM, Gour  wrote:

> It's OK, and it would be superb to e.g. have *PGP SIGNED* as hyperlink
> to the artifact?
>

To the raw manifest, you mean?

-- 
- 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] commit signing

On Tue, 20 Aug 2013 14:58:49 +0200
Stephan Beal  wrote:

> Can you please try that out, Gour?

My mistake...I mixed fossil versions for commit and ui.

It's OK, and it would be superb to e.g. have *PGP SIGNED* as hyperlink
to the artifact?


Sincerely,
Gour

-- 
Not by merely abstaining from work can one achieve freedom 
from reaction, nor by renunciation alone can one attain perfection.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] commit signing

On Tue, Aug 20, 2013 at 9:23 AM, Gour  wrote:

> On Tue, 20 Aug 2013 14:58:49 +0200
> Stephan Beal  wrote:
>
> > Can you please try that out, Gour?
>
> Here is output from configure:
>
> gour@atmarama ~/t/fossil> ./configure
>

Try instead:  ./configure --disable-lineedit




> Host System...x86_64-unknown-linux-gnu
> Build System...x86_64-unknown-linux-gnu
> 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...ok
> Checking for zlib.h...ok
> Checking libs for inflateEnd...-lz
> Checking for ssl via pkg-config...ok
> 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
>
>
> From where it should find it?
>
> It looks it does not work without it?
>
>
> Sincerely,
> Gour
>
> --
> The work of a man who is unattached to the modes of material
> nature and who is fully situated in transcendental knowledge
> merges entirely into transcendence.
>
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
>
>
> ___
> 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] commit signing

On Tue, Aug 20, 2013 at 3:23 PM, Gour  wrote:

> On Tue, 20 Aug 2013 14:58:49 +0200
> Stephan Beal  wrote:
>
> > Can you please try that out, Gour?
>
> Here is output from configure:
>

Do:

fossil co timeline-pgp-marker
./configure
make clean
make
./fossil rebuild
./fossil ui

and then you'll see the signed entries in the timeline.

-- 
- 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] commit signing

On Tue, 20 Aug 2013 14:58:49 +0200
Stephan Beal  wrote:

> Can you please try that out, Gour?

Here is output from configure:

gour@atmarama ~/t/fossil> ./configure
Host System...x86_64-unknown-linux-gnu
Build System...x86_64-unknown-linux-gnu
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...ok
Checking for zlib.h...ok
Checking libs for inflateEnd...-lz
Checking for ssl via pkg-config...ok
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

>From where it should find it?

It looks it does not work without it?

Sincerely,
Gour

-- 
The work of a man who is unattached to the modes of material 
nature and who is fully situated in transcendental knowledge 
merges entirely into transcendence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

___
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] commit signing

On Tue, Aug 20, 2013 at 2:11 PM, Stephan Beal  wrote:

> i've just written down a TODO to add this info to the timeline if it's not
> terribly problematic. The main problem is that the timeline doesn't have
> that level of data. Ah, but it could - we could still see the PGP key in
> the crosslink phase, i think, and that's where the timeline is updated,
> anyway.
>
> Written down on my TODO list.
>

i love low-hanging fruit...

http://fossil-scm.org/index.html/timeline?r=timeline-pgp-marker

i'm not entirely satisfied with this solution, so i've put it into a branch
and am hoping someone has a prettier/better suggestion. What i've done is
during manifest parsing, set a flag if we see a PGP key, and add "(*PGP
SIGNED*)" to the event.comment (not ecomment) if that flag is set. e.g.

[507ee45f25]  Fix an off-by-one bug
in the network protocol handler so that it can accept a zero-length file.
(*PGP SIGNED*) (user:
drh,
tags: trunk
)04:02
[9b30224db7]  Closed-Leaf: Merging
formatting changes to timeline and concepts documentation (*PGP SIGNED*)
(user: aku,
tags: trunk
)

That didn't paste so well, but you get the idea.

Caveat: this marker only applies to new commits or after a rebuild (then
it's retroactive).

Can you please try that out, Gour?

-- 
- 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] commit signing

On Tue, Aug 20, 2013 at 2:05 PM, Gour wrote:

> Iow, I'd like an easy way to check whether the commit is signed or not,
> possibly close to the 'SHA1 Hash:' label or something.
>

i recently some samething similar in the JimTCL timeline, where each commit
has a "signed off by...", but i don't know if that was done via PGP-sig
post-processing or if they commits were manually marked.

This is extremely unofficial for the time being, and this isn't the
solution you're looking for but you could do:

stephan@tiny:~/cvs/fossil/fossil$ ../f2/f-acat 22c1ac41d4c02c44 | head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C
Add\sseparate\s"clone"\spermissions.\s\sPreviously,\sone\sneeded\s"History"\npremission\sin\sorder\sto\sclone.\s\sBut\ssometimes\swe\swant\sto\sgrant\sclone\nwithout\sgranting\shistory.
D 2007-08-23T19:52:19
F BUILD.txt e7fed9d5b647337f8e7abf45981d10cdcc1555e2
...

http://fossil.wanderinghorse.net/repos/f2/index.cgi/wiki?name=f-tools

i've just written down a TODO to add this info to the timeline if it's not
terribly problematic. The main problem is that the timeline doesn't have
that level of data. Ah, but it could - we could still see the PGP key in
the crosslink phase, i think, and that's where the timeline is updated,
anyway.

Written down on my TODO list.

--
- 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] commit signing

On Tue, Aug 20, 2013 at 8:05 AM, Gour  wrote:

>
> Iow, I'd like an easy way to check whether the commit is signed or not,
> possibly close to the 'SHA1 Hash:' label or something.
>
> I'm also pretty sure that something like that was available or am I
> dreaming...
>

I think you dreamed it.  I don't recall ever having added anything like
that in Fossil.


-- 
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] commit signing

On Tue, 20 Aug 2013 07:47:42 -0400
Richard Hipp  wrote:

> The PGP signature is recorded in the repository.  (See, for example
> the PGP signature on an early check-in to Fossil itself at
> http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44).

OK.

> However, I have never added any logic in the timeline display to
> actually show the signature.  The need to do this has never arisen in
> 6+ years.

> What kind of timeline display are you looking for?

Well, the example above is OK, but I wonder is there any ling in the
timeline which leads to it or one has to manually enter
http://path/artifact/id ?

Iow, I'd like an easy way to check whether the commit is signed or not,
possibly close to the 'SHA1 Hash:' label or something.

I'm also pretty sure that something like that was available or am I
dreaming...


Sincerely,
Gour

-- 
A self-realized man has no purpose to fulfill in the discharge 
of his prescribed duties, nor has he any reason not to perform 
such work. Nor has he any need to depend on any other living being.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] commit signing

On Tue, Aug 20, 2013 at 7:42 AM, Gour  wrote:

> Hello,
>
> I've converted (mostly from Git, but as well as from darcs & btr) *all*
> my repost to Fossil in order to exclusively use it and test it
> thoroughly.
>
> Now I experience some (strange) problem that I can't see GPG signatures
> in my commits.
>
> During commit I see the following:
>
> You need a passphrase to unlock the secret key for
> user: "Gour-Gadadhara Dasa "
> 4096-bit RSA key, ID 52B5C810, created 2011-04-02
>
> New_Version: da8de0a52e73efdb545cd5020d17182e2e657c6d
>
> but when I look in the timeline, I cannot see whether the commit is
> signed or not?
>
> Has something changed in Fossil in regard?
>

The PGP signature is recorded in the repository.  (See, for example the PGP
signature on an early check-in to Fossil itself at
http://www.fossil-scm.org/fossil/artifact/22c1ac41d4c02c44).  However, I
have never added any logic in the timeline display to actually show the
signature.  The need to do this has never arisen in 6+ years.

What kind of timeline display are you looking for?




>
> Here is the snippet from my settings:
>
> clearsign(local)  1
> case-sensitive
> clean-glob
> crnl-glob
> default-perms
> diff-binary
> diff-command
> dont-push
> editor   (local)  vim
> empty-dirs
> encoding-glob
> gdiff-command
> gmerge-command   (local)  meld
> http-port
> https-login
> ignore-glob
> keep-glob
> localauth(local)  0
> main-branch
> manifest
> max-upload
> mtime-changes
> pgp-command  (local)  gpg --clearsign -o
>
>
> When I use: 'gpg clearsign -o' with some test document, it is normally
> signed without asking for passphrase since gpg-agent is active (via
> keychain) and required key is set as default.
>
> Any hint?
>
>
> Sincerely,
> Gour
>
> --
> But for one who takes pleasure in the self, whose human life
> is one of self-realization, and who is satisfied in the self only,
> fully satiated — for him there is no duty.
>
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
>
>
> ___
> 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

[fossil-users] commit signing