Ubuntu 18.04 APT Repository

Something which @Michael_Gottesman and I have previously discussed was the idea of an APT repository to get recent builds of the swift toolchain more readily.

I have setup such a repository at https://bintray.com/compnerd/swift that should be publicly accessible.

I am not sure about the long term hosting of the repository, as bintray has a pretty small limit and the toolchain package is ~250MiB. The packages should be uploaded hourly (after building on Azure). This means that I will probably have to figure out some solution to purging of older releases frequently. However, this should allow for an easy way to grab a toolchain at a point in time at least.

The repository contains packages for ICU, the toolchain, the Linux, Windows and Android (Swift) SDKs. The prepackaged version of these packages into a docker image are still available at http://hub.docker.com/r/compnerd/swift

Saleem

11 Likes

Cool!

I believe for Ubuntu specifically, a PPA would be the most idiomatic solution. They do seem to have a size limit of some gigabytes, but it seems you can get that limit raised if needed.

Sure, that may be idiomatic, but it comes with other restrictions (such as the code needs to be built on Launchpad, etc. This allows much better management of the CI, and the repository is largely automated and up-to-date for very little engineering effort.

Thank you very much for this. I very much appreciate your progress on the Linux port.

A few remarks:

  1. A short explanation how to use this would be nice because of 2, 3 and 4.
  2. I tried to download via apt but only get GPG errors.
  3. I downloaded the swift-toolchain deb via wget which installs but it installs into /Library which is not very linux-ey (at least /opt would be preferred), and
  4. Running "swift -v" works as expected but trying to compile a simple hello world results in

:0: error: unable to load standard library for target 'x86_64-unknown-linux-gnu'

After that I gave up (for the moment).

Wish list: Long term I think it would be desirable to join forces with the packagers of clang for Debian (https://packages.debian.org/sid/clang) where packaging is largely automated (https://salsa.debian.org/pkg-llvm-team/llvm-defaults/tree/experimental/debian). That way all distributions forking from Debian including Ubuntu would benefit.

I agree, that this really does need instructions. I cannot put up instructions on the apt URL itself, but, Im happy to put them up on the GitHub repo where Ive been collecting all the infrastructure content.

The GPG issues I'm not sure how to resolve, as that is from bintray. I am not as familiar with debian packaging as I am with gentoo and exherbo packaging, so, help in improving the packaging is definitely appreciated. I have marked bintray to sign uploaded packages (which are being uploaded from Azure), but, it seems that the JFrog gpg key is missing?

Yes, the path is not very linux-y, and I plan on keeping it this way for the time being. I completely understand the desire to have it be under /opt, I suppose I could symlink it there for the muscle memory. The reason for this is to have uniform paths across all the platforms (this means that the same path works on Linux, Windows, and macOS), hence the path selection.

Yes, the build is a bit different in that it requires the swift-sdk and swift-icu packages installed as well, AND a set of flags to be passed along. In particular, you need -resource-dir /Library/Developer/Platforms/Linux.platform/Developer/SDKs/Linux.sdk/usr/lib/swift passed along to it (you can optionally add -use-ld=lld to use the bundled lld linker).

For what it is worth, I am using these packages to build the docker image, and that should have most of this automated and setup for you :slight_smile: I just figured that others may want to use the packages as well, and this makes it easier for others to get a recent package.

This worked for me, thanks.

I understand.

swift package init does not work, the package manager isn't yet included, right?

Again, thanks.

Yeah, need a bit more work to get the devtools packaged in. Im reworking the azure pipelines to be more efficient and homogenous, which I hope will mean better test coverage. But, the devtools are pretty high on my list of things at this point. Help is of course welcome :slight_smile: I think that I have the s-p-m content being installed improperly resulting in the failure.

Terms of Service

Privacy Policy

Cookie Policy