-
Notifications
You must be signed in to change notification settings - Fork 51
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
Include go vendor modules for boringssl #107
Conversation
Required for services that do not allow network access to the outside during compilation (e.g. open build service etc.). When compiling, at least an 'export GOFLAGS="-mod=vendor"' must be done before.
That's right. It uses |
Q. Should those go modules be added in the same tarball? If those go modules are added in different tarball, it'll provide distributions a choice to use their own package/version. |
One possibility would be like The question is whether this is necessary to provide two different packages. See also https://go.dev/ref/mod#go-mod-vendor |
I have created an alternative with two separate packages. diff: master...munix9:android-tools:vendor3#diff Let me know what you think about this. |
I can confirm the I would like to add that excluding setting Meanwhile until this is sorted out I'll keep using the following workaround with the official source though: def do_prepare(self):
with self.pushd("vendor/boringssl"):
self.do("go", "mod", "vendor", allow_network = True) |
So the idea here would be to have the CI generate the source tarball, include vendored Go dependencies in the tarball, and then use that tarball for the release? Sounds ok too me, can we also use the CI to automatically create a GitHub release when a new tag is pushed and use the created tarball for this release (if I understand your setup correctly then the tarball is only made available as a CI artifact presently)? Alternatively: Could the |
I actually wanted to keep it simple, so I put it inside the What might be possible would be an additional cmake option, for example (untested):
|
Ok, that's fine. But is the idea to include vendored Go dependency in the release tarball (i.e. the one that can be downloaded from GitHub as well) or should they just be available as a CI artifact? Because the former is presently generated and uploaded manually by me using At Alpine we are usually also fine with downloading Go/Rust/… dependency from the internet as long as the version is fixed and the checksum is verified (ensuring that the build is reproducible). Not sure how other distributions handle it. |
Yes, valid point, I had not considered the creation of a release. How about a script (similar to package-release-tarballs.bash), e.g.
The script creates two archives, one with source code only and another archive with source code AND vendor modules. Maybe you already have something similar for building a release.
With openSUSE, a network connection is not allowed during the build. The package maintainer has to make sure that additionally needed packages are either already available in the distribution or provide an appropriate vendor archive. |
While at it anyhow, my preferred solution would be to automate release tarball creation via the CI and as part of that also include the vendored Go dependencies. So every time a new tag/release is created, the CI would vendor the Go dependencies (analog to what you propose in this PR), create a new tarball, and upload that as an artifact for the tag/release. If the CI uses a script internally that would be fine but it would be cool if the tarball creation and upload for a release would be automated. I think Go software on GitHub (like gocryptfs which you mentioned) often has similar rules in their CI setups to attach statically linked binaries (for different operating systems) to their GitHub releases. For example, the encryption tool age uses The gocryptfs repository also does that but it seems that their static binaries are not automatically uploaded by the CI? Do you think that something similar to the age workflow would be viable here too? If so, would you be interested in updating your PR accordingly?
Oh! Good to know, in that case this is definitely something we should address. |
Sure, some kind of automation makes sense. |
Sure that's fine. I will do the platform-tools-34.0.1 release as usual then today. |
Is there still something to do here after https://github.com/nmeum/android-tools/releases/tag/34.0.4 which contains the vendored boringssl sources now? |
This is about the go modules in the boringssl project. And the 34.0.4 does not contain those. |
Huh, I commented that as I no longer needed the setup I described previously (#107 (comment)) for my 34.0.4 packaging (chimera-linux/cports@1e92a03), perhaps something else changed. Full native build log of that ver fwiw https://paste.c-net.org/zvzhhipyb0rd |
I created a local build for openSUSE Tumbleweed and completely removed the requirements for the created vendor archive and the export of the GOFLAGS variable and it compiled without problems. So, yes, I also think that is no longer needed for the build. |
Would like to explain why this is no longer needed? At first, you mentioned that vendored go libraries are required when network is disabled. |
Until version 34.0.1 that was also necessary. With version 34.0.4 something was changed in the configuration and no more external go-modules are requested. I test this in a kvm environment without network and have just repeated this: |
I'm still testing this under Leap 15.4/5/6 and will let you know. The builds of version 34.0.4 on the OBS (Open Build Service) are all successful, without vendor-archive and "-mod=vendor" (and without network). Without a closer look at the differences between 34.0.1 and 34.0.4, I can't say why. So this PR is not necessary for version 34.0.4, but it doesn't hurt, because I did the first tests with vendor-archiv and they worked without problems. |
I have built this project using git repository and source tarball from release. In both cases, go executable downloads modules in |
Required for services that do not allow network access to the outside during compilation (e.g. open build service etc.). When compiling, at least an
export GOFLAGS="-mod=vendor"
must be done before.See #47