niemeyer / gopkg Goto Github PK

View Code? Open in Web Editor NEW

537.0 537.0 85.0 68 KB

Source code for the gopkg.in service.

License: Other

Go 100.00%

gopkg's People

Contributors

Stargazers

Watchers

gopkg's Issues

gopkg doesn't choose latest tag in major release

Hi,

The package https://gopkg.in/h2non/bimg.v1 points to tag v1.0.8, even though v1.0.9 has been pushed over 4 hours ago (at moment of writing).

When can I expect the update to take place?

Cheers,

Mark

respect canonical import paths

As you know, go1.4 will allow developers to specify the canonical import path that should be used for importing a package. For packages that include this, gopkg should not recommend using a gopkg import path.

For example, the appengine library uses an import path of google.golang.org/appengine. However, if you were to navigate to http://gopkg.in/golang/appengine.v0, you would be instructed to use an import path of gopkg.in/golang/appengine.v0, which is clearly wrong and won't be allowed by the go command.

Instead, if gopkg detects that a package is using a canonical import path, it should display some kind of message to the effect of:

This package uses the canonical import path example.com/foo and therefore cannot be used with gopkg.

Using gopkg is great because it supports features X, Y, and Z. Feel free to contact the developer of package foo and tell them why they should use it. In the meantime, you can get this package using:
go get example.com/foo
and import this package using:
import "example.com/foo"

To be clear, I think using this as a place to promote the benefits of gopkg is totally fine, but it should still respect the developer's declared import path.

GoDoc cannot refresh documentation of packages that use gopkg.in

I just tried refreshing the documentation of my package Gomail which use gopkg.in and GoDoc showed this error: Error refreshing package: Internal server error.
Whereas refreshing the documentation of github.com/go-gomail/gomail worked fine:

So I tried refreshing mgo's documentation, and there's no error with labix.org/v2/mgo but I just got this error with gopkg.in/mgo.v2: Error refreshing package: Error getting package files from gopkg.in.

fsnotify breakage

Can we please have a temporary workaround in gopkg.in to fix the fsnotify breakage?
I can't just rewrite all the imports in all my branches and tags and update all the vendored packages (assuming they have been fixed at all).

Installations from gopkg.in failing

https://tools.taskcluster.net/groups/Dbxt_ZAzSdGbw4tWOmEdbw/tasks/U3tZazOITWyo5hRCpiIWmw/runs/0/logs/public%2Flogs%2Flive_backing.log

is failing with

go: gopkg.in/[email protected]: unrecognized import path "gopkg.in/yaml.v2" (parse https://gopkg.in/yaml.v2?go-get=1: no go-import meta tags ())

and has been for a few days now.

dustin@jemison ~ $ curl https://gopkg.in/yaml.v2?go-get=1

<html>
<head>
<meta name="go-import" content="gopkg.in/yaml.v2 git https://gopkg.in/yaml.v2">
<meta name="go-source" content="gopkg.in/yaml.v2 _ https://github.com/go-yaml/yaml/tree/v2.2.2{/dir} https://github.com/go-yaml/yaml/blob/v2.2.2{/dir}/{file}#L{line}">
</head>
<body>
go get gopkg.in/yaml.v2
</body>
</html>

I can't reproduce this locally, but I expect that yaml.v2 has been cached somewhere for me.

Allow any ref?

Are there plans to just allow any ref to be fetched? Right now only branches are supported.

Source code links on godoc.org pages

GoDoc.org (like godoc) provides links in the documentation to the source code when the viewer clicks on the function name.

For code hosted on the major sites (github, bitbucket, google code) the links are present and work correctly, but no links are present on gopkg.in packages.

Add support for packages with underscores

gopkg considers this repo an unsupported URL pattern even though the github repo exists: http://gopkg.in/nickjones/proc_box.v1.

Add support for package names containing dots

gopkg.in considers the following URL invalid though it should map to a GitHub repo that exists: http://gopkg.in/errcw/glow.v0/gl-core/4.4/gl. I believe this is the result of the URL parsing regular expressions being too strict.

go get: remote error: tls: internal error

Hi,

It seems the gopkg.in is no longer reachable through HTTPS. Did the certs expire or something? It would be nice to have this fixed soon as our project depends on some packages in gopkg.in.

https fetch failed: Get https://gopkg.in/redis.v5?go-get=1: remote error: tls: internal error
package gopkg.in/redis.v5: unrecognized import path "gopkg.in/redis.v5" (https fetch: Get https://gopkg.in/redis.v5?go-get=1: remote error: tls: internal error)```

Allow specifying v0 minor versions

Hi, assume I have a library which is unstable and in v0 but still being used in several other projects. I don't want to switch major version to 1 yet as backwards incompatible changes are still being made frequently.

However I want my other library dependent projects stick to some particular v0 versions (let's say project Foo uses v0.1 and project Bar uses v0.2) and not break anytime backwards incompatible changes are introduced to the library. And as I see this is currently not possible with v0 packages (getting a message like package gopkg.in/foo/bar.v0.2: unrecognized import path "gopkg.in/foo/bar.v0.2").

I understand we could switch the major version anytime breaking changes are introduced but having a library of version v13.1.5 which is not production ready is funny.

Is there a chance you start supporting minor versions for v0 projects and if so would you accept PR with such a change? Hopefully I could find some time to dig into your code and make appropriate changes.

Thanks!

Installed binary contains version number in name

Running

go get -u gopkg.in/alecthomas/gometalinter.v1

I get an installed binary called gometalinter.v1. I would expect to simple call a binary called gometalinter directly, but that does not work.

Is that something that can be fixed in gopkg? Or is this dependent on logic within go get?

Importing gopkg and using it on a custom domain?

I would like to propose allowing people to write their own Go HTTP server with import "github.com/niemeyer/gopkg" or perhaps import "gopkg.in/gopkg.v1".

The primary purpose would be:

Importing packages running on custom domain (e.g. example.com/pkg.v1 -> github.com/specificuser/pkg), identical to self-hosting (see #16).
Allow custom home pages, and other web pages, at example.com.
Allow custom package pages, e.g. visiting example.com/pkg.v1 in a browser could display a custom page with news about the package or other things.

The package would need to expose a way to:

Ask gopkg to handle a given HTTP request by writing an appropriate response, it would be no-op if the path was not a package (e.g. example.com/some/page.html would be no-op).
Determine if a net/url.URL is a package path (e.g. example.com/pkg.v1) so that a custom package page can be rendered.

Would others find such a feature useful?

Support for Gitlab ?

How about Gitlab.

Failed to connect to gopkg.in port 443: Operation timed out

I am not sure if this is the appropriate forum to bring up such issue, but here goes.

When I run go get -v gopkg.in/yaml.v2 while on my corporate VPN, I get the error: Failed to connect to gopkg.in port 443: Operation timed out, but go get works just fine on my home network.

Additionally, I can't even hit https://gopkg.in on corporate VPN, but works fine on my home network.

I originally suspected my corporate VPN / strict firewall policies to be the problem, but I was able to hit a number of *.in domains.

I am starting to think that perhaps gopkg.in has blocked the egress IP address of my corporate VPN.

Any ideas?

Occasional EOF

https fetch failed: Get https://gopkg.in/mgo.v2?go-get=1: unexpected EOF

Sorry, no more details than that. I see this error occasionally.

Fetch list of available versions

I'd like to get able to ask gopkg.in for available versions of a package.

For example, I do a GET gopkg.in/stretchr/graceful.vlist or similar, and I receive a JSON (or otherwise) response containing a list of all available versions for this repository.

This would be useful for tools. For example:

A tool to insert the appropriate, latest version (or show you a list), import for a package
A tool to scan your project for gopkg.in imports and inform of new releases
A tool to scan your project and inform you of imports that can be changed to gopkg.in
A tool to, on save, inform you of imports that can be converted to gopkg.in imports

Effectively the goal is to make it easy to discover and use gopkg.in import paths for packages, hopefully encouraging developers to use it more.

Gitlab support?

Am I right that atm only github.com is supported? What about self-hosted Git instances? Can we add support for other sites, too?

Doesn't seem to be pulling the correct version

https://gopkg.in/fsnotify/fsnotify.v0 reports v0.14.0, as it should be.

But when I do a fresh go get -u gopkg.in/fsnotify/fsnotify.v0 and less CHANGELOG.md, I only see v0.9.0.

Also, the documentation at http://godoc.org/gopkg.in/fsnotify/fsnotify.v0 is showing the old v0.9.0 API.

I'm not sure why this is. Is it just pulling the wrong tag from the right repo?

Or worse, is it pulling the wrong repo altogether. Perhaps https://github.com/howeyc/fsnotify? As you can see, http://gopkg.in/howeyc/fsnotify.v0 points to v0.9.0.

How do you reference a versioned sub-package?

For example, if router.go of main uses trie package in a subdir, I tried gopkg.in/GlassyMedia/go-json-rest/trie.v1 but it doesn't seem to work. Is this feature available?

I can send in a pull request if you point me in the right direction on how to patch it.

├── router.go
├── router_benchmark_test.go
├── router_test.go
├── status.go
├── status_test.go
├── test
│   └── util.go
├── timer.go
└── trie
    ├── impl.go
    └── impl_test.go

Consider moving away from StartCom for SSL certificate

This is what happened when I disabled StartCom from the list of System Root CAs, which prevented package manager (Glide in my case) from fetching any gopkg.in dependencies.

Consider the community's response to what WoSign and StartCom did, it's a good practice to disable them. Maybe switch to Let's Encrypt?

beta version 0.1 and 0.2

@nuveo maintains a software called pREST that this in the beta version, today we generate version 0.2 that is not compatible with 0.1, how to deal with this case in gopkg?

gopkg.in/nuveo/prest.v0.1 (not working)
gopkg.in/nuveo/prest.v0.2 (not working)
gopkg.in/nuveo/prest.v0 (call branch v0.2 working)

gopkg.in seems to fail when there is no master repository

I created a new organisation, github.com/go-myorg, and a new repository, github.com/go-myorg/myorg, then pushed a "v1" branch in that repo.

gopkg.in did not recognise the branch (I got an error saying that the branch was not found).

When I pushed a "master" branch to that repo, gopkg.in/myorg.v1 immediately started working.

"cannot talk to GitHub"

For some reason it cannot talk to GitHub. The requests time out. GH is up. Must be something between your server and GH.

changeRefs implementation causes an ambiguous default branch.

The default branch of a git repository is its remote HEAD branch.

In modern versions of Go, go get respects the default branch and uses it.

I have a tool that verifies that a Go package has the default branch checked out (and lets you know if it's not). It's currently failing to work correctly on some gopkg.in repositories. This is because the implementation of changeRefs does something that causes the remote HEAD to be ambiguous.

Consider gopkg.in/sourcemap.v1 import path.

If I go get (or git clone) it and cd into the directory:

$ git remote show origin 
* remote origin
  Fetch URL: https://gopkg.in/sourcemap.v1
  Push  URL: https://gopkg.in/sourcemap.v1
  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    master
    v1
  Remote branches:
    master tracked
    v1     tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Note:

  HEAD branch (remote HEAD is ambiguous, may be one of the following):
    master
    v1

On the other hand, a regular git repository such as github.com/gorilla/mux typically prints:

$ git remote show origin 
* remote origin
  Fetch URL: https://github.com/gorilla/mux
  Push  URL: https://github.com/gorilla/mux
  HEAD branch: master
  Remote branches:
    custom-context   tracked
    master           tracked
    matcher-refactor tracked
    subexp-fix       tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Note the single unambiguous value in HEAD branch: master.

This issue was originally reported at shurcooL/Go-Package-Store#72 (/cc @mvdan), you can see it for more details.

You can reproduce it by running this code:

package main

import (
	"fmt"
	"log"

	"github.com/shurcooL/vcsstate"
)

func main() {
	rv, err := vcsstate.NewRemoteVCS(vcs.ByCmd("git"))
	if err != nil {
		log.Fatalln(err)
	}
	branch, revision, err := rv.RemoteBranchAndRevision("https://gopkg.in/sourcemap.v1")
	fmt.Printf("branch = %q\nrevision = %q\nerr = %v\n", branch, revision, err)

	// Output:
	// branch = ""
	// revision = "6e83acea0053641eff084973fee085f0c193c61a"
	// err = HEAD branch not found in ls-remote output
}

On the other hand, a git repository from github results in:

branch, revision, err := rv.RemoteBranchAndRevision("https://github.com/gorilla/mux")
fmt.Printf("branch = %q\nrevision = %q\nerr = %v\n", branch, revision, err)

// Output:
// branch = "master"
// revision = "599cba5e7b6137d46ddf58fb1765f5d928e69604"
// err = <nil>

RemoteBranchAndRevision internally uses git ls-remote --symref remoteURL HEAD refs/heads/*, see its code.

You can also compare the output of:

curl -A 'git/2:2.1.1+github-607-gfba4028' 'https://github.com/gorilla/mux/info/refs?service=git-upload-pack'
curl -A 'git/2:2.1.1+github-607-gfba4028' 'https://gopkg.in/sourcemap.v1/info/refs?service=git-upload-pack'
git ls-remote --symref 'https://github.com/gorilla/mux' HEAD 'refs/heads/*'
git ls-remote --symref 'https://gopkg.in/sourcemap.v1' HEAD 'refs/heads/*'

I believe the root issue is in changeRefs and that needs to be fixed.

I'm using git version 2.10.1 (Apple Git-78) and go version go1.8 darwin/amd64.

Please let me know if you need any more information to reproduce this @niemeyer. Thank you.

docs at gopkg.in don't mention the -unstable tag.

They could do with updating in the light of http://blog.labix.org/2015/01/13/improvements-on-gopkg-in

Popular packages

I think it would be a big improvement if http://gopkg.in showcased popular packages that are conforming to the versioning standards and being heavily used. This would help adoption and give incentives to package maintainers to share the word about gopkg.in.

go get fails with status 301

run:

$ go get gopkg.in/yaml.v2

result:

# cd .; git clone https://gopkg.in/yaml.v2 /Users/akupila/go/src/gopkg.in/yaml.v2
Cloning into '/Users/akupila/go/src/gopkg.in/yaml.v2'...
error: RPC failed; HTTP 301 curl 22 The requested URL returned error: 301
fatal: The remote end hung up unexpectedly
package gopkg.in/yaml.v2: exit status 128

I suspect this could be related to the recently added Let's Encrypt support. I'm not very familiar with how git clone works under the hood but some quick googling and found https://github.com/gitlabhq/gitlabhq/issues/3892

Question: How to be notified of package updates when using gopkg.in?

Suppose I import "gopkg.in/pipe.v1" in my project, and one day there's an improved API-breaking change, which is available as "gopkg.in/pipe.v2".

If the same improved API-breaking change happened for a package not using gopkg.in, it's likely (but not guaranteed) that I would find out when I update that Go package via go get -u and find that my code no longer compiles. Then I can proceed to look at the API change and update to new, improved API.

How can I find out about potential new versions for packages that do use gopkg.in?

Public Report Not Activated

There's an uptime report link on the website, but when I follow it, it tells me:

Public Report Not Activated

point to SHA?

Is there any way to currently pull a specific git commit via sha? instead of relying on branches and tags?

Thank you

Support development branches

This is a pain point that has shown up a few times and I think we should address, so here is the rationale and a candidate plan for it.

In a few cases I wanted to share an unstable sneak peak of the next API version. The most recent case at hand was the gopkg.in/qml.v0 => v1 migration. The problem was that the new project API version was still being worked on at a fast pace, breaking every day, and at the same time there were people interested in experimenting and helping out on the new API. This forced the early release of gopkg.in/qml.v1, with an unstable qml.v1/gl subpackage, which is not great and kills the expectation of stability that we want to create. This also sounds like a common problem, that we should address for everybody with a well known pattern rather than struggling every time.

So the current plan is to introduce support for vN-dev selector in URLs, which map to the vN*-dev tag/branch. In the example cited, this would allow the development of v1-dev publicly, while clearly marking the content as in-development. Once the daily breakages stop, it can be tagged/copied into the v1 release appropriately and as usual.

Please feel free to provide feedback here. If there are no major uncovered points, I'll work on this soon.

Latest git does not follow redirects by default, breaking gopkg.in

See kubernetes/kubernetes#39583 for an example of this failure

Display nice error pages

Error pages should display more information.
For instance, once a package has created a version branch, the pkg.v0 will be invalidated. Right now this is displayed as:
GitHub repository at https://github.com/go-yaml/yaml has no branch or tag "v0", "v0.N" or "v0.N.M"
This could be a page explaining that the package might have launched it's firsts version. e.g.:
Maybe this package was released under a stable version number. Try <a>pkg.v1</a>

Also; it wouldn't hurt to have all errors in the same styling as the home and pkg page. We could do this by creating a generic "error" page.

If you agree, I'm willing to start working on it.

cannot talk to GitHub

$ go get github.com/micro/go-config
package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: read tcp 10.233.243.127:52710->35.196.143.184:443: wsarecv: An existing connection was forcibly closed by the remotehost.)

getting master instead of v1

██ go get -u gopkg.in/mattes/migrate.v1

will result in pulling master on https://github.com/mattes/migrate instead of branch v1, any idea how that can happen

Allow tags without “v” prefix

How to add projects without the v prefix ?

gopkg.in/v2/yaml broken (?)

Not sure where the problem lies here, but external systems reference gopkg.in/v2/yaml , which cannot be resolved by go get (go get gopkg.in/yaml.v2 works though)

e.g. https://github.com/GoogleCloudPlatform/kubernetes/blob/master/Godeps/Godeps.json

Is that incorrect, and/or did something change at gopkg.in?

gopkg.in/srwiley/oksvg.gradfix does not resolve

I would like to import the gradfix branch of https://github.com/srwiley/oksvg.

gopkg.in/srwiley/oksvg.gradfix does not resolve to the gradfix branch of https://github.com/srwiley/oksvg, instead it says

Unsupported URL pattern; see the documentation at gopkg.in for details.

Why?

Reference:
srwiley/oksvg#15 (comment)

Always returning HTTP 301

Doing go get gopkg.in/yaml.v2 on my machine or any package from gopkg.in fails with the error:

$ go get -v gopkg.in/yaml.v2
Fetching https://gopkg.in/yaml.v2?go-get=1
Parsing meta tags from https://gopkg.in/yaml.v2?go-get=1 (status code 200)
get "gopkg.in/yaml.v2": found meta tag main.metaImport{Prefix:"gopkg.in/yaml.v2", VCS:"git", RepoRoot:"https://gopkg.in/yaml.v2"} at https://gopkg.in/yaml.v2?go-get=1
gopkg.in/yaml.v2 (download)
# cd .; git clone https://gopkg.in/yaml.v2 C:\gocode\src\gopkg.in\yaml.v2
Cloning into 'C:\gocode\src\gopkg.in\yaml.v2'...
fatal: The remote end hung up unexpectedly
error: RPC failed; HTTP 301 curl 22 The requested URL returned error: 301
package gopkg.in/yaml.v2: exit status 128

Does it have to do with the location of my machine? Singapore.

Support for full version or arbitrary references

I'm not sure if this is philosophically opposed to the gopkg philosophy, but I figured creating an issue was the best way to see if it could be done :).

I am new to Go, but my company is switching from a primarily javascript/Node.js backend to a Go backend.

With package and dependency management systems in other languages (Java, Node), I've had enough bad experiences surrounding automatically pulling in updated code that supposedly follows semantic versioning that I have completely written off any sort of automatic resolution of semantic versioning and, instead, prefer to know exactly which version I am dealing with, always.

This is also required if you want "repeatable builds". Where a "repeatable build" is defined as the output from multiple builds done on different machines (but with the same architecture) should produce the exact same output. If your build system might pull down a different version of a library, then the output can be different.

For these reasons, I'd like to request the ability to specify the full, exact version that I would like to depend on with gopkg.

I can probably help out with a PR if you point me in the right direction for what to adjust.

License?

Are you planning on licensing this? I would definitely be interested in using this, or parts of it at least, for my personal repos as well as a possible community site I've been working on.

Upgrading to OSX 10.12.1 breaks the ability to "go get" packages from gopkg.in

Can not get packages like go get gopkg.in/alecthomas/kingpin.v2. It will fail with the following error: Unknown SSL protocol error in connection to gopkg.in:-9838

Unknown SSL protocol error in connection to gopkg.in:-9838

$ go get gopkg.in/ini.v1
# cd .; git clone https://gopkg.in/ini.v1 ./src/gopkg.in/ini.v1
Cloning into './src/gopkg.in/ini.v1'...
fatal: unable to access 'https://gopkg.in/ini.v1/': Unknown SSL protocol error in connection to gopkg.in:-9838
package gopkg.in/ini.v1: exit status 128

$ go version
go version go1.7.4 darwin/amd64

I use macOS v10.12.3 (16D17a)
This error is constant for several months, but on Linux there are no errors.

gopkg.in prefers 'go1' branch over 'v1.0.9' branch?

It appears that gopkg.in prefers the go1 branch over a properly versioned branch? This seems like a bug to me. One specific reason for which I want a go1 branch is to force users to use the gopkg.in imports for master without having custom import comments in the master branch itself (which is impractical for development).

I created a test repo: https://github.com/rightscale/gopkgintest which has master, go1 and v1.0.9 branches. They all have slightly different simple.go to make them easy to identify. Here's what I get:

$ cd /tmp
tve@h:/tmp$ mkdir -p go/src
tve@h:/tmp$ cd go/src
tve@h:/tmp/go/src$ export GOPATH=/tmp/go
tve@h:/tmp/go/src$ go get -v gopkg.in/rightscale/gopkgintest.v1
Fetching https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
Parsing meta tags from https://gopkg.in/rightscale/gopkgintest.v1?go-get=1 (status code 200)
get "gopkg.in/rightscale/gopkgintest.v1": found meta tag main.metaImport{Prefix:"gopkg.in/rightscale/gopkgintest.v1", VCS:"git", RepoRoot:"https://gopkg.in/rightscale/gopkgintest.v1"} at https://gopkg.in/rightscale/gopkgintest.v1?go-get=1
gopkg.in/rightscale/gopkgintest.v1 (download)
gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src$ cd gopkg.in/rightscale/gopkgintest.v1
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ git status
HEAD detached at origin/go1
nothing to commit, working directory clean
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ cat simple.go
package gopkgintest

func branch() string { return "go1" }
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$
tve@h:/tmp/go/src/gopkg.in/rightscale/gopkgintest.v1$ go version
go version go1.4 linux/amd64

Badge

I'd like to create a badge that displays the latest version in READMEs:

It would link to the package page on gopkg.in.

Having already done the badge for GoDoc, I'd be happy to take this on (when I have a spare evening or two).

Self hosted

Hi @niemeyer,

This is not an issue, more of a question really. Is there any plan to add support for self hosted deployments. It would be really cool if we can use this tool internally. I was reading through the code, and I suppose to do such a thing would be quite doable, for the most part it's about replacing "gopkg.in" with a variable (perhaps flag) and other such values which are now hard coded.

Would you be accepting pull requests for these additions? Do you have any guidelines or recommendations for contributing?

Thanks,
Alex

git clone stats

Since gopkg is making a MitM between the real repository and the clients, we can track the number of clones and some other cool metrics. I will love know a bit more about how often are my packages used.

Caveats:
The bad part of this is that for keep the stats the service will require storage.

I can work in this feature if fits on the project scope.

Having problem with version "v0"

When hitting the link:
http://gopkg.in/igm/sockjs-go.v1/sockjs
I get correct gopkg.in page.

However I have problems when referencing "v0" in the same way:
http://gopkg.in/igm/sockjs-go.v0/sockjs
I get an error:

GitHub repository at https://github.com/igm/sockjs-go has no branch or tag "v0", "v0.N" or "v0.N.M"

Also $ go get http://gopkg.in/igm/sockjs-go.v0/sockjs fails. As far as I understand "v0" should reference "master" branch on github and I'm not completely sure but I think it worked correctly couple of days/weeks ago. Has anything changed or is it me doing something wrong?

Expect issues with gopkg.in

Hello, folks!

I'm using your project and everything working well. I working from MacOS, CentOS 7 and everything goes smoothy.

But from one server with CentOS 6 I expected so huge issues:

git clone -v https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
......

And process hangs.

I have traced it with strace:

strace -f -etrace=connect git clone -v https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
Process 166342 attached
[pid 166342] connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 166342] connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 166342] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("107.178.216.236")}, 16) = -1 EINPROGRESS (Operation now in progress)
Process 166343 attached
[pid 166343] +++ exited with 0 +++
[pid 166342] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=166343, si_status=0, si_utime=0, si_stime=0} ---
Process 166344 attached
[pid 166342] connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(6, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("107.178.216.236")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 166342] connect(9, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.133.100.100")}, 16) = 0
[pid 166342] connect(9, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("192.30.252.129")}, 16) = -1 EINPROGRESS (Operation now in progress)

So as you can see we have issues with Git itself.

I have checked another server from another network with CentOS 6 and same Git tool version and got same issues:

git clone https://gopkg.in/tomb.v2
Initialized empty Git repository in /root/tomb.v2/.git/
....
it hangs too

Could you test it and fix? I could offer any debug details.

niemeyer / gopkg Goto Github PK

gopkg's People

Contributors

Stargazers

Watchers

Forkers

gopkg's Issues

Recommend Projects

Recommend Topics

Recommend Org