Skip to content
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

Merged
merged 1 commit into from Oct 21, 2019
Merged

Initial RPM package sources #2

merged 1 commit into from Oct 21, 2019

Conversation

carlwgeorge
Copy link
Collaborator

These are the package sources used to build https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/.

Version: 2.0.0~beta6
%global tag v2.0.0-beta6
Release: 1%{?dist}
Summary: HTTP/2 web server with automatic HTTPS
Copy link
Member

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

Copy link
Collaborator Author

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.
Copy link
Member

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()
}
Copy link
Member

@mholt mholt Oct 21, 2019

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!)

Copy link
Collaborator Author

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.

@mholt mholt merged commit ee5797c into master Oct 21, 2019
echo "require github.com/caddyserver/caddy/v2 %{tag}" >> go.mod
go build \
-buildmode pie \
-compiler gc \
Copy link
Member

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?

Copy link
Collaborator Author

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?

Copy link
Member

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

Copy link
Member

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.

Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link

@jcajka jcajka Oct 21, 2019

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlwgeorge carlwgeorge deleted the rpm branch October 21, 2019 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants