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
Initial RPM package sources #2
Conversation
| Version: 2.0.0~beta6 | ||
| %global tag v2.0.0-beta6 | ||
| Release: 1%{?dist} | ||
| Summary: HTTP/2 web server with automatic HTTPS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, in the future I think I want to make summaries/descriptions of the project more generic, something like "Web server with automatic HTTPS" (since versions will get outdated)
Will still merge of course, just wanted to mention that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that's an easy adjustment.
|
|
||
|
|
||
| %description | ||
| Caddy is the HTTP/2 web server with automatic HTTPS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Here too, a more generic description will be forthcoming. We should chat about what a standard project description should be across all packages.)
|
|
||
| func main() { | ||
| caddycmd.Main() | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also hope to simplify this main file so that the "standard" modules will be plugged in for you just by importing Caddy. That will help standardize each package I think. (Nothing you need to do here right now, just letting you know!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And you can make whatever changes you need to to this file, and the next package build will use it.
| echo "require github.com/caddyserver/caddy/v2 %{tag}" >> go.mod | ||
| go build \ | ||
| -buildmode pie \ | ||
| -compiler gc \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any downside for including -trimpath for build that doesn't expose local path of the build server and be more reproducible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar enough with go build flags to say for sure. I got these flags from Fedora's %gobuild macro. I didn't use the macro directly because it turns off go modules. Are you saying that without this flag, build server paths are encoded (maybe the wrong term here) into the final binary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. For example, on my laptop, Caddy lives in /Users/mohammed/github/caddy. If I build Caddy without it, then execute strings {caddy_executable}, you'll find lines listing the paths of Caddy source files prefixed with /Users/mohammed/github/caddy, e.g. /Users/mohammed/github/caddy/admin.go etc. With -trimpath, it'll just be github.com/caddyserver/caddy/admin.go, or something like this.
-trimpath
remove all file system paths from the resulting executable.
Instead of absolute file system paths, the recorded file names
will begin with either "go" (for the standard library),
or a module path@version (when using modules),
or a plain import path (when using GOPATH).
https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah -- I think so anyway. Stack traces include (absolute) file paths without trimpath. Trimming the path can make stack traces a little more readable and the full file paths don't mean anything useful outside of dev environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to a blogpost by Filippo, passing -s -w to -ldflags also still leaves meaningful information in the stack trace and not hinder understanding the underlying cause. But, I don't know if there are any negative consequences. Linkers are beyond my current knowledge level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Conan-Kudo Do you know if there is a reason Fedora's %gobuild doesn't include -trimpath? I found a few hits for that in the mailing list for build log output, but my recent copr builds don't have it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that @jcajka didn't know about the flag? He's the one who maintains the build flags we set for %gobuild.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carlwgeorge @Conan-Kudo the flag had landed in Apr this year in what to become 1.13, so there hasn't been really a chance for adding it with all the stuff happening in the f31. It does seem to me sensible to add it from end user perspective, compiler maintainer's..., not sure how it will be handled by the "new macros" infrastructure though. Could you please open a Fedora BZ against go-rpm-macros packageor feel free to open PR. Thanks for bringing this up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are the package sources used to build https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/.