-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build error regarding h2quic #2560
Comments
@marten-seemann what do you think should be done here? |
Nothing needs to be done here. Caddy has its vendored version of quic-go, so the current state of the quic-go repository is irrelevant. |
Alright, thanks. Closing this then. |
I have the same issue when building from source. I don't see the vendored code in caddy. I'm following the build instructions from the README.md |
Same here, I am getting the exact same issue |
We no longer use vendor, starting with 1.0 beta 1. Are you in a GOPATH? Try setting |
Yes, this should fix this. |
Good evening, I am running into this issue as well. Setting
Is there something else I should be doing or setting? |
@wP99DhYrMMTYbfAvgiWm v0.11.5 does not use Go modules, so you'll need to use v1.0.0-beta1. |
Thanks for the quick reply! The strange thing is I am getting the code using Disclaimer: As you can no doubt tell, I am fairly new to Go. Please forgive me for any stupid things I might say :D |
Don't worry, I'm also new to this (Go modules, anyway) hence the beta period. :) What does |
Huh, apparently the docs on modules are missing some critical information: https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies -- says
But actually it ignores beta releases. Edit: I just updated the wiki page so it at least says it now... |
Huh, I would not have guessed that. Features, I suppose 😛. I'm fine with running 0.11.5 for now, but unfortunately this still does not build due to the errors mentioned above (when using
Edit: I guess this makes sense. Even though I'm using an older version of Caddy, the One other possible solution I came up with was to clone the entire Caddy repo, replace all instances of
(I am ignoring the possibility that it would still not build with the updated |
If you check out v0.11.5, it should give you the vendor folder and use it, and it should build OK as far as I know. |
I see. A final question then: how would I go about doing this? I have attempted this using both Update: It is possible to get the beta version using the commit hash (using -tags does not work):
This still results in an error around markdown, but at least we now have the beta version!
|
Hi, I hope I can help you. Caddy v0.11.5 does not support modules. Because of this, these problems occur. If you want to build Caddy v0.11.5, you will have to use these instructions. (
If you want to build Caddy v1.0.0-beta1, you will have to use these instructions.
or
|
Hi @elcore, Thank you for the clear instructions, this helped me get it working! Much appreciated. |
I think this should be reflacted in the readme. I ended up with the following: export GO111MODULES=off
mkdir -p "$(go env GOPATH)/src/github.com/mholt/caddy"
cd "$(go env GOPATH)/src/github.com/mholt/caddy"
git clone https://github.com/mholt/caddy .
git checkout -f -b build 80dfb8b2a7f89b120a627bc4d866a1dc5ed3d92f
mkdir -p "$(go env GOPATH)/src/github.com/caddyserver/builds"
cd "$(go env GOPATH)/src/github.com/caddyserver/builds"
git clone https://github.com/caddyserver/builds .
git checkout -f -b build c62e2219460a8828970dad09212c3a4cec40b56c
cd "$(go env GOPATH)/src/github.com/mholt/caddy/caddy"
go run build.go Why do we need to use this |
We will upgrade the instructions, you just need to run
To enable proper versioning of Caddy binaries. |
Additionally, modules have the advantage that you can build them outside your GOPATH.
|
My question is: why would we want this code to be in a separate repo ( I'm not using modules because I need a very particular version of the caddy (commit hashes are for an older version in my real use case) - and used the vendoring setup back then. I'm also donig Of course, moving to the latest version could solve some of the issues - but it has other problems (with dependencies) that are blocking me from doing just that. I'll look into it later. I'm just saying that for now I've came up with a workaround that's good enough for us - but this was not trivial. Please reconsider making |
That is okay, you can use an older version of Caddy.
It is not broken,
What is the issue?
Caddy is go-get-able... |
In my case the behavior is pretty obvious. Remember, I need an older version of caddy. With modules enabled usual By the way, it would be great if somebody notify go team about the issues we encounter here - as this is the very feedback they look on the new mod system. |
That's the whole point, if you enable modules, vendor will be ignored. |
So, if you want |
|
Disabling modules will not help. You still have to do :/ |
Thank you for the explanation, which I find useful, as I am still learning modules here! 😇 To be fair, though, I've been referencing these resources for on and off for about a week:
And not only are all those pages (the last 2 especially) huge walls of text, their docs are not totally consistent. For example, the wiki doesn't mention that prerelease tags are ignored (until I added a blurb to it myself). The go cmd docs say that So it's all trial and error for me at this point. The docs have been mediocre and the transition has been frustrating for everyone. I appreciate everyone's patience. |
This works pretty well, you don't have to use
|
If that worked then our CI would not break, which it did. At the very step 1. @elcore, if you still insist that it works after reading my comment above - I find it hard to follow your reasoning. |
I feel much less stupid now. |
@MOZGIII I hope this can help you. Edit: Here I explicitly disabled modules, just to be sure. |
I do not know, how your build environment (CI) is configured. I am using Ubuntu 18.10, with Go 1.12.4. If I can help you in any way, feel free to message me eldinhadzic [at] protonmail.com |
Are you starting from scratch? Empty |
Yes, I am starting from scratch. On a side note, I would recommend you to update to Go 1.12.4 |
Ok, let's go through what
The worst this is what exactly is being attemped to be downloaded depends on the state of the current Regarding Go 1.12.4 - definetly a good idea. We already got our toolchain updated after we encountered this issue. |
Frankly, you shouldn't be relying on I can definitely vouch for @elcore and that he's doing what he can to help you. He's not trolling. We've also learned a lot here when it comes to With all that said, your feedback about this is definitely appreciated, it's helping uncover edge cases of the build tooling. Thanks for that. |
Ok, once again. @francislavoie, My proposal for installing older version does not have that issue: export GO111MODULES=off
mkdir -p "$(go env GOPATH)/src/github.com/mholt/caddy"
cd "$(go env GOPATH)/src/github.com/mholt/caddy"
git clone https://github.com/mholt/caddy .
git checkout -f -b build 80dfb8b2a7f89b120a627bc4d866a1dc5ed3d92f
mkdir -p "$(go env GOPATH)/src/github.com/caddyserver/builds"
cd "$(go env GOPATH)/src/github.com/caddyserver/builds"
git clone https://github.com/caddyserver/builds .
git checkout -f -b build c62e2219460a8828970dad09212c3a4cec40b56c
cd "$(go env GOPATH)/src/github.com/mholt/caddy/caddy"
go run build.go That said, I'm unsubbing from this issue as I feel there's enough context by now for people to see my point of view on the issue. One last note: maybe it's a good idea to re-add |
Great to hear that from you.
Your reasons are totally valid, it does pull some thirdparty repos over the network.
I was trying to show you, that the build will be successful, if you follow instructions I have provided.
I am very sorry, if you felt like I was trolling you! I was just trying to be helpful, the transition to modules is not as easy as it should have been. I do not expect anything in return, I am using my resources available to help this project and its community. I even created a simple Docker container as a proof of concept a few minutes ago. https://github.com/elcore/caddy-docker
It is great that you have found a solution that works for you. |
While we are at it, I will follow Matt´s advice, and give you some space to breath. |
same problem when docker build. Is there any quick solution? |
Here is the answer and it's a hacky one: |
Because of this issue: caddyserver/caddy#2560
Hey everyone, I hope you can help. I ran into this issue recently and seeing it's been a couple of years later I'm hoping there may be some updates. How to reproduceWith xcaddy
Without xcaddy
Error
Other Info
|
Well I just read here pyed/ipfilter#46 that |
|
You're replying to a closed 4-year old issue with insufficient data and invalid repository URL. Please start by following the proper steps of how to build caddy from source, then report failures through the appropriate channels. |
When I try to build the server I'm receiving:
I noticed there was a recent change on the library renaming the directory from
h2quic
tohttp3
:Example here.
The text was updated successfully, but these errors were encountered: