[9fans] Drawterm login prompt.

2009-09-07 Thread drivers
9fans,

   Is anyone aware of where the configuration data is concerning drawterm 
logins?  I initially set my system up as crashing.dom and since put the system 
into production as plan9.union.edu for my final honors project in CS. 
Unfortunatly fixing the /cfg plan9.ini and /lib/ndb/local to the proper setups 
did not change this login prompt it still reads ja...@crashing.dom password: .  
Any thoughts as to where I might be able to change the prompt?  
Additionally I recompiled the kernel in a final effort after I felt enough 
updates had past. The rest of the system is functioning well.

Thanks for reading.

=james
=jt



Re: [9fans] Drawterm login prompt.

2009-09-07 Thread drivers
Fgb,


This did the trick thanks.  Eric thanks for your quick reply, good to know you 
actually are a human.

=jt
--Original Message--
From: erik quanstrom
Sender: 9fans-boun...@9fans.net
To: 9fans@9fans.net
ReplyTo: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] Drawterm login prompt.
Sent: Sep 7, 2009 23:13

On Mon Sep  7 23:11:27 EDT 2009, benave...@gmail.com wrote:
 it's still stored in the nvram, you'll need to
 echo blah  /dev/sdC0/nvram
 reboot and enter the right one

i could be wrong, but i don't think nvram has anything to do with drawterm.

- erik



=jt



Re: [9fans] Blocks in C

2009-09-03 Thread drivers
To ensure only one thread in the kernel at a time?

-jt-
--Original Message--
From: erik quanstrom
Sender: 9fans-boun...@9fans.net
To: 9fans@9fans.net
ReplyTo: Fans of the OS Plan 9 from Bell Labs
Subject: Re: [9fans] Blocks in C
Sent: Sep 3, 2009 21:32

 what does BLK stand for?

big kernel lock.

- erik



=jt



Re: [9fans] vmware installation problems

2009-07-29 Thread drivers
Hello Roger,

I'm currently running latest Plan 9 in vmware fusion Version 2.0 
(116369).  This system has been behaving perfectly on every installation (save 
where i really botched something up trying to learn the system).

What is your host OS?  I'm running this on Mac OS X 10.5.8

hope we can get you a fix for this soon,

respectfully,

++james



[9fans] git on plan9

2009-07-18 Thread drivers
Phew finally got it.  There was some hackery involved in the hg-git 
python code since mmap wasn't supported -- i basically just implemented them 
with reads; however I was considering writing an mmap module that used reads 
but realized that would be misleading since it wasn't really mmap.  I think 
altering the hg-git code is the best option and i've done it in such a way that 
its isolated so it can be easily updated from mainstream.  Let me know if you 
want it.

++james

