Re: [fossil-users] Linux 2.6 :-(

2014-08-08 Thread Steve Bennett
On 8 Aug 2014, at 2:34 pm, Andy Bradford amb-fos...@bradfords.org wrote:

 Thus said Joe Mistachkin on Thu, 07 Aug 2014 21:14:56 -0700:
 
 Yeah, it appears the net change  was that Jim Tcl was updated. There
 are quite a  lot of changes to  it since the last  version. However, I
 think it should be fine merging it to trunk? Any conflicting opinions?
 
 No, looks fine now (as far as the merge is concerned).
 
 I tried to test  it by making my /home unreadable  (chmod 711 /home) but
 then  Fossil couldn't  even  update,  and all  other  kinds of  problems
 happened:
 
 $ fossil up
 cannot find current working directory; Permission denied
 $ ./configure --disable-lineedit
 No installed jimsh or tclsh, building local bootstrap jimsh0
 Runtime Error: stdlib.tcl:87: Failed to get pwd
 in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, 
 line 11
 at file stdlib.tcl, line 87
 Runtime Error: stdlib.tcl:87: Failed to get pwd
 in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, 
 line 11
 at file stdlib.tcl, line 87
 No working C compiler found. Tried cc and gcc.
 $ which tclsh
 /usr/local/bin/tclsh
 $ pwd
 /home/src/fossil
 
 $ cd /home
 $ pwd
 /home
 $ ls
 ls: .: Permission denied
 $ cd src
 $ ls 
 fossil
 
 So  clearly it's  possible to  navigate, but  configure doesn't  like it
 much. I  tried with --debug and  didn't get any other  useful info. It's
 also odd that it didn't think it  could find tclsh (yes I forgot to make
 tclsh disappear, but it thought it was gone already).

Are you sure you just changed /home to 711? 
Worked OK for me:

