Weekly builds
Weekly builds
I set up automatic builds from bzr. They're done every Monday, usually. If there are no source changes this week, no build is done.
The builds can be fetched from here:
Trunk builds, rebranded as "Armagetron Experimental"
0.2.8 builds, rebranded as "Armagetron Alpha"
hack builds, mostly sty+ct, various rebrandings.
Read here what quality to expect from those builds. tl;dr: not much
The rebranding makes it so that you can install versions from different branches somewhat independently from each other and from our main, stable releases. On Windows and Linux, installation is independent with different default installation directories, separate uninstallers and start menu entries. On Linux only currently, your user configuration will be independent for different brandings.
If there are no build errors, every build should contain 32 and 64 bit Linux binaries and 32 bit Windows binaries, they are all automated. Mac builds are not done every week, I need to boot up a different machines for those. And if they are done, they are usually uploaded with a delay of no more than one release.
Ubuntu and Debian users can also just use our PPA, all the automatic builds are uploaded to there, too, as the armagetronad-alpha and armagetronad-experimental packages. If you don't want to add the PPA to your software sources, you can manually download current packages (sources, too) on the package detail page. Just expand the various packages to get to their content list.
I currently cannot build Trunk Mac releases. Sorry. Will work on it.
The builds can be fetched from here:
Trunk builds, rebranded as "Armagetron Experimental"
0.2.8 builds, rebranded as "Armagetron Alpha"
hack builds, mostly sty+ct, various rebrandings.
Read here what quality to expect from those builds. tl;dr: not much
The rebranding makes it so that you can install versions from different branches somewhat independently from each other and from our main, stable releases. On Windows and Linux, installation is independent with different default installation directories, separate uninstallers and start menu entries. On Linux only currently, your user configuration will be independent for different brandings.
If there are no build errors, every build should contain 32 and 64 bit Linux binaries and 32 bit Windows binaries, they are all automated. Mac builds are not done every week, I need to boot up a different machines for those. And if they are done, they are usually uploaded with a delay of no more than one release.
Ubuntu and Debian users can also just use our PPA, all the automatic builds are uploaded to there, too, as the armagetronad-alpha and armagetronad-experimental packages. If you don't want to add the PPA to your software sources, you can manually download current packages (sources, too) on the package detail page. Just expand the various packages to get to their content list.
I currently cannot build Trunk Mac releases. Sorry. Will work on it.
Re: Weekly builds
Switched the upload for the snapshots form Launchpad to SourceForge. The Launchpad uploads are too intertwined with the other systems for my tastes, on SF it's just a big file dump not linked with anything you can organize as you see fit.
All Linux and Windows users can also use the various Zero Install feeds to keep up to date:
-Main client feed
-Main server feed
-Sty+CT client feed
-Sty+CT server feed
-Full list for fine control
All Linux and Windows users can also use the various Zero Install feeds to keep up to date:
-Main client feed
-Main server feed
-Sty+CT client feed
-Sty+CT server feed
-Full list for fine control
Re: Weekly builds
*facepalm* wrong thread, delete this post if you want
Re: Weekly builds
Latest 0.2.8 Mac build: 0.2.9_alpha_r1382
(new post because of link limit.)
(new post because of link limit.)
Re: Weekly builds
The new build system is almost ready, new builds have already been pushed to SF. Known broken:
- The portable linux apps
Also not working yet, so not available:
- 0.4 PPAs for Ubuntu
- ZeroInstall updates
Abandoned:
- Autopackage
- our own .deb builds, though I think I kicked them out way earlier already because they absolutely didn't work.
For the curious, the old build system was my Laptop running 32 bit Ubuntu, doing the 32 bit Linux and Windows builds, then enlisting the help of the 64 bit Ubuntu big PC to do the 64 bit Linux builds. Both had custom, handmade builds of all the libraries we depend on. It broke pretty badly when the two machines were upgraded. The new system is one VirtualBox virtual installation of Ubuntu 10.04, 64 bit, with a 32 bit chroot environment for the 32 bit Linux builds, both using stock libraries as much as possible, ZThread being the lone exception. GCC 4.1 is used for compilation, which is the oldest GCC you can install via the official repositories, for maximum possible convenient compatibility with older Linuxes. The new setup decouples the build system from the actual work machines and makes it super easy to keep the libraries up to date with security fixes. It loses us Autopackage and the even better backwards compatibility provided by its apbuild system, but that would only affect systems considerably older than Ubuntu 10.04, so not too many users should be inconvenienced by it. I plan to keep the build system on 10.04 for as long as possible (so, until we require a lib that does not exist on it or until it drops out of support in 2015) and at least keep a clone of it around after it is upgraded.
For managing the builds, I simply use the <branch>_build_work bzr branches, one for 64 bit, one for 32 bit, and the makefiles therein. Important tweaks: the tarball gets built on the 64 bit branch, then copied to 32 bit, the 0install files are only on the 64 bit branch and symlinked to 32 bit, the finished files are compiled from 32 to 64 before the upload there. The reason for this complication is that it's difficult to get ssh and thus bzr operations to work in the 32 bit environment.
- The portable linux apps
Also not working yet, so not available:
- 0.4 PPAs for Ubuntu
- ZeroInstall updates
Abandoned:
- Autopackage
- our own .deb builds, though I think I kicked them out way earlier already because they absolutely didn't work.
For the curious, the old build system was my Laptop running 32 bit Ubuntu, doing the 32 bit Linux and Windows builds, then enlisting the help of the 64 bit Ubuntu big PC to do the 64 bit Linux builds. Both had custom, handmade builds of all the libraries we depend on. It broke pretty badly when the two machines were upgraded. The new system is one VirtualBox virtual installation of Ubuntu 10.04, 64 bit, with a 32 bit chroot environment for the 32 bit Linux builds, both using stock libraries as much as possible, ZThread being the lone exception. GCC 4.1 is used for compilation, which is the oldest GCC you can install via the official repositories, for maximum possible convenient compatibility with older Linuxes. The new setup decouples the build system from the actual work machines and makes it super easy to keep the libraries up to date with security fixes. It loses us Autopackage and the even better backwards compatibility provided by its apbuild system, but that would only affect systems considerably older than Ubuntu 10.04, so not too many users should be inconvenienced by it. I plan to keep the build system on 10.04 for as long as possible (so, until we require a lib that does not exist on it or until it drops out of support in 2015) and at least keep a clone of it around after it is upgraded.
For managing the builds, I simply use the <branch>_build_work bzr branches, one for 64 bit, one for 32 bit, and the makefiles therein. Important tweaks: the tarball gets built on the 64 bit branch, then copied to 32 bit, the 0install files are only on the 64 bit branch and symlinked to 32 bit, the finished files are compiled from 32 to 64 before the upload there. The reason for this complication is that it's difficult to get ssh and thus bzr operations to work in the 32 bit environment.
- compguygene
- Adjust Outside Corner Grinder
- Posts: 2346
- Joined: Thu Aug 21, 2008 12:09 pm
- Location: Cleveland, Ohio
- Contact:
Re: Weekly builds
Since autopackage is now abandoned, I am wondering if the process to build a Linux binary from a tarball will now change. For servers that I run and the one client I run on my 64-bit Ubuntu 12.04 Linux laptop, I just have been building from a source tarball with the generalized directions:
I do know that in the past this depended on autopackage, but will the commands still remain the same?
Code: Select all
./bootstrap.sh
./configure --whatever options make sense
make
make install
Armagetron: It's a video game that people should just play and enjoy
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
Re: Weekly builds
That's AutoMAKE (and autoconf), not AutoPACKAGE. We'll still be using automake. If we do drop autopackage (see epsy's cmake-branch), there still would be a configure script for compatibility with expectations.
Autopackage was the distribution system that produced installer scripts and took care that dependencies are met by downloading and installing them as well. It is an abandoned project and all our dependencies are dead by now. You could not even download the SDK any more, last time I checked.
Autopackage was the distribution system that produced installer scripts and took care that dependencies are met by downloading and installing them as well. It is an abandoned project and all our dependencies are dead by now. You could not even download the SDK any more, last time I checked.
- compguygene
- Adjust Outside Corner Grinder
- Posts: 2346
- Joined: Thu Aug 21, 2008 12:09 pm
- Location: Cleveland, Ohio
- Contact:
Re: Weekly builds
Thank you for clearing up my misunderstanding. It should have been pretty obvious to me from the names of the packages i have installed in the past, none of which was autopackage.
Armagetron: It's a video game that people should just play and enjoy
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
https://bit.ly/2KBGYjvCheck out the simple site about TheServerPharm
Re: Weekly builds
No worries.
Also, fixed builds are up for all but the 0.4 ppa and macs. Testers very welcome.
The reason for the failures was that in the 32 bit chroot, /proc was missing and binreloc disabled itself. And for PortableApps/0install, we rely on binreloc to find the data and config files. I may delegate that task to the launch script instead, that already has the full information required; binreloc also comes from autopackage and if it ever breaks, nobody is going to repair it.
Next steps: integrate alpha project and the school thingie, Mac builds for the 0.2.8 based stuff. I'll take another crack at 0.4 builds for the Mac sometime, but I really need a large chunk of time reserved for that.
Also, fixed builds are up for all but the 0.4 ppa and macs. Testers very welcome.
The reason for the failures was that in the 32 bit chroot, /proc was missing and binreloc disabled itself. And for PortableApps/0install, we rely on binreloc to find the data and config files. I may delegate that task to the launch script instead, that already has the full information required; binreloc also comes from autopackage and if it ever breaks, nobody is going to repair it.
Next steps: integrate alpha project and the school thingie, Mac builds for the 0.2.8 based stuff. I'll take another crack at 0.4 builds for the Mac sometime, but I really need a large chunk of time reserved for that.
Re: Weekly builds
Hi, I wanted to try out this new 0.4 build but I have ArchLinux and so I thought it was better to stick with 0install. The problem is, I cannot seem to find the correct feed on the wiki page. The maximum version is sty+ct (BTW, what does that mean? ), which is 0.3 and not 0.4.
I would be happy if I could try the new version! In case there are no feed, I could try to compile it from source, but it will be a pain.
I would be happy if I could try the new version! In case there are no feed, I could try to compile it from source, but it will be a pain.
Re: Weekly builds
Compiling source is probably the best bet, since you can customize the config, but I guess 0install is easier.mr_ wrote:Hi, I wanted to try out this new 0.4 build but I have ArchLinux and so I thought it was better to stick with 0install. The problem is, I cannot seem to find the correct feed on the wiki page. The maximum version is sty+ct (BTW, what does that mean? ), which is 0.3 and not 0.4.
I would be happy if I could try the new version! In case there are no feed, I could try to compile it from source, but it will be a pain.
You probably want: http://simamo.de/0install/armagetronad- ... x86_64.xml
But he gives a full list: http://simamo.de/0install/
Re: Weekly builds
Any news on weekly Mac builds?
Is there any recent Mac build of trunk/0.4 somewhere?
Is there any recent Mac build of trunk/0.4 somewhere?
Winner of the How Many Pages Before The Lock® competition and a grand total of 18,93 euros in Euromillions.
Re: Weekly builds
I think the latest mac build is from 2013madmax wrote:Any news on weekly Mac builds?
Is there any recent Mac build of trunk/0.4 somewhere?
Re: Weekly builds
I always link to http://sourceforge.net/projects/armaget ... pha_z1965/ for mac users.
Not sure if there are newer (probably, that link's been on my bookmarks for very long), you might have a look in those folders for yourself. Also I have no idea if building it from source is easy on macs. It's a pain on win32.
Not sure if there are newer (probably, that link's been on my bookmarks for very long), you might have a look in those folders for yourself. Also I have no idea if building it from source is easy on macs. It's a pain on win32.
Re: Weekly builds
Swag claims that its just like compiling on linux. Not that I can trust him with a 10 foot pole, but heyvov wrote:I always link to http://sourceforge.net/projects/armaget ... pha_z1965/ for mac users.
Not sure if there are newer (probably, that link's been on my bookmarks for very long), you might have a look in those folders for yourself. Also I have no idea if building it from source is easy on macs. It's a pain on win32.