I use a custom configuration inside a Jenkinsfile for integration in my package build CI server so posting that here would be of no use to you.
A basic command would be as simple as
fpm -s tar -t deb swift.tar.gz
You will need to add a number of other things such as dependencies, package name, version etc.
Everything is here in the documentation.
Yes, these scripts are for 5.6.3 for now. This is the last version that can be built without having a preexisting swift compiler installed as a build dependency. I need to get 5.6.3 building across all supported architectures before moving on to 5.7.x.
The files in that repo do work, but may have some rough edges. For example, the fetch_sources_and_prep_build.sh script should be copied out of the debian directory and placed into a higher level directory before running it. When it is done running you will have a new file called swiftlang_5.6.3.orig.tar.xz. Extract this into your working directory and rename it from swiftlang-5.6.3 to swiftlang_5.6.3 then copy and paste the debian directory into it. From within swiftlang_5.6.3 run a packaging command such as debuild -sa to start the build.
So, to be clear, your build directory structure needs to look like this:
your_build_dir
|-> swiftlang_5.6.3
|-> cmark
|-> debian
|-> indexstore-db
|-> llbuild
|-> llvm_project
|-> <etc>
|-> swiftlang-5.6.3.orig.tar.xz
Note that there are build dependencies listed in debian/control that must be installed first. This is meant to package swift in a way that is Debian approved and is by no means the easiest way to get the .deb files.
Now that this package is in Debian on the experimental build, you can grab the .deb files from Debian as well. Start by going to swiftlang - Debian Package Tracker then click on each of the four links under binaries at the bottom left of the web page. For each one, after you click the link scroll to the bottom of the page and click on amd64 under Architecture. Select the mirror of choice to download that .deb file.
okay. Thanks. Actually, i need 5.7.3 release.
Hello,
Actually, using the tar directly install a swift directory at root of system. I needed to add skip-components to tar parameters.
Then, I use the following dependencies :
--depends binutils
--depends git
--depends gnupg2
--depends libc6-dev
--depends libcurl4-openssl-dev
--depends libedit2
--depends libsqlite3-0
--depends libxml2-dev
--depends libz3-dev
--depends pkg-config
--depends tzdata
--depends unzip
--depends zlib1g-dev
But I have a conflict with libicu :
dpkg: error processing archive /home/swiftlang_5.7.3_amd64.deb (--unpack):
trying to overwrite '/usr/include/unicode/utf.h', which is also in package libicu-dev:amd64 72.1-3
How did you proceed with this conflict ?
Thanks for your help,
David
Hi @David_Screve I am more than happy to help where I can but do you mind moving these questions to another post they are not directly relevant to the subject of this post.
Thanks.
Hello...I succeeded in !! no more help required. Thanks a lot.
That's a shame. FWIW I've only had good experiences using swiftlang.xyz.
I see that the server workgroup has their own "swiftly" tool, which I suppose was intended to replace this service. It's natural that, after providing the service for so many years, you might feel left out by that process.
I imagine there would be a similar reaction from the maintainers of swiftpackageindex.com if Apple one day announced their own version. Everyone lives on a tightrope here.
I hope that the server workgroup (and other workgroups) consider whether there is anything they can do to ensure that members of the community who take it upon themselves to solve problems and give back to the community continue to feel involved.
Just a quick update.
I have been working on a solution and I will have the Swift Community Apt Repository up and running again very soon. Hopefully by the end of the week.
I am currently in the process of moving to new hosting and updating all the packages.
More info coming soon.
Hi everyone,
The Swift Community Apt Repository is back with new hosting, improvements and hopefully a sustainable future.
The repository is now being hosted on packagecloud. Packagecloud manage all the repository infrastructure and security which will greatly reduce my workload.
I have also rebuilt all of the swift packages using an updated compression profile which has resulted in a reduction of the package sizes by about 35%. This reduces storage requirements and will have a big impact on network bandwidth.
As the storage space is now limited I have reduced the swift versions currently available.
Supported Swift Versions are 5.7.3 / 5.8.1 / 5.9.1.
Supported Distributions are Ubuntu 20.04 / 22.04 / 23.04 and Debian 11 / 12.
Other Distributions that are based on Ubuntu are also supported.
The new packagecloud infrastructure is different which means there were some changes needed in the install scripts and user guides.
One of the main differences is that all the package versions now reside in the same repository. While this makes installing a specific version of swift easier, steps need to be taken to prevent swift being auto updated when running sudo apt upgrade.
For example:-
To install Swift version 5.7.3
sudo apt install swiftlang=5.7.3*
To hold the installed Swift version and prevent auto upgrade
sudo apt-mark hold swiftlang
I have changed all the swiftlang.xyz dns information to point to the new repository so all the previous links and install instructions will work without any changes.
To use the new repository just run the quick install script as before.
curl -s https://archive.swiftlang.xyz/install.sh | sudo bash
The install script will remove the old swiftlang.xyz sources list and install the new packagecloud.io source list and repository keys.
The install script will also detect if you are using a ubuntu based distribution like Pop!_OS and install the correct ubuntu version.
There are 2 main areas where you can help support this repository.
Donations
In previous posts some people have said that I should have asked for donations. I found these comments a bit strange as I have asked for support/donations several times on this forum, on the swiftlang.xyz website and on my GitHub repository. To keep posting requests for support/donations feels uncomfortable and wrong.
See previous support request here
Credit and Acknowledgement
If you are using the repository it would be great if you could share details on social media.
In the past there have been a number of times that my work has been used and featured in tech conferences. It would have been nice if these people had taken the time to contact me about their presentations.
(@0xTim I am still waiting for the video of the talk by Matias Piipari from the Server-Side Swift Conference. 9th December 2022)
Please let me know if there are any problems with the repository.
Neil.
BTW what I donât understand is why the install page on swift.org does not link to this repo. It is BY FAR the easiest way to install Swift on Linux. But instead there is only Docker, RPM or tarbal options, which all add friction.
If we want to promote Swift for non-Apple platforms, getting started with it should be as frictionless as possible. This repo is a great step to that goal. Why not promote it more?
I think this would mean for the Swift project to take responsibility for the distribution. Maybe that's what should happen sooner or later. As great as this solution is (thanks for the effort!), many will insist on using an "official" distribution.
I just want to echo this sentiment. I just picked up a Raspberry Pi and am doing some research on how to get Swift up and running on it. The official process is really not so great. I would ask how I could contribute to making things better, but @futurejones has already done that (kudos!). I'm happy to buy them a coffee, but wanted to advocate here for some kind of formal recognition from Swift.
My sense, after spending about a year playing around with Swift in an academic environment, is that it's a great educational language. I think there's a lot of room for it to flourish in that setting, and the work's already been done to make it accessible. Let's take advantage of it.
We have deployed production apps to a Raspberry Pi, and have used the official Docker image thus far.
is on its way.