http://bugzilla.suse.com/show_bug.cgi?id=1132101 Thorsten Kukuk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jkowalczyk@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1132101 http://bugzilla.suse.com/show_bug.cgi?id=1132101#c2 Klaus Kämpf changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |graham@andtech.eu, | |kkaempf@suse.com Assignee|graham@andtech.eu |containers-bugowner@suse.de --- Comment #2 from Klaus Kämpf --- Reassign to get raise attention -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1132101 http://bugzilla.suse.com/show_bug.cgi?id=1132101#c4 Flavio Castelli changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcastelli@suse.com Assignee|containers-bugowner@suse.de |jkowalczyk@suse.com --- Comment #4 from Flavio Castelli --- Reassigning the bug to Jeff, who is now in charge of Go packaging for SLES -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1132101 http://bugzilla.suse.com/show_bug.cgi?id=1132101#c6 --- Comment #6 from Thorsten Kukuk --- (In reply to Jeff Kowalczyk from comment #5)

If I understand the conditional correctly (expands to 0 or 01), go_provides only applies to SLE11?

Should be, yes. But I think /usr/lib/rpm/fileattrs/golang.attr is the real problem. In short: macros.go belongs to /usr/lib/rpm/macros.d, not /etc/... go_nostrip: why do we need that? What's wrong with our default debuginfo packages? This only creates really fat binaries, and as result, I often see "-s -w" in go build arguments, which throws the debuginfo really away. goprep: go mod init and go mod vendor is much more useful. /usr/lib/rpm/golang.sh: this need a security review, fix filenames in /tmp written by root? Ouch. Same for the golang.req/golang.prov files. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1132101 http://bugzilla.suse.com/show_bug.cgi?id=1132101#c7 Aleksa Sarai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asarai@suse.com --- Comment #7 from Aleksa Sarai --- (In reply to Thorsten Kukuk from comment #6)

(In reply to Jeff Kowalczyk from comment #5) go_nostrip: why do we need that? What's wrong with our default debuginfo packages? This only creates really fat binaries, and as result, I often see "-s -w" in go build arguments, which throws the debuginfo really away.

This is required because the default debuginfo stripping has caused several cases in the past where Go binaries were subtly broken (in particular, backtraces in panics were broken). I submitted patches to the post-build scripts several years ago to fix it (currently strip(1) gives an error code, but the file is still modified), but those patches weren't accepted. Ideally, if everyone used the RPM macro for "go build", then we'd use '-s -w' universally -- but as you said this means that debuginfo is completely useless.

goprep: go mod init and go mod vendor is much more useful.

I can't disagree, though we don't have internet access in our builds so you couldn't really do this in an OBS build.

/usr/lib/rpm/golang.sh: this need a security review, fix filenames in /tmp written by root? Ouch. Same for the golang.req/golang.prov files.

Yeah, this should be reviewed. The current golang.sh is a bug-compatible rewrite of the original which was written by the old Golang maintainer for openSUSE. Personally I'm not really sold on golang-packaging at all (almost nobody uses it, and those that do use it don't like it). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1132101 http://bugzilla.suse.com/show_bug.cgi?id=1132101#c9 --- Comment #9 from Jeff Kowalczyk --- (In reply to Aleksa Sarai from comment #7)

(In reply to Thorsten Kukuk from comment #6)

...

goprep: go mod init and go mod vendor is much more useful.

I can't disagree, though we don't have internet access in our builds so you couldn't really do this in an OBS build.

devel:languages:go/obs-service-go_modules is now available to help automate this step. https://build.opensuse.org/package/show/devel:languages:go/obs-service-go_mo... https://github.com/openSUSE/obs-service-go_modules -- You are receiving this mail because: You are on the CC list for the bug.