On 10/15/07, Jamis Buck [EMAIL PROTECTED] wrote:
It's not the authentication that is failing, it is the lower-level
attempt to open a forwarded port to the remote host.
I wonder if your gateway's SSH implementation is somehow not
configured to allow port forwarding. That, or maybe the SSH
On 10/16/07, Kenneth Kalmer [EMAIL PROTECTED] wrote:
On 10/15/07, Jamis Buck [EMAIL PROTECTED] wrote:
It's not the authentication that is failing, it is the lower-level
attempt to open a forwarded port to the remote host.
I wonder if your gateway's SSH implementation is somehow not
The undefined method `[]' error might be caused by the svn utility
not existing in your path on the localhost. (It needs to be a command-
line version of Subversion.)
As for the not a valid URL error, I'm not sure what's up there.
What subversion client do you have installed?
- Jamis
On
I understand but
why when use capistrano 1.4, it's work
why i correctly with ssh it's work
$ ssh -l b.michelin lamp2
[EMAIL PROTECTED]'s password:
Linux srv-mq-lamp2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007
i686
The programs included with the Debian GNU/Linux system are free
software;
Hi Jamis,
Thanks for the help.
ruby -v gets 1.8.5
and I get the same when I run rake db:migrate by hand.
On Oct 16, 9:52 am, Jamis Buck [EMAIL PROTECTED] wrote:
Sounds like a bug in the ruby version you have installed on the
remote machine. What version of Ruby is it, and how was it
I'm afraid I have no idea why it would work with cap 1.4.1 and not
cap2. You might try comparing the command that gets executed via cap
1.4.1 and see what the difference is. Sorry I can't be of more help.
- Jamis
On Oct 16, 2007, at 9:12 AM, Bolo wrote:
I understand but
why when use
More information.
When i use cap shell, it's works
$ cap shell
* executing `shell'
Welcome to the interactive Capistrano shell! This is an experimental
feature, and is liable to change in future releases. Type 'help' for
a
okay - thanks for the help.
On Oct 16, 10:32 am, Jamis Buck [EMAIL PROTECTED] wrote:
Sounds like an upgrade of Ruby might be called for, then. :( That, or
you'll need to track down exactly what is causing the illegal
instruction and see if you can work around it.
- Jamis
On Oct 16, 2007,
Note that it's not capistrano's connection to lamp2 that is failing,
it is subversion's.
* executing svn checkout -q -r72 svn+ssh://[EMAIL PROTECTED]/var/
lib/svn/partenaires/ /var/www/apps/partenaires/releases/20071016131050
(echo 72 /var/www/apps/partenaires/releases/20071016131050/
I have uploaded a tar of a copy strategy 'rsync' into this group
'rsync_copy_dest.tar'. It uses the --copy-dest flag provided by rsync
to reference the most recently deployed release as the local copy to
compare against.
--copy-dest=DIR
This option behaves like --compare-dest,
What is the difference between that
command, the command that cap 1.4.1 uses?
how i can know that ?
as u can see with 1.4.1, it's work
cap development deploy
* executing task development
* executing task deploy
* executing task update
** transaction: start
* executing task
In cap 1.4.1, this command is being executed:
* executing if [[ ! -d /var/www/apps/wexpay/releases/
20071016164911 ]]; then\n svn co --no-auth-cache -q -
r999 svn+ssh://[EMAIL PROTECTED]/var/lib/svn/wexpay/trunk /var/
www/apps/wexpay/releases/20071016164911 \n (test
Well, hmm, Here are two more things to try, and then I'm out of ideas.
First, I wonder if the removal of the pty in cap 2.1 has somehow
affected subversion in your environment. Try adding the following
line to your deploy.rb:
default_run_options[:pty] = true
Does that make any
I've been using 1.8.5 all the time on Ubuntu without problems except Iconv.
On 10/16/07, Jamis Buck [EMAIL PROTECTED] wrote:
Sounds like an upgrade of Ruby might be called for, then. :( That, or
you'll need to track down exactly what is causing the illegal
instruction and see if you can work
I've found the problem. I had Tortoise SVN installed as well as the
command line subversion. I've uninstalled Tortoise and I've managed to
deploy now. Thanks for your help
On Oct 16, 7:32 pm, RobTalbot [EMAIL PROTECTED] wrote:
svn seems to be in the path ok. Running svn --version I get the
I just upgraded to cap 2, and I'm getting the following error when
trying to deploy:
$ cap staging deploy
* executing `staging'
triggering start callbacks for `deploy'
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
*
I just upgraded to cap 2, and I'm getting the following error when
trying to deploy:
$ cap staging deploy
* executing `staging'
triggering start callbacks for `deploy'
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
*
Hi everyone,
I just upgraded from 2.0.0 to 2.1.0, and I'm getting this error. I
spent some time sifting through the code and trying to figure out what
had changed, with no luck, so I thought I'd ask the experts. Here's
what I see
With Capistrano 2.1.0:
~/rails/grapher/trunk $cap
Please try adding the following:
default_run_options[:pty] = true
And see if that makes any difference.
- Jamis
On Oct 16, 2007, at 3:39 PM, [EMAIL PROTECTED] wrote:
Hi everyone,
I just upgraded from 2.0.0 to 2.1.0, and I'm getting this error. I
spent some time sifting through the code
Scott, out of curiosity, what operating system are you deploying to?
Some people have reported that when subversion is run without a pty,
it won't prompt, but I've not been able to duplicate that. I'd like
to have some idea of what to recommend when people report this issue.
Thanks,
Jamis
I'm deploying to Ubuntu 7.0.4 (Feisty) running on an EC2 instance.
I don't know if it matters, but:
I'm deploying from Mac OS X 10.4
The svn server is Fedora Core release 5 (Bordeaux)
I just did some more poking around, and found the following:
I ran in to the same problem deploying to a box
I understand the default is key access. I can't do it that way. How
do I override?
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
Problem doesn't occur with version 2.0. Bug in 2.1?
On Oct 16, 5:24 pm, Justin [EMAIL PROTECTED] wrote:
It seems to have something to do with sudo's timeout (of about 5
minutes). Any ideas?
On Oct 15, 10:25 pm, Justin [EMAIL PROTECTED] wrote:
Yes, it is. No errors in the log.
To add,
Prior to 2.1, Capistrano would always allocate a pseudo-tty (or
pty) for every command it ran. This allowed commands that did
windowing stuff (e.g., via curses and friends) to query things like
the size of their window and so forth. However, it also meant that
when you ran a command via
I added the line, but it didn't resolve the issue. First run returns
the *** [err :: and the following attempts within about a 5 minute
period are successful. (sudo timeout?)
Also, I made a mistake and didn't realize that the issue does (seem)
to occur with 2.0.0. However, it instead of *** [err
Note that the err prefix just means the text that follows was
printed by the remote process to stderr. (Similarly, out means the
text was printed to stdout.) It doesn't necessarily connote an actual
error.
Another thing to try:
default_run_options[:shell] = false
That will cause all
26 matches
Mail list logo