$ stat /home
  File: `/home'
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 801h/2049d  Inode: 164626433   Links: 8
Access: (0711/drwx--x--x)  Uid: (0/root)   Gid: (0/root)
Access: 2013-04-18 13:27:17.195385388 +1000
Modify: 2012-08-10 14:46:50.0 +1000
Change: 2014-08-08 15:52:14.586170436 +1000
 Birth: -

$ ./autosetup/find-tclsh
No installed jimsh or tclsh, building local bootstrap jimsh0
/home/steveb/src/fossil/autosetup/jimsh0
$ ./configure --disable-lineedit
Host System...i686-pc-linux-gnu
Build System...i686-pc-linux-gnu
C compiler...ccache cc -g -O2
...


--
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


Re: [fossil-users] how to push to chiselapp

2014-08-08 Thread Martijn Coppoolse

On 7-8-2014 21:47, Will Parsons wrote:

Andy Bradford wrote:

Thus said Will Parsons on Thu, 07 Aug 2014 00:53:53 -:


Since I wasn't transmitting any sensitive data anyway, I answered yes,
and then got:

Error: not authorized to write

Is there something wrong with the way I'm trying to authenticate?


I  see you  used  -B for  HTTP_AUTH.  I don't  know,  but does  chiselap
actually  require  HTTP_AUTH? At  any  rate,  it  won't be  used  unless
required, however, I suspect you  are missing the actual Fossil username
somewhere  and this  is  why Fossil  is  telling you  that  you are  not
authorized to write. Without a Fossil  username, you get the default set
of permissions  which does not  include the  permission to write  to the
repository.


I don't understand - what I represented by uname in the command *is*
my chiselapp user name.  To be clear, in my original local repository,
I had a superuser name1.  I created the chiselapp user as name2.
Looking at the repository on chiselapp, I see two superusers, name1
and name2.  name2 is what I represented by uname in the command I
indicated.  I assume I would have to supply my chiselapp name and
password in the command line somehow, and if not by the -B option,
then how?


If both name1 and name2 are a superuser in the remote repo, then 
either of the following should work:


fossil push https://na...@chiselapp.com/user/name2/repository/repo

fossil push https://na...@chiselapp.com/user/name2/repository/repo

(it does when I try it using my own hosted repo).

You need to use the repository's user name and passwords, but Chisel 
adds your chisel user name and password as superuser to each and every 
repo you host with them anyway.


Each repo can be accessed completely independently from your chiselapp 
username (except that it's part of the URL). When syncing with that 
repo, all the handling is done by Fossil, without intervention from 
Chisel. And Fossil will only look at the table of users present in the repo.


HTH,
--
Martijn Coppoolse
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] stupid libfossil tricks: requirejs-like resource loading

2014-08-08 Thread Stephan Beal
Hi, all!

i think this is the coolest stupid fossil trick yet...

Those who know a bit about requirejs (http://requirejs.org/) might find it
interesting to know that we can now use a similar mechanism to load
arbitrary resources from a fossil database. A short demo:


// Import our requirejs workalike:
const R = s2.import('toys/require.s2');

// Some shared state for the various plugins we'll install...
const fslState = {
f: Fossil.Context.new().openCheckout()
};

/**
   require() plugin: wiki!PageName
*/
R.configs.wiki = {
isVirtual: true,
load: function(name,opt){
affirm F.db  F.db.repo;
return F.loadManifest(F.db.selectValue(sql.applyFormat(name)));
}.importSymbols({
F: fslState.f,
sql: ___
  SELECT x.rid FROM tag t, tagxref x
  WHERE x.tagid=t.tagid
  AND t.tagname='wiki-%1$q'
  ORDER BY mtime DESC LIMIT 1
___
})
};

/**
   require() plugin: blob!SYMBOLIC_NAME|rid:RID
*/
R.configs.blob = {
isVirtual: true,
load: function(sym,opt){
return F.loadBlob(sym)
}.importSymbols({F: fslState.f})
};


// Now use it like requirejs:
R(// Resources to load:
  ['wiki!home',
   'text!require-demo.s2',
   'blob!rid:1'],
  // Callback to pass the resources to:
  function(page, thisScript, rid1){
  print(__FLC, typename page, typename thisScript, typename rid1);
  print(Wiki page, page.L,is, page.W.lengthBytes(),bytes long.);
  print(This script is,thisScript.lengthBytes(),bytes long.);
  print(RID 1 is,rid1.length(),bytes long.);
});


That all results in something like:

[stephan@host:~/cvs/fossil/libfossil/s2]$ ./s2sh require-demo.s2
require-demo.s2:43:12 object string buffer
Wiki page home is 8640 bytes long.
This script is 1225 bytes long.
RID 1 is 168 bytes long.


i expect to be making heavy use of this in the new/ongoing CGI layer.

Happy Hacking!

-- 
- 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] Linux 2.6 :-(

2014-08-08 Thread Andy Bradford
Thus said Steve Bennett on Fri, 08 Aug 2014 15:55:51 +1000:

 Are you sure you just changed /home to 711?

Yes, I did ``chmod  711 /home'' (as root). That was it.  Then I tried to
configure and got the errors. I see you are on Linux. I'm on OpenBSD, so
perhaps things work a little differently (for whatever reason):

$ ls -ld /home
drwxr-xr-x  13 root  wheel  512 Jul 30  2013 /home/
$ sudo chmod 711 /home
$ ls -ld /home
drwx--x--x  13 root  wheel  512 Jul 30  2013 /home/
$ ./configure
No installed jimsh or tclsh, building local bootstrap jimsh0
Runtime Error: stdlib.tcl:87: Failed to get pwd
in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, 
line 11
at file stdlib.tcl, line 87
Runtime Error: stdlib.tcl:87: Failed to get pwd
in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, 
line 11
at file stdlib.tcl, line 87
No working C compiler found. Tried cc and gcc.
$ which tclsh
/usr/local/bin/tclsh
$ which cc
/usr/bin/cc

Andy
-- 
TAI64 timestamp: 400053e4e3ea


___
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] Problem with using branch names

2014-08-08 Thread Tony Papadimitriou
Figured it out.  It is case sensitive, I branched as WIP and tried with “wip”.  
Sorry for the noise.

From: Tony Papadimitriou 
Sent: Friday, August 08, 2014 9:01 PM
To: Fossil SCM user's discussion 
Subject: [fossil-users] Problem with using branch names

This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC

(f = fossil)
I created a branch with the F COMMIT --BRANCH WIP command (WIP is the name of 
the branch I created) .
Then if I do F UP TRUNK it switches to trunk, no problem.  Then I try F UP WIP 
and it gives this error: “no such version: wip”
But in the timeline, I can see this version with “tags: WIP”, and if I use F UP 
with the hash value instead it loads it.  So, it simply does not accept the 
branch name as a version.  Isn’t the use of a branch or tag name a shortcut for 
the latest version carrying that tag?
Why doesn’t it work?  (I have a feeling it used to work, but now I must be 
doing something differently, and I can’t figure out what.)
Thanks.



___
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] [PATCH] Wiki formatting

2014-08-08 Thread Warren Young

On 8/7/2014 15:09, Warren Young wrote:


you can use a meta tag to do the same thing


Confirmed.  If you go to Admin  Skins  Header, and add this line 
somewhere in head, IE8+ will work in standards mode when you point it 
at an intranet instance of Fossil:


meta http-equiv=x-ua-compatible content=IE=edge 

I don't think this is the right solution for Fossil out of the box, 
though, for a bunch of reasons:


1. You'd have to add it redundantly to all the head tags in 
src/style.c, not just to zDefaultHeader.


2. Fixing it here won't help any Fossil installation where they have 
already customized the page header.


3. It appears that Fossil's SCGI and HTTP server features are built on 
top of its CGI feature, so one fix applies to all three use cases.


Therefore, I offer this trivial patch, which I hope does not require a 
signed contributor agreement:


Index: src/cgi.c
==
--- src/cgi.c
+++ src/cgi.c
@@ -306,10 +306,11 @@

   if( g.fullHttpReply ){
 fprintf(g.httpOut, HTTP/1.0 %d %s\r\n, iReplyStatus, zReplyStatus);
 fprintf(g.httpOut, Date: %s\r\n, cgi_rfc822_datestamp(time(0)));
 fprintf(g.httpOut, Connection: close\r\n);
+fprintf(g.httpOut, X-UA-Compatible: IE=edge\r\n);
   }else{
 fprintf(g.httpOut, Status: %d %s\r\n, iReplyStatus, zReplyStatus);
   }

   if( blob_size(extraHeader)0 ){

I tested it against IE11 on Windows 8.1 in fossil server mode only. 
It does indeed fix both problems I noticed with IE in compatibility 
view mode.  (Broken CSS handling for the logo, as well as the WYSIWYG 
editor problem.)


You still get HTML1202 warnings in the developer console (F12), but this 
appears to be bogus:


   http://msdn.microsoft.com/en-us/library/ie/hh180764%28v=vs.85%29.aspx

I assume it also works in CGI and SCGI modes, but I did not test this.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users