News: CVS URL changed
CVS changes
Item posted by Sylvain Beucler <Beuc> on Tue Dec 13 22:35:18 2005.
In our effort to better structure the Savannah system and get the necessary fundations for new features, all CVS-related services are moved to cvs.savannah.gnu.org and cvs.savannah.nongnu.org.
You can use 'sv' instead of 'savannah' for short.
cvs -z3 -d:ext:username@cvs.sv.gnu.org:/sources/project co module_name
cvs -z3 -d:ext:username@cvs.sv.gnu.org:/web/project co module_name
Anonymous access over SSH, which has been somewhat troublesome, and uses an unnecessary encryption (since it is public access), was disabled. The new structure allowed us to replace it with the more common pserver access. pserver access is anonymous only.
cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/sources/project co module_name
cvs -z3 -d:pserver:anonymous@cvs.sv.gnu.org:/web/project co project
We now use 'sources' and 'web' instead of respectively 'cvsroot' and 'webcvs' - this sounds clearer. The old paths are still supported via symbolic links.
Migration: type one of the following one-liner in your CVS working copy:
- For anonymous working copies
find . -path '.*/CVS/Root' -print0 | xargs -0 perl -i -p -e 's/:ext:anoncvs\@(cvs\.)?s/:pserver:anonymous\@cvs.s/'
- For a project member working copy
find . -path '.*/CVS/Root' -print0 | xargs -0 perl -i -p -e 's/\@s/\@cvs.s/'
(Note: this was reported not to work under MSys (see the comments); if you know a more portable way, feel free to reply)
Or, just check out a fresh copy :)
rsync is now enabled on default port (873), you can use it to get your raw CVS files. With this new service, the (resources consuming) daily tarball generation script could be disabled.
rsync cvs.savannah.gnu.org::sources/project/
rsync cvs.savannah.gnu.org::web/project/
ViewCVS was also upgraded. Old URLs are seamlessly redirected to the new ones.
Commit notification was cleaned-up; this doesn't change much, except that those receiving notifications and diffs to the same list as separate mails now get them all in a single mail.
You can ignore the deprecation warnings that CVS issues when sending the e-mail: we need to upgrade our version of log_accum to support new-style CVSROOT/loginfo format, and meanwhile we use the old-style format for that particular hook.
Comments:
| I can not checkout hurd code (posted by Charles Peng, Tue Dec 20 13:53:08 2005) |
I used `cvs -z3 -d:ext:chp516@cvs.sv.gnu.org:/cvsroot/hurd co hurd` to checkout hurd code.
But when I tried the cvs command above, ssh said "Permission denied (publickey)."
What can I do???
p.s.
|
| RE: I can not checkout hurd code (posted by Sylvain Beucler, Tue Dec 20 21:03:10 2005) |
You're not member of any project, so you don't have a system account.
You need to use pserver :) |
| RE: I can not checkout hurd code (posted by Charles Peng, Wed Dec 21 13:20:26 2005) |
But how can I use pserver from behind a proxy?
What should I do? |
| RE: I can not checkout hurd code (posted by Sylvain Beucler, Wed Dec 21 23:31:08 2005) |
Hmm, how do you do with SF and other CVS services?
|
| RE: I can not checkout emacs code (posted by Darel Henman, Tue Jan 10 06:40:47 2006) |
I have the same problem as chp516 had.
Anonymous vis ssh worked fine till you "fixed" it.
Since it is broken, I joined as a project member name and to loging, but alas....
cvs -z3 -d:ext:djh@cvs.sv.gnu.org:/cvsroot/emacs co emacs
Error --> Permission denied (publickey).
This problem is not unique to me.
Please fix this problem or tell me and others in the same situation the give us the procedures to access the source code for users behind a proxy
Regards,
|
| RE: I can not checkout emacs code (posted by Sylvain Beucler, Fri Jan 13 21:14:21 2006) |
Hi,
If you are stuck behind a proxy, there're 3 different approaches to fix this issue:
1) Add proxy support to Tor - if that's not already done by the development team,
2) Make your local admin understand why proxying is not an option for you and your fellow co-workers,
and 3) Get all the remote sites you need access to to tweak their configuration so you can bypass your proxy (preventing setting up an https server on the remote IP, incidentally).
As a general rule, I would like people to go 2) and then 1), and avoid 3) :)
I would also be pleased to know if people found others ways than the ones I mentioned, especially for Savannah-like sites such as SF.net. |
| RE: I can not checkout emacs code (posted by Darel Henman, Fri Jan 27 05:45:01 2006) |
>3) Get all the remote sites you need access to to tweak their configuration so you can bypass your proxy (preventing setting up an https server on the remote IP, incidentally).
This is how we used to access savannah's cvs, through a proxy and using ssh. This system worked well. Now it is gone, and myself and others have to spend a lot of time trying to get things fixed. You already had the system in place at port 80 and 443. Can't you easily re-implment it.
As you said tor is heavy and slow. Plus I don't enough know anything about it....
Do you have pserver:cvs.gnu.org on port 80 or 443?
Darel |
| RE: I can not checkout emacs code (posted by Sylvain Beucler, Mon Jan 30 15:18:25 2006) |
We have Apache running on port 80, because we provide ViewCVS there :)
(Then we have SSH running on port 22/443, and pserver on port 2401.)
Activating anonymous SSH again is cumbersome for us and other users (asks for password instead of rejecting connections when the public key is missing, uses more resources, etc.)
If you want to learn Tor, we wrote a FAQ entry on it :)
Good to hear that you're working to get your outgoing traffic restrictions fixed.
|
| Sylvain Beucler's miss about anon access (posted by Darel Henman, Wed Feb 1 02:35:04 2006) |
Sylvain Beucler propsed three methods of access and gave us his opinion of what we should do, to get access to supposedly free source code.
Now you either have to be blessed project member to get access to the code if you are stuck behind a fire wall to spend maybe years trying learning about networks and try hacking something together.
Of the 3 methods he proposed.
What's wrong with it:
(a) "As of 2005-03-27, (Tor) does not work from behind a proxy."
(b) This page is now only blessed project member access
Syvain's proposed Method 2.) Get you corp sys adminstrators to allow it.
This is naive and impractible if not impossible, since corporate policy is not changeable by system administrators and additionally some of us can download free source during off times, such as lunch, as downloadning the source is not a direct work related activity.
Syvain's proposed Method 3.) Get all the remote sites you need access to to tweak their configuration so you can bypass your proxy (preventing setting up an https server on the remote IP, incidentally).
This was what we had and it worked. This is what should be restored. As to preventing it from having a http(S) server, I never noticed savannah to lack a site.
I would like a little help for all of us. There should be a method clear described how people behind firewall proxys can freely access cvs for read purposes.
Had this but now, it has been stolen from us and only allowed to blessed members. Note also that it is in way simple and easy to become a development member.
Regards,
|
| RE: Sylvain Beucler's miss about anon access (posted by Sylvain Beucler, Thu Feb 2 21:42:39 2006) |
[I begins to be hard to follow this conversation - can you send new comments to savannah-hackers-public@gnu.org please? :)]
I decided to have a deeper look at this "behind a proxy", and it took me around one hour to both reproduce such a setup and workaround it. I'll update the FAQ asap; the key piont is that during last year, Tor added support for proxy-ed connections.
My first question is: did you actually try?
Also:
> (b) This page is now only blessed project member access
What kind of error do you get? Could it be that this page is blacklisted? That sounds quite bad, hopefully there was a routing problem or something else :/
I insist that this page never was 'stolen', and even if it were, pages at Savannah are provided by default under a verbatim copying license, so you're still free to get it from anywhere else (friends, web archives) =)
So solution 1 does work, you don't even have to write code, since the code is already there :)
On to solution 2: my second question is: did you even ask?
Maybe it's difficult to make things change, but if you never ask, as people who disagree with me often does, then this surely will never change.
So it would be good to ask people in charge of your network (be it Big Boss or Local Guru):
As I wrote in the FAQ, feel free to point your admins to the Savannah FAQ that explains how to bypass their setup in a matter of minutes.
Also, I worked in the world's biggest corporation, and they didn't have any kind of outgoing traffic restrictions. I'm not naive, but I know such filtering is just irrelevant.
On to method 3: this method was possible for around a year, without warranty, at Savannah. Now it isn't anymore for anonymous users because we performed necessary changes to our installation (among others, improve speed and error feedback).
This approach doesn't scale, since few people will want to complexify their setup to help you work-around misworking connection on your end. We can't also start providing all services on port 443, this would require 1 IP per service. Notice that this also fails the concept of traffic restriction - if all services are available when you're behind a proxy, then just drop the proxy. And that's already the case when you use Tor, so tell you Boss that the proxy just wastes his money.
I insist that cvs.savannah.gnu.org:443 is occupied by SSH because of such a workaround, and as a consequence I cannot add SSL accept there, as I explained here:
I need to add though, for better understanding, that https support for a website needs one additional IP, so the fact we provide https at savannah.[non]gnu.org doesn't necessarily means that we can do so at cvs.savannah.gnu.org.
The short conclusion is that you should try to fix your end of the problem, either by making it change, either by working around it which is quite simple.
|
| RE: Behind a proxy firewall access (posted by Darel Henman, Tue Feb 7 04:18:53 2006) |
Sylvain, et al.
Thanks for the information.
The new CvsFromBehindFirewall page, I believe you had a hand in, is very informative and gives enough information for tunneling out.
I appreciate your efforts as Im sure many others do as well.
d-j-h |
| cvs [update aborted]: cannot stat /var/lock/c (posted by Bruce Korb, Fri Dec 16 00:08:35 2005) |
Should this not have all been done before locking out the old access mechanism? I have a new release already uploaded, but CVS is out of date and I cannot update the web pages either. Thanks! Regards, Bruce |
| RE: cvs [update aborted]: cannot stat /var/lo (posted by Sylvain Beucler, Fri Dec 16 00:52:07 2005) |
Sorry about the /var/lock issue; we need to recreate the lock dirs in tmpfs at each startup, and the script had a bug.
I do not understand the part about CVS out of date.
The [non]gnu.org admin upgraded the webcvs updating process, but apparently something is not properly working; he's already notified. |
| Err, well, having some trouble here... (posted by Christian Mauduit, Tue Dec 13 00:07:38 2005) |
Hi,
I'm trying to upload my web pages to Savannah, but I'm having trouble with CVS:
ufoot@guenegaud:~/home/cvs/savannah/t$ cvs -z3 \
ufoot@guenegaud:~/home/cvs/savannah/t$ cvs -z3 \
Some other projects work well with similar commands (more precisely liquidwar and u61, which I opened "a long time ago"). Projects I opened recently seem also wrecked (pygpsweb also has "cannot stat /var/lock/cvs/pygpsweb", and uwikicms has "Cannot access /web/uwikicms/CVSROOT No such file or directory"), but this is not of great concern for now. Since I use GNU Arch 8-)
But the liquidwar6 problem is bothering me, for I need CVS for the web pages.
Thanks in advance,
Christian.
|
| RE: Err, well, having some trouble here... (posted by Sylvain Beucler, Tue Dec 13 08:23:20 2005) |
I recreated all the locks dirs. Michael already recreated liquidwar6 a while ago :) |
| really rocks (posted by paul poulain, Mon Dec 12 17:24:59 2005) |
savannah admins really rocks ;-)
(et ca fait plaisir de trouver des compatriotes) |
| Setting $CSVROOT to avoid typing 'cvs -d...' (posted by Greg Chicares, Mon Dec 12 01:39:39 2005) |
Is it still possible to set a $CVSROOT shell variable to
$ cvs -d:ext:chicares@cvs.sv.gnu.org:/sources/lmi add so_attributes.hpp
In the past I had used this in local bash:
$ export CVSROOT="chicares@cvs.sv.gnu.org:/sources/lmi"
and got:
CVS moved to cvs.savannah.[non]gnu.org
I get the same message when I issue the same 'commit'
Yet this works, even though '-d' matches the last $CVSROOT
$ cvs -d:ext:chicares@cvs.sv.gnu.org:/sources/lmi commit -m"Import header with shared-library macros from skeleton branch" so_attributes.hpp
|
| RE: Setting $CSVROOT to avoid typing 'cvs -d. (posted by Greg Chicares, Mon Dec 12 03:01:05 2005) |
Oh...I think the perl commands in Sylvain's original message
Here's a caution for users of MSYS (mingw.org): this command
$ find -path '.*/CVS/Root' -print0 | xargs -0 perl -i -p -e 's/:ext:anoncvs\@(cvs\.)?s/:pserver:anonymous\@cvs.s/'
resulted in
Can't do inplace edit on ./current/lmi/CVS/Root: Permission denied.
and many more "permission denied" messages, and had the
|
| RE: Setting $CSVROOT to avoid typing 'cvs -d. (posted by Bob Proulx, Fri Dec 16 06:36:44 2005) |
> Is it still possible to set a $CVSROOT shell variable to
You may be having trouble because you have CVSROOT set in
|
| Thanks! (posted by Han-Wen Nienhuys, Sun Dec 11 23:34:43 2005) |
hi,
cvs upping seems to have sped up quite bit. Thanks for this improvement!
|
| RE: Thanks! (posted by Sylvain Beucler, Sun Dec 11 23:49:15 2005) |
Thanks your support :)
Apparently uptime is happy as well:
|
| www super-membership and webpages (posted by Sylvain Beucler, Sun Dec 11 22:58:34 2005) |
Before anybody ask, I am aware that the www group 'super-membership', that is, their ability to edit any GNU web repository, is not working at the moment.
That's not a common feature, it doesn't fit with the Savane membership scheme, and I need to write a separate script to edit the webgroups (the groups that can access /web/project/).
Webpages will be updated as soon as the sync job at http://www.[nongnu.org] will use the new access method. |
| RE: www super-membership and webpages (posted by Sylvain Beucler, Mon Dec 12 23:00:30 2005) |
Webpages now correcly update again, via hourly cron job. |
| RE: www super-membership and webpages (posted by Sylvain Beucler, Sat Dec 17 20:32:30 2005) |
www super-membership is (re)implemented.
On to updating CVS repositories creation now. |
| RE: www super-membership and webpages (posted by Sylvain Beucler, Sat Dec 17 23:07:30 2005) |
CVS repository created functional again now. |
|
Next Messages |


