Now on the AUR

[theredbaron1834]

So, I like this game. Alot I spent all last night playing it. When I gave up, it was 5am and I had to be up in a few hours. It is just such a well made little game. Plus, I run Linux, and it is just always nice to have such a great game run everywhere, from my phone to my netbook to my desktop .

I just thought I would drop in and say great job on a great game, and if anyone here uses Arch, I added it to the AUR (Arch Linux's user repository), to make it a bit easier for reinstalls for me, etc, as I don't like the steam overhead. My first PKGBUILD for something more then a script, so not sure how great it is, as well as being my first in the new AUR, but it installs and plays great for me

 

[Cervator]

Hi @theredbaron1834 and thank you! We do have a few arch users and Terasology has a package like that too. Have you set it up so it'll automatically update based on our Jenkins or GitHub somehow? That's ideal to avoid having it go out of date

 

[theredbaron1834]

Hm, I guess that package got lost in the latest update of the AUR, or is named something weird, as I didn't see it when I looked. The AUR went to a git based repo, and all packages that the maintainer didn't move are gone now, or at least really hard to find .

As for updating based on Jenkins or Github. Well, Jenkins might work, if there is a "latest" package on it. It looks like "http://jenkins.terasology.org/job/DestinationSol/lastSuccessfulBuild/artifact/desktop/build/distributions/DestinationSol.zip" is that. Is this always the latest package? If so, and stuff like file layout doesn't change often, I could easy do that. It would simply be a matter of moving where my PKGBUILD grabs from. As well as some way to find a version number easy. Don't wont to have to redownload every update.

As for from the GIT, well, I wasn't sure what "gradlew" was, have never used it, etc. If all the commands needed to compile it can be done headless, then yeah, could go that way too. I just didn't because of the aforementioned lack of knowledge. I only know .configure and make, etc.

Also, do you know what it depends on? All I could see is just Java, do you use any other linux libs?

EDIT:

Ok, so I got the jenkins one working. Should I add it, or do you want to? I could disown the destinationsol name, so you can have the "official" one as well, if you want.

 

[SimonC4]

Also, do you know what it depends on? All I could see is just Java, do you use any other linux libs?

As far as I know, it shouldn't depend on anything and it comes with a bundled Java Runtime. Be good to know if it works for you with the bundled JRE and if there are any other dependencies.

 

[theredbaron1834]

Actually, I don't use the bundled runtime for my pkgbuild, I just copy the res, libs, and add a script to user/bin that cd's to the dir and then then uses system java to launch, and then a .desktop file so it shows up in the menu. It did work for me just fine with the bundled when I just ran from the zip, however with an "install" I at least prefer to use native packages. It has a lot of bonus, not the least of which is a much smaller size. The downloaded zip is over 200mb's, where as the install tar.gz is not quite 70mb, solely due to the removed runtimes.

Plus, it makes it easier to read when doing both x86 and x64 in one installer. To use the built in ones you would have to first check what system they are running, and then different commands based on that. This adds alot of if/then stuff, etc, adding the chance of bugs, more so because I am so not a dev. I can do some scripting, but still far from a gray beard.

In fact, the way I did it should allow it to run on the Raspberry Pi 2, among other ALARM systems, if all it really needs is Java. Alas, I can't check as mine is dead. Anybody know if this will work with ARM java? If so, I could edit the pkgbuild to support it

 

[Cervator]

Favor using the http://jenkins.terasology.org/view/DestSol/job/DestinationSolRelease/ job - that's the actual release job for stable builds we trigger when ready, the job you picked does the develop build that runs on every commit and may be unstable

The current zip is a bit bloated as it contains all the embedded JREs when we really should split out some OS specific smaller packages.

Raspberry Pi etc work in theory just for the Java part, but the game still depends on natives being present for the rendering so OpenGL / LWJGL which I believe doesn't work on ARM-based stuff and such

Eventually I wouldn't mind building these kinds of distributions right out of our Jenkins attached to the end of the build job, I just have trouble finding the time to hook it up. Jenkins essentially just runs a shell on our CentOS-based build server and does the gradlew etc from there. I forget if you need the different OS distros to hit the different distribution repos, probably not?

Argh everything takes time! Need more hours in a day

 

[theredbaron1834]

So, updated to use the said job. Just a question. It needs a package version. Right now, it scraps the build number, aka 5 right now. Is this a good way, aka will every release change +1, and not stray from that format?

The Raspberry Pi/2, as far as I know, only support OpenGL ES, not normal OpenGL. However, isn't that the same with Android? I would have expected it to work with the Pi, since it works on Android.

"I forget if you need the different OS distros to hit the different distribution repos, probably not". I am not sure what you mean by this. If you mean do you need to compile stuff from said distrobution in order to get in the distribution, then no. Since this is a java app, if you released a tar.gz with /libs and /resources, as well as a script that runs java -jar libs/solDesktop.jar, that would be all that is needed to be added to repos.

 

[Cervator]

You should be able to use the latest build number as a package number, yup. You can also get that more easily via this link: http://jenkins.terasology.org/view/DestSol/job/DestinationSolRelease/lastSuccessfulBuild/buildNumber which just returns the number alone, no need to scrape anything.

And oh right, I often get stuck thinking about Terasology which in its current shape wouldn't work on Android. But DestSol runs via LibGDX which I guess respects the limitations somehow so it does work on Android. So maybe it does indeed work on a Pi - unsure if anybody has tried

As for distros I meant can we prepare an AUR update from a CentOS box? I figure we can. And for this kind of situation I figure we shouldn't need the embedded JRE, and should make a JRE-free zip available.

 

[theredbaron1834]

Yeah, that link makes it much eaiser. No more seding the crap out of things .

And, yeah, as you can see by the package build, you only need the RES, LIB, and a script to launch it. In general, Linux is Linux. I believe as long as you use the same libc, which most distros do (GNU LibC), most binary's should work, at least as long as the needed libraries are statically linked, or common enough to be installed on all distros, and the graphics are supported . However, since DestSol is a java based program, it is even more cross platform. You could even make it on Windows, and it should work anywhere. Java adds a bit of bloat vs native, but it is so easy to do crossplatform support vs native, that it makes it well worth it (imo).

For a download on the website, how you got it is actually really good. Having it that way allows it to work on "anything", all with just one download, is a great way to deal with cross-platform support. The only thing that would make it better is if there could be a script/batch file that could tell what OS it was running, and launch the right java (not possible I don't think).

However, an agnostic package (aka no JRE's,) would be good as well, as it makes it easier to add to a distro's repo by saving on download time. Also it would save the user, and the project, bandwidth.

 

[Cervator]

We had a ton of discussion and some limited implementation of a more advanced game executable, for Terasology and its launcher specifically. @shartte was leading that up but ran out of time a while ago Would probably be handy here as well. Lots of pending work on it in Jenkins as well. One day!