rator_gade% hg clone git://zen-sources.org/zen/THE.git
destination directory: THE.git
fetching from : git://zen-sources.org/zen/THE.git
importing Hg objects into Git
Counting objects: 1592, done.
Compressing objects:   0% (1/1185)   
Compressing objects:   1% (12/1185)   
Compressing objects:   2% (24/1185)   
Compressing objects:   3% (36/1185)   
Compressing objects:   4% (48/1185)   
Compressing objects:   5% (60/1185)   
Compressing objects:   6% (72/1185)   
Compressing objects:   7% (83/1185)   
Compressing objects:   8% (95/1185)   
Compressing objects:   9% (107/1185)   
Compressing objects:  10% (119/1185)   
Compressing objects:  11% (131/1185)   
Compressing objects:  12% (143/1185)   
Compressing objects:  13% (155/1185)   
Compressing objects:  14% (166/1185)   
Compressing objects:  15% (178/1185)   
Compressing objects:  16% (190/1185)   
Compressing objects:  17% (202/1185)   
Compressing objects:  18% (214/1185)   
Compressing objects:  19% (226/1185)   
Compressing objects:  20% (237/1185)   
Compressing objects:  21% (249/1185)   
Compressing objects:  22% (261/1185)   
Compressing objects:  23% (273/1185)   
Compressing objects:  24% (285/1185)   
Compressing objects:  25% (297/1185)   
Compressing objects:  26% (309/1185)   
Compressing objects:  27% (320/1185)   
Compressing objects:  28% (332/1185)   
Compressing objects:  29% (344/1185)   
Compressing objects:  30% (356/1185)   
Compressing objects:  31% (368/1185)   
Compressing objects:  32% (380/1185)   
Compressing objects:  33% (392/1185)   
Compressing objects:  34% (403/1185)   
Compressing objects:  35% (415/1185)   
Compressing objects:  36% (427/1185)   
Compressing objects:  37% (439/1185)   
Compressing objects:  38% (451/1185)   
Compressing objects:  39% (463/1185)   
Compressing objects:  40% (474/1185)   
Compressing objects:  41% (486/1185)   
Compressing objects:  42% (498/1185)   
Compressing objects:  43% (510/1185)   
Compressing objects:  44% (522/1185)   
Compressing objects:  45% (534/1185)   
Compressing objects:  46% (546/1185)   
Compressing objects:  47% (557/1185)   
Compressing objects:  48% (569/1185)   
Compressing objects:  49% (581/1185)   
Compressing objects:  50% (593/1185)   
Compressing objects:  51% (605/1185)   
Compressing objects:  52% (617/1185)   
Compressing objects:  53% (629/1185)   
Compressing objects:  54% (640/1185)   
Compressing objects:  55% (652/1185)   
Compressing objects:  56% (664/1185)   
Compressing objects:  57% (676/1185)   
Compressing objects:  58% (688/1185)   
Compressing objects:  59% (700/1185)   
Compressing objects:  60% (711/1185)   
Compressing objects:  61% (723/1185)   
Compressing objects:  62% (735/1185)   
Compressing objects:  63% (747/1185)   
Compressing objects:  64% (759/1185)   
Compressing objects:  65% (771/1185)   
Compressing objects:  66% (783/1185)   
Compressing objects:  67% (794/1185)   
Compressing objects:  68% (806/1185)   
Compressing objects:  69% (818/1185)   
Compressing objects:  70% (830/1185)   
Compressing objects:  71% (842/1185)   
Compressing objects:  72% (854/1185)   
Compressing objects:  73% (866/1185)   
Compressing objects:  74% (877/1185)   
Compressing objects:  75% (889/1185)   
Compressing objects:  76% (901/1185)   
Compressing objects:  77% (913/1185)   
Compressing objects:  78% (925/1185)   
Compressing objects:  79% (937/1185)   
Compressing objects:  80% (948/1185)   
Compressing objects:  81% (960/1185)   
Compressing objects:  82% (972/1185)   
Compressing objects:  83% (984/1185)   
Compressing objects:  84% (996/1185)   
Compressing objects:  85% (1008/1185)   
Compressing objects:  86% (1020/1185)   
Compressing objects:  87% (1031/1185)   
Compressing objects:  88% (1043/1185)   
Compressing objects:  89% (1055/1185)   
Compressing objects:  90% (1067/1185)   
Compressing objects:  91% (1079/1185)   
Compressing objects:  92% (1091/1185)   
Compressing objects:  93% (1103/1185)   
Compressing objects:  94% (1114/1185)   
Compressing objects:  95% (1126/1185)   
Compressing objects:  96% (1138/1185)   
Compressing objects:  97% (1150/1185)   
Compressing objects:  98% (1162/1185)   
Compressing objects:  99% (1174/1185)   
Compressing objects: 100% (1185/1185)   
Compressing objects: 100% (1185/1185), done.
Total 1592 (delta 455), reused 1128 (delta 286)
importing Git objects into Hg
at:   0/116
at: 100/116
updating working directory
241 files updated, 0 files merged, 0 files removed, 0 files unresolved
rator_gade%




Re: [9fans] git on plan9

2009-07-17 Thread drivers
ok, so there is another snag i've just found out.  The new dulwich code 
which hg-git relies on requires mmap -- which we do not provide in ape 
currently.  I'm new to plan9; but am not afraid to code up things that are 
useful.  I do need to know what the best idea is for how to resolve 
this...seems I can write an mmap for ape (which might be a huge pain) or we can 
run it on linuxemu (which i really don't want to do).  And, of course, there is 
just eliminating git repositories.  It posts to the git repo; however, when it 
starts to handle the pack or object it just freaks out because thats all in the 
dulwich code dealing with things like...

mmap.mmap(f.fileno(), size, access=mmap.ACCESS_READ)

and seeing as we have no mmap in ape the mmap module in python 2.5 has been 
diligently ommitted

sorry if i got someone elses (other than my own) hopes up.  She works just fine 
for hg though...

++james
---BeginMessage---
Congratulations! I'm interested in giving it a shot; is it just a
tarball to compile, or is it a package for fgb's contrib(1)? I'll
throw it on sources for you if you don't have an alternate hosting
solution while you wait for your contrib.

John

On Thu, Jul 16, 2009 at 5:35 PM, driv...@0xabadba.be wrote:
        I currently have hg and this bookmarks git module working on plan9. 
 Russ, thanks for the clue -- i have this packaged up now (my first package 
 but doesn't seem like rocket science.  Please let me know if you are 
 interested.  Also to be honest 98% of this was Filipe and FGB i just put a 
 few pieces together to get 1.3 and git working nicely together.

 hope everyone is doing well,

 respectfully,

 james toy


 -- Forwarded message --
 From: Federico G. Benavento benave...@gmail.com
 To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net
 Date: Thu, 16 Jul 2009 20:25:06 -0300
 Subject: Re: [9fans] git on plan9
 ok, I didn't get this the first time, so this is not the hg which is in 
 sources
 this is hg 1.3

 cpu% hg clone --traceback http://bitbucket.org/jespern/django-piston/
 destination directory: django-piston
 requesting all changes
 adding changesets
 adding manifests
 adding file changes
 added 161 changesets with 309 changes to 67 files
 updating working directory
 53 files updated, 0 files merged, 0 files removed, 0 files unresolved
 cpu%

 the one i have installed just works, notice is the same link you provided.
 as I told you yesterday, hg changes a lot of stuff from release to
 release, and it's probably ape's fault.

 On Thu, Jul 16, 2009 at 8:16 PM, Federico G.
 Benaventobenave...@gmail.com wrote:
 and my reply to that was:

 my patch behaves exactly like chmod(1), so those bits are inherited
 I think this is the right thing to do as posix doesn't support those bits.

 http://www.opengroup.org/onlinepubs/95399/basedefs/sys/stat.h.html


 On Thu, Jul 16, 2009 at 8:08 PM, Federico G.
 Benaventobenave...@gmail.com wrote:
 it was loosing the dir bit, from the readme:

 Fixed chmod and fchmod, they were ignoring the dir bit.

 federico


 from the notes:

 Fri May 30 00:04:19 EDT 2008 geoff
    should append-only and exclusive-access be cleared,
    inherited or settable via the mode argument?


 On Thu, Jul 16, 2009 at 6:17 PM, ron minnichrminn...@gmail.com wrote:
 I may be missing it, but what particular thing in the chmod failed?
 What was it trying to set?

 ron





 --
 Federico G. Benavento




 --
 Federico G. Benavento




 --
 Federico G. Benavento





-- 
I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
---End Message---


Re: [9fans] git on plan9

2009-07-17 Thread drivers
Cinap recommended this and I am working on it right now :) -- any other 
suggestions are very welcome.  Thanks Russ.

respectfully

++james
---BeginMessage---
You don't need mmap to implement this mmap.
If it's just trying to map files into memory read-only,
you could implement it by open, stat to find length,
malloc, readn, and return the pointer.  This is
what the original linuxemu did (and still does?).

Russ
---End Message---


[9fans] (no subject)

2009-07-17 Thread drivers
All,

I've fixed the last bug (thank god) its hard trying to problem solve 
and learn a language at the same time but at least I'm still having fun (and 
python isn't like learning C ;).  Additionally now I have this bug which is 
mutually exclusive from any of the mmap stuff. But at least its registering 
with the git repository as can be seen below.  The problem is more in this 
other dulwich thingwhich apparently there is a new version of so i'm going 
to merge that and retry.  Compressing objects certainly gives some nasty Cr 
output though

james++


rator_gade% hg clone git://zen-sources.org/zen/THE.git
destination directory: THE.git
fetching from : git://zen-sources.org/zen/THE.git
importing Hg objects into Git
Counting objects: 1592, done.
Compressing objects:   0% (1/1185)   
Compressing objects:   1% (12/1185)   
Compressing objects:   2% (24/1185)   
Compressing objects:   3% (36/1185)   
Compressing objects:   4% (48/1185)   
Compressing objects:   5% (60/1185)   
Compressing objects:   6% (72/1185)   
Compressing objects:   7% (83/1185)   
Compressing objects:   8% (95/1185)   
Compressing objects:   9% (107/1185)   
Compressing objects:  10% (119/1185)   
Compressing objects:  11% (131/1185)   
Compressing objects:  12% (143/1185)   
Compressing objects:  13% (155/1185)   
Compressing objects:  14% (166/1185)   
Compressing objects:  15% (178/1185)   
Compressing objects:  16% (190/1185)   
Compressing objects:  17% (202/1185)   
Compressing objects:  18% (214/1185)   
Compressing objects:  19% (226/1185)   
Compressing objects:  20% (237/1185)   
Compressing objects:  21% (249/1185)   
Compressing objects:  22% (261/1185)   
Compressing objects:  23% (273/1185)   
Compressing objects:  24% (285/1185)   
Compressing objects:  25% (297/1185)   
Compressing objects:  26% (309/1185)   
Compressing objects:  27% (320/1185)   
Compressing objects:  28% (332/1185)   
Compressing objects:  29% (344/1185)   
Compressing objects:  30% (356/1185)   
Compressing objects:  31% (368/1185)   
Compressing objects:  32% (380/1185)   
Compressing objects:  33% (392/1185)   
Compressing objects:  34% (403/1185)   
Compressing objects:  35% (415/1185)   
Compressing objects:  36% (427/1185)   
Compressing objects:  37% (439/1185)   
Compressing objects:  38% (451/1185)   
Compressing objects:  39% (463/1185)   
Compressing objects:  40% (474/1185)   
Compressing objects:  41% (486/1185)   
Compressing objects:  42% (498/1185)   
Compressing objects:  43% (510/1185)   
Compressing objects:  44% (522/1185)   
Compressing objects:  45% (534/1185)   
Compressing objects:  46% (546/1185)   
Compressing objects:  47% (557/1185)   
Compressing objects:  48% (569/1185)   
Compressing objects:  49% (581/1185)   
Compressing objects:  50% (593/1185)   
Compressing objects:  51% (605/1185)   
Compressing objects:  52% (617/1185)   
Compressing objects:  53% (629/1185)   
Compressing objects:  54% (640/1185)   
Compressing objects:  55% (652/1185)   
Compressing objects:  56% (664/1185)   
Compressing objects:  57% (676/1185)   
Compressing objects:  58% (688/1185)   
Compressing objects:  59% (700/1185)   
Compressing objects:  60% (711/1185)   
Compressing objects:  61% (723/1185)   
Compressing objects:  62% (735/1185)   
Compressing objects:  63% (747/1185)   
Compressing objects:  64% (759/1185)   
Compressing objects:  65% (771/1185)   
Compressing objects:  66% (783/1185)   
Compressing objects:  67% (794/1185)   
Compressing objects:  68% (806/1185)   
Compressing objects:  69% (818/1185)   
Compressing objects:  70% (830/1185)   
Compressing objects:  71% (842/1185)   
Compressing objects:  72% (854/1185)   
Compressing objects:  73% (866/1185)   
Compressing objects:  74% (877/1185)   
Compressing objects:  75% (889/1185)   
Compressing objects:  76% (901/1185)   
Compressing objects:  77% (913/1185)   
Compressing objects:  78% (925/1185)   
Compressing objects:  79% (937/1185)   
Compressing objects:  80% (948/1185)   
Compressing objects:  81% (960/1185)   
Compressing objects:  82% (972/1185)   
Compressing objects:  83% (984/1185)   
Compressing objects:  84% (996/1185)   
Compressing objects:  85% (1008/1185)   
Compressing objects:  86% (1020/1185)   
Compressing objects:  87% (1031/1185)   
Compressing objects:  88% (1043/1185)   
Compressing objects:  89% (1055/1185)   
Compressing objects:  90% (1067/1185)   
Compressing objects:  91% (1079/1185)   
Compressing objects:  92% (1091/1185)   
Compressing objects:  93% (1103/1185)   
Compressing objects:  94% (1114/1185)   
Compressing objects:  95% (1126/1185)   
Compressing objects:  96% (1138/1185)   
Compressing objects:  97% (1150/1185)   
Compressing objects:  98% (1162/1185)   
Compressing objects:  99% (1174/1185)   
Compressing objects: 100% (1185/1185)   
Compressing objects: 100% (1185/1185), done.
Total 1592 (delta 455), reused 1128 (delta 286)
** unknown exception encountered, details follow
** report bug details to 

Re: [9fans] git on plan9

2009-07-16 Thread drivers
hi,
Ok, so I have hg compiled and it will run via hg cmd; however, i'm 
running into a chmod error.  There was a proposed change in 
/n/sources/patch/ape-chmod-dirbit which can be seen here: 
http://www.kix.in/plan9/mirror/sources/patch/.  I've taken the chmod.c.new file 
and replaced the old one (copying it for backup's sake...). FGB and others that 
have worked with the previous system have you seen this error:

rator_gade% hg clone --traceback http://bitbucket.org/jespern/django-piston/
destination directory: django-piston
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
Traceback (most recent call last):
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 43, in _runcatch
return _dispatch(ui, args)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 449, in _dispatch
return runcommand(lui, repo, cmd, fullargs, ui, options, d)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 317, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 501, in 
_runcommand
return checkargs()
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 454, in checkargs
return cmdfunc()
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 448, in lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File /sys/python/lib/python2.5/mercurial/util.py, line 370, in check
return func(*args, **kwargs)
  File /sys/python/lib/python2.5/mercurial/commands.py, line 635, in clone
update=not opts.get('noupdate'))
  File /sys/python/lib/python2.5/mercurial/hg.py, line 286, in clone
dest_repo.clone(src_repo, heads=revs, stream=stream)
  File /sys/python/lib/python2.5/mercurial/localrepo.py, line 2176, in clone
return self.pull(remote, heads)
  File /sys/python/lib/python2.5/mercurial/localrepo.py, line 1465, in pull
return self.addchangegroup(cg, 'pull', remote.url())
  File /sys/python/lib/python2.5/mercurial/localrepo.py, line 2066, in 
addchangegroup
if fl.addgroup(chunkiter, revmap, trp) is None:
  File /sys/python/lib/python2.5/mercurial/revlog.py, line 1197, in addgroup
ifh = self.opener(self.indexfile, a+)
  File /sys/python/lib/python2.5/mercurial/store.py, line 296, in 
fncacheopener
return self._op(hybridencode(path), mode, *args, **kw)
  File /sys/python/lib/python2.5/mercurial/util.py, line 839, in __call__
makedirs(d, self.createmode)
  File /sys/python/lib/python2.5/mercurial/util.py, line 788, in makedirs
os.chmod(name, mode)
OSError: [Errno 12] Invalid argument: '/usr/james/django-piston/.hg/store/data'
abort: Invalid argument: /usr/james/django-piston/.hg/store/data
rator_gade% 

If so, what kind of things should i be trying to rectify it (other than using 
that ape-chmod-dirbit/chmod.c.new to replace chmod.c in the appropriate dir ; 
mk ; mk install;) 

respectfully,

+=jt



Re: [9fans] git on plan9

2009-07-16 Thread drivers
Filipe,
This has fixed the os.chmod error, I had rebuild ape; however, i had 
not rebuilt python.  I am now running into this traceback even though the .hg 
dir is being instantiated.  

rator_gade% hg clone http://bitbucket.org/jespern/django-piston
real URL is http://bitbucket.org/jespern/django-piston/
destination directory: django-piston
requesting all changes
adding changesets
adding manifests
adding file changes
added 161 changesets with 309 changes to 67 files
updating working directory
** unknown exception encountered, details follow
** report bug details to http://mercurial.selenic.com/bts/
** or mercur...@selenic.com
** Mercurial Distributed SCM (version 1.3)
** Extensions loaded: 
Traceback (most recent call last):
  File /bin/hg, line 27, in module
mercurial.dispatch.run()
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 16, in run
sys.exit(dispatch(sys.argv[1:]))
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 27, in dispatch
return _runcatch(u, args)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 43, in _runcatch
return _dispatch(ui, args)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 449, in _dispatch
return runcommand(lui, repo, cmd, fullargs, ui, options, d)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 317, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 501, in 
_runcommand
return checkargs()
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 454, in checkargs
return cmdfunc()
  File /sys/python/lib/python2.5/mercurial/dispatch.py, line 448, in lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File /sys/python/lib/python2.5/mercurial/util.py, line 370, in check
return func(*args, **kwargs)
  File /sys/python/lib/python2.5/mercurial/commands.py, line 635, in clone
update=not opts.get('noupdate'))
  File /sys/python/lib/python2.5/mercurial/hg.py, line 313, in clone
_update(dest_repo, uprev)
  File /sys/python/lib/python2.5/mercurial/hg.py, line 331, in update
stats = _merge.update(repo, node, False, False, None)
  File /sys/python/lib/python2.5/mercurial/merge.py, line 456, in update
_checkunknown(wc, p2)
  File /sys/python/lib/python2.5/mercurial/merge.py, line 77, in _checkunknown
for f in wctx.unknown():
  File /sys/python/lib/python2.5/mercurial/context.py, line 583, in unknown
def unknown(self): return self._status[4]
  File /sys/python/lib/python2.5/mercurial/util.py, line 118, in __get__
result = self.func(obj)
  File /sys/python/lib/python2.5/mercurial/context.py, line 553, in _status
return self._repo.status(unknown=True)
  File /sys/python/lib/python2.5/mercurial/localrepo.py, line 1016, in status
s = self.dirstate.status(match, listignored, listclean, listunknown)
  File /sys/python/lib/python2.5/mercurial/dirstate.py, line 569, in status
for fn, st in self.walk(match, listunknown, listignored).iteritems():
  File /sys/python/lib/python2.5/mercurial/dirstate.py, line 519, in walk
entries = listdir(join(nd), stat=True, skip=skip)
TypeError: 'skip' is an invalid keyword argument for this function
rator_gade%

