Replacement for -X link option
by Brad Smith
The go tool link command has a -X option (see go doc cmd/link):
-X importpath.name=value
Set the value of the string variable in importpath named name to value.
This is only effective if the variable is declared in the
source code either uninitialized
or initialized to a constant string expression. -X will not
work if the initializer makes
a function call or refers to other variables.
Note that before Go 1.5 this option took two separate arguments.
In a spec file using -linkmode=external is there an equivalent option
to -X above?
An upstream project uses -X in their makefile to set the Version
string to a value other than "unknown". One option that works for a
spec file is to just use sed to set the Version string to the desired
value but I was wondering if there was an equivalent linker flag that
can be used that will replicate -X above.
thanks
Brad
1 week, 3 days
Issues packaging transifex-cli
by Mikel Olasagasti
Hi all,
I'm trying to package transifex-cli but I find the following error in
the %install phase:
/usr/bin/strip:
/builddir/build/BUILDROOT/transifex-client-1.6.10-1.fc41.x86_64/usr/bin/tx(__.PKGDEF):
Unable to recognise the format of file: file format not recognized
/usr/bin/strip:
/builddir/build/BUILDROOT/transifex-client-1.6.10-1.fc41.x86_64/usr/bin/tx(_go_.o):
Unable to recognise the format of file: file format not recognized
%check phase is OK and during the final phase this is reported:
Provides: transifex-client = 1.6.10-1.fc41 transifex-client(x86-64) =
1.6.10-1.fc41
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Processing files: transifex-client-debugsource-1.6.10-1.fc41.x86_64
error: Empty %files file /builddir/build/BUILD/cli-1.6.10/debugsourcefiles.list
RPM build errors:
Empty %files file /builddir/build/BUILD/cli-1.6.10/debugsourcefiles.list
Finish: rpmbuild transifex-client-1.6.10-1.fc41.src.rpm
Finish: build phase for transifex-client-1.6.10-1.fc41.src.rpm
Spec[1] doesn't have anything special and build logs are available[2].
It fails for all current Fedora versions.
Any idea what could be happening?
Regards,
Mikel
[1] https://github.com/mikelolasagasti/transifex-client-specs
[2] https://copr.fedorainfracloud.org/coprs/mikelo2/transifex-client/build/72...
1 week, 6 days
The Docker Stack and Go Vendoring
by Maxwell G
Hi everyone,
Intro
There have been on-and-off discussions within the Go SIG about vendoring
dependencies. To put my thoughts into words, I wrote a blog post [0]
about the issues with Go dependency de-vendoring that Fedora currently does.
Docker stack vendoring
I worry that the current approach to dependency management is
unfeasible—especially for complex package stacks like
Containerd/Docker/Moby. These packages and the underlying libraries have
huge dependency trees and circular dependencies and have been
out-of-date for months or longer. moby-engine already takes a
complicated, hybrid approach to vendoring (part of the package uses
vendored dependencies, part does not), while containerd is all
un-bundled. Getting everything up-to-date will require a significant
amount of work that nobody has stepped up to do, and in my view, is
ultimately unsustainable. Last year, I onboarded new contributors, as I
no longer could dedicate time to maintain these packages, but it was
also difficult for them to keep up with the web of dependencies.
I propose we start with fully vendoring the Docker stack. As I said,
parts of moby-engine are already bundled, and so are podman, kubernetes,
cri-o, containernetworking-plugins, and other applications in the
written-in-Go containerization stack. I have been working on revamped
Docker stack packages at [1]. I believe that the simplified packaging
approach will entice new maintainers to come onboard—I have already
reached out to one. I also wrote specfiles for Docker Buildx and Docker
Compose v2 that were not feasible to package with the previous approach.
Overall Go ecosystem
Then, we can re-evaluate the overall state of the Go library ecosystem.
I am not proposing that we immediately mass retire all Go libraries and
vendor everything, but I think we need to consider the overall health of
Go applications in Fedora and consider vendoring in at least some cases.
I will also note the Go Packaging Guidelines' current stance on the
vendoring[2]:
> At the moment golang projects packaged in Fedora SHOULD be unbundled
> by default. It means projects are built from dependencies packaged in
> Fedora.
>
> For some project it can be reasonable to build from bundled
> dependencies. Every bundling needs a proper justification.
>
Vendoring the Docker stack is allowed under this guideline. Any more
drastic steps to mass de-vendor certain packages or use vendoring for
any new packages would obviously require guidelines changes—but again,
we are not there yet. There is more tooling work to be done and more
discussion to be had.
go-vendor-tools
I have been working on go-vendor-tools [3], a tool to enable packaging
vendored Go applications in a Guidelines-compliant way, for the past
couple weeks. go-vendor-tools aims to make creating fully reproducible
vendor archives and handling licensing a relatively frictionless
process. The tool also natively supports regenerating vendor tarballs to
apply security updates[4].
See [5] for instructions to test the latest go-vendor-tools and the
current iteration of the go2rpm code to allow automatically generating
vendored Go package specfiles. I look forward to your feedback.
***
If you have read this far, thank you! Any feedback about the Docker
stack or Go vendoring overall is welcome.
Best,
Maxwell
[0] https://gtmx.me/blog/fedora-go-unbundling-is-broken/
[1] https://git.sr.ht/~gotmax23/docker-ng
[2]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundle...
[3] https://fedora.gitlab.io/sigs/go/go-vendor-tools/
[4]
https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#security-updates
[5] https://gitlab.com/fedora/sigs/go/go2rpm/-/merge_requests/4
--
Maxwell G (@gotmax23)
Pronouns: He/They
2 weeks, 4 days
Re: Golang bundled() Provides generator
by Maxwell G
On Tue Apr 2, 2024 at 17:16 +0200, Dan Čermák wrote:
> Hi Maxwell & Go SIG,
Hi Dan,
Thank you for reaching out!
> we have recently started working on introducing a bundled() provides
> generator for golang in openSUSE and found a very simple solution using
> the output of `go version -m /path/to/binary` [1]
It seems that only works when builds are performed with GO111MODULE
turned on[1]. We have it turned off by default, although I suppose we
can turn it on when doing vendored builds—we only need to turn it off
when using the RPM-packaged dependencies for un-vendored packages.
Without GO111MODULE, the dep information doesn't show up with "go
version -m."
[1] https://go.dev/blog/go116-module-changes
> The solution is of course only that simple, because we build more or
> less all go binaries with vendored dependencies and hence we do not need
> to distinguish between those build with vendored and those build
> without.
>
> As I would like to align the Fedora and openSUSE go packaging closer
> together and hence, if possible, find a solution to use this generator
> for both Fedora and openSUSE. I think it is a bit simpler and does not
> require to ship the modules.txt in the final rpm. However, I see that
> both are rather weak reasons.
>
> Do you see a way how we can find a common solution? E.g. by having a
> macro %go_enable_bundled_provides that would set an environment variable
> and enable the bundled generator?
Other than the technical issue with GO111MODULE, I still prefer
modules.txt approach. It is more efficient, as we don't need to process
every single binary file in the package, and it requires explicit opt-in
from the packager.
Best,
Maxwell
3 weeks, 6 days
