What happened to the libraries repositories?
ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://ghc.haskell.org/libraries/binary
pushurl = ssh://g...@ghc.haskell.org/libraries/binary
[branch "master"]
remote = origin
merge = refs/heads/master
ezyang@javelin:~/Dev/ghc-clean/libraries/binary$ git pull
fatal: remote error: access denied or repository not exported:
/libraries/binary
Edward
Excerpts from Herbert Valerio Riedel's message of Sat Aug 10 05:06:06 -0400
2013:
> Hello GHC Devs,
>
> Let me add some details and clarifications to yesterday's
> migration completion notice:
>
> On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
> > Push access is now restored and Gitolite is in place! This brings some
> > nice updates:
>
> > * There's now access to the 'git' protocol for cloning anonymously.
> > This lets you clone even the biggest repos extremely quickly, and is
> > the fastest method for getting a copy of the tree.
>
> Consequently, if you are a developer (and not behind a firewall that
> filters port 9418) you should try out the following assymetric
> configuration:
>
> ./sync-all -r git://ghc.haskell.org remote set-url origin
> ./sync-all -r ssh://g...@ghc.haskell.org remote set-url --push origin
>
> This uses the unauthenticated low-latency git:// protocol for fetching
> repository data, and the authenticated encrypted high-latency ssh://
> protocol for pushing into the GHC repositories.
>
> This setup has the advantage over using the GitHub GHC mirrors, that the
> fetch and push locations are really identical and never out-of-sync
> (e.g. if the Git mirroring breaks or lags for some reason)
>
> > * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git,
> > meaning it should be faster too!
> > * We will soon have Gitweb available, once our git.haskell.org CNAME
> > is in place. Eventually we'd like something akin to
>
> Small clarification: Smart HTTP Git transport is only enabled on
> http://git.haskell.org/; The legacy URLs at http://darcs.haskell.org/
> are is still served "dumbly".
>
> If you don't want to wait for the DNS CNAME entry, you can fake the DNS
> entry to point to ghc.haskell.org, e.g. by
>
> echo "88.198.224.241 git.haskell.org" >> /etc/hosts
>
> (...and don't forget to remove that entry once the real DNS CNAME entry
> is in place) and then just point your browser to http://git.haskell.org/
>
> > The following people have had their keys re-added, and should be able
> > to push and pull from the new setup.
> > [...]
>
> You should all check your current permissions by invoking
>
> ssh g...@ghc.haskell.org info
>
> you should see something like
>
> ,----
> | hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git 1.7.10.4
> | the gitolite config gives you the following access:
> | @R W ghc
> | @R W ghc-tarballs
> | @R W git-sandbox
> | @R W haddock
> | [...]
> | @R W packages/unix
> | @R W packages/vector
> | @R W packages/xhtml
> | @R W testsuite
> `----
>
> Please make sure, *YOUR* username shows up in place of $USERNAME, to
> find out whether we mixed up your public keys.
>
> (See http://gitolite.com/gitolite/g2/info_expand.html#info, if you want
> to know more about the meaning of the output)
>
> Note: The current setup denies non-fast-forward and ref-deletion updates
> via "git push". This will be relaxed once we reach an agreement over
> what the Git heads/tag refs namespace policy shall be (i.e. who is
> allowed to create/delete/non-fwd-update heads/tags (and which ones)).
>
> If you want to debug/test 'git push', feel free to push whatever you
> like to the 'git-sandbox' repository.
>
> > Please direct any concerns to me, like if you need something off the
> > server, need your shell account back, or need commit access.
>
> For technical problems with Trac&Git(olite) itself, please CC me as
> well; as I am in a different timezone from Austin, this may help reduce
> the response time for solving the issue at hand. Alternatively, you can
> also reach us on freenode's #haskell-infrastructure
>
> And finally, the changes resulting from the new Trac commit-hook
> integration is worth a separate posting of its own to follow shortly.
>
> Cheers,
> hvr
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