note: i picked this hg repo because it was super small :P nothing of 
interest

i'll play with it some more.. not exactly sure what this is yet

thanks!

+=jt



Re: [9fans] git on plan9

2009-07-16 Thread drivers
I currently have hg and this bookmarks git module working on plan9. 
Russ, thanks for the clue -- i have this packaged up now (my first package but 
doesn't seem like rocket science.  Please let me know if you are interested.  
Also to be honest 98% of this was Filipe and FGB i just put a few pieces 
together to get 1.3 and git working nicely together.

hope everyone is doing well,

respectfully,

james toy
---BeginMessage---
ok, I didn't get this the first time, so this is not the hg which is in sources
this is hg 1.3

cpu% hg clone --traceback http://bitbucket.org/jespern/django-piston/
destination directory: django-piston
requesting all changes
adding changesets
adding manifests
adding file changes
added 161 changesets with 309 changes to 67 files
updating working directory
53 files updated, 0 files merged, 0 files removed, 0 files unresolved
cpu%

the one i have installed just works, notice is the same link you provided.
as I told you yesterday, hg changes a lot of stuff from release to
release, and it's probably ape's fault.

On Thu, Jul 16, 2009 at 8:16 PM, Federico G.
Benaventobenave...@gmail.com wrote:
 and my reply to that was:

 my patch behaves exactly like chmod(1), so those bits are inherited
 I think this is the right thing to do as posix doesn't support those bits.

 http://www.opengroup.org/onlinepubs/95399/basedefs/sys/stat.h.html


 On Thu, Jul 16, 2009 at 8:08 PM, Federico G.
 Benaventobenave...@gmail.com wrote:
 it was loosing the dir bit, from the readme:

 Fixed chmod and fchmod, they were ignoring the dir bit.

 federico


 from the notes:

 Fri May 30 00:04:19 EDT 2008 geoff
    should append-only and exclusive-access be cleared,
    inherited or settable via the mode argument?


 On Thu, Jul 16, 2009 at 6:17 PM, ron minnichrminn...@gmail.com wrote:
 I may be missing it, but what particular thing in the chmod failed?
 What was it trying to set?

 ron





 --
 Federico G. Benavento




 --
 Federico G. Benavento




-- 
Federico G. Benavento
---End Message---


Re: [9fans] git on plan9

2009-07-16 Thread drivers
John,

I'm going to write an rc script to do the installation. The package works 
to pull in hg; however, it depends on a lot of things.  I'll write a readme and 
post it.  Is the wiki an ok place for this?

respectfully,

james 
---BeginMessage---
Congratulations! I'm interested in giving it a shot; is it just a
tarball to compile, or is it a package for fgb's contrib(1)? I'll
throw it on sources for you if you don't have an alternate hosting
solution while you wait for your contrib.

John

On Thu, Jul 16, 2009 at 5:35 PM, driv...@0xabadba.be wrote:
        I currently have hg and this bookmarks git module working on plan9. 
 Russ, thanks for the clue -- i have this packaged up now (my first package 
 but doesn't seem like rocket science.  Please let me know if you are 
 interested.  Also to be honest 98% of this was Filipe and FGB i just put a 
 few pieces together to get 1.3 and git working nicely together.

 hope everyone is doing well,

 respectfully,

 james toy


 -- Forwarded message --
 From: Federico G. Benavento benave...@gmail.com
 To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net
 Date: Thu, 16 Jul 2009 20:25:06 -0300
 Subject: Re: [9fans] git on plan9
 ok, I didn't get this the first time, so this is not the hg which is in 
 sources
 this is hg 1.3

 cpu% hg clone --traceback http://bitbucket.org/jespern/django-piston/
 destination directory: django-piston
 requesting all changes
 adding changesets
 adding manifests
 adding file changes
 added 161 changesets with 309 changes to 67 files
 updating working directory
 53 files updated, 0 files merged, 0 files removed, 0 files unresolved
 cpu%

 the one i have installed just works, notice is the same link you provided.
 as I told you yesterday, hg changes a lot of stuff from release to
 release, and it's probably ape's fault.

 On Thu, Jul 16, 2009 at 8:16 PM, Federico G.
 Benaventobenave...@gmail.com wrote:
 and my reply to that was:

 my patch behaves exactly like chmod(1), so those bits are inherited
 I think this is the right thing to do as posix doesn't support those bits.

 http://www.opengroup.org/onlinepubs/95399/basedefs/sys/stat.h.html


 On Thu, Jul 16, 2009 at 8:08 PM, Federico G.
 Benaventobenave...@gmail.com wrote:
 it was loosing the dir bit, from the readme:

 Fixed chmod and fchmod, they were ignoring the dir bit.

 federico


 from the notes:

 Fri May 30 00:04:19 EDT 2008 geoff
    should append-only and exclusive-access be cleared,
    inherited or settable via the mode argument?


 On Thu, Jul 16, 2009 at 6:17 PM, ron minnichrminn...@gmail.com wrote:
 I may be missing it, but what particular thing in the chmod failed?
 What was it trying to set?

 ron





 --
 Federico G. Benavento




 --
 Federico G. Benavento




 --
 Federico G. Benavento





-- 
I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
---End Message---


[9fans] git on plan9

2009-07-15 Thread drivers
Thats good to hear HG is working well, I am really hoping for git as it is 
hosting my current repo of works.  If git does not exist and there is no plan 
to do it in the future I can migrate over my stuff (i'd prefer to do actual new 
work than porting VCS!).  Thanks for the replies thus far.

+=jt



Re: [9fans] git on plan9

2009-07-15 Thread drivers
John,

I think I might be 3/4 the way there with 1.3 :).  I'll update you when 
its done.  Too bad geoff is away until the 25th -- he is making me a contrib 
then.  

respectfully,

jamest
---BeginMessage---
On Wed, Jul 15, 2009 at 4:01 PM, Russ Coxr...@swtch.com wrote:
 On Wed, Jul 15, 2009 at 3:38 PM, driv...@0xabadba.be wrote:
 Thats good to hear HG is working well, I am really hoping for git
 as it is hosting my current repo of works.  If git does not exist
 and there is no plan to do it in the future I can migrate over my
 stuff (i'd prefer to do actual new work than porting VCS!).
 Thanks for the replies thus far.

 If the hg is new enough that it comes with the bookmarks
 extension, then you can install a separate extension
 that will make it handle git too.  I have been using hg to
 manipulate git repositories and find it far more pleasant
 than using git directly.

  http://hg-git.github.com/
  http://bitbucket.org/abderrahim/hg-git/

 The code at the second URL, which is a newer fork
 of the first URL's code, makes it almost transparent:

  hg clone git://asdfkjasdfadsf
  hg commit
  hg push
  hg pull -u

 They all just work.

 Russ


It appears that the Plan 9 port of hg is version 1.0.2, which does not
have bookmarks.

To those who ported it, how difficult was the task? How much work
would it be to bring in 1.2?

To Russ, it's not quite clear... does the git extension *require*
bookmarks, or just work better with them?

Right now I'm trying to clone hg-git to test it, but the clone is failing with:
%hg clone http://bitbucket.org/abderrahim/hg-git/
destination directory: hg-git
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Invalid argument: /usr/john/lib/hg-git/.hg/store/data


John
-- 
I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
---End Message---