Richard Stallman wrote: > Ruben, could this bug have been introduced by the upgrade in Trisquel? > This may be the first time I have accessed the repo since then. > The setup of my checkout has not changed; if nothing has > changed on Savannah, that suggests the problem is in cvs.
CVS on Savannah did migrate recently from vcs0 to a new VM host vcs1. Every effort was attempted to make the migration transparent and seemless but sometimes gremlins do get into things. Although the name did not change (cvs.savannah.gnu.org) the IP address did change. This is the new address for IPv4 and IPv6. $ host cvs.savannah.gnu.org cvs.savannah.gnu.org has address 184.108.40.206 cvs.savannah.gnu.org has IPv6 address 2001:470:142::81 My first suspicion is that there is a stale IP address that is still pointing to the old vcs0 system which does not have. Could the address be verified to be the above on your system? The above is the "important stuff". Below this is additional background information which I will comment upon since I am here. > When I do cvs up on my checkout of gnu.org/philosophy it gives > > Cannot access /web/www/CVSROOT > No such file or directory > > CVS/Root in that directory says > :ext:r...@cvs.savannah.gnu.org:/web/www > which is unchanged from 2012. > CVS/Repository says > www/philosophy All of the above looks okay to me. I can also make a good cvs checkout of the entire www directory myself. I did that just now as a test and all worked okay. The command I used was: cvs -d :ext:r...@cvs.savannah.gnu.org:/web/www co www/philosophy Note that I am "rwp" not "rms" in the above but otherwise should be the same. The above worked okay for me just a few minutes ago. > I had an environment variable > > export CVSROOT=r...@savannah.gnu.org:/cvsroot/emacs > > but getting rid of that did not change anything. I do not think the CVSROOT variable should be needed. I know that CVSROOT has been a traditional variable documented for working with CVS but I recommend against setting it. I think it is better to give that information in the -d option when the local sandbox is created and it is stored in the CVS/Root therefore not needed at any time after the initial creation. > I also had > > export CVS_RSH=~/bin/ssh-for-cvs > > but getting rid of that did not change anything. I do not know what ~/bin/ssh-for-cvs is on your system and therefore cannot comment at all about it as such. But cvs being from the days of "rsh" cvs calls "rsh" and these days we expect "rsh" to be a symlink resolving to "ssh". (Through the "alternatives" package management infrastructure typically.) Then the insecure rsh of old is avoided by default for all applications without needing the application to be specifically reconfigured. That's the way it typically works for such a long lived program as cvs which has been around forever. If the symlink from rsh to ssh exists then CVS_RSH is not needed. However if a system does have an actual non-ssh "rsh" command installed then CVS_RSH is needed as an override to select ssh. Also if specific VPN or specific routing for ssh is needed then CVS_RSH can be used to create a custom command that uses a specific connection path. Most of us do not need this and use the ssh that is installed as the default with the default system routing and do not need to set CVS_RSH at all these days. However special situations do occur. Bob