Loading...
  OR  Zero-K Name:    Password:   

Making Linux Zero-K download easier

28 posts, 494 views
Post comment
Filter:    Player:  
Page of 2 (28 records)
sort


FIrankVermind
18 days ago
(edited 17 days ago)

Hi, the current guide to getting Zero-K on Linux is for the terminal. That's fine for me, but it might be nice to have a GUI version.

Current guide:
quote:

sudo apt-get install mono-complete libsdl2-2.0-0 libopenal1 libcurl3
mkdir Zero-K
cd Zero-K
wget https://zero-k.info/lobby/Chobby.exe
chmod u+x Chobby.exe
mono Chobby.exe


Here is one attempt at an installer that does all that:

(Link updated, fix current folder path)
https://mega.nz/#!K0t3FDRa!UEWVdtdqWKhhhAs8AK6ETjs9TlIwaINvhb2tdrrCxXQ

It's a tar.gz file with an icon and a bash script that installs the dependencies, creates a .desktop file, and downloads Chobby.

Install guide with that:
1. Download Zero-K.tar.gz
2. extract it anywhere
3. double click to go into the newly created Zero-K folder
4. double click setup-zerok.sh, choose run or run in terminal
5. Follow instructions (first one is dependency install, then wait for Chobby download)
6. double click Zero-K.desktop and mark it trusted
7. Double click again to launch Chobby and play.

8. Optional: Copy Zero-K.desktop to your desktop or to your ~/.local/share/applications folder to have it in your Ubuntu / Mint / KDE / LXDE menu.


P.S.
For a bit of an improvement to the manual one, to get the dependencies, we can also say, please click this apt link to install the packagers required by Zero-K:

apt://mono-complete,libsdl2-2.0-0,libopenal1,libcurl3

P.P.S. Source code
[Spoiler]

Source code explanation:

[Spoiler]


+4 / -0


JPrankgajop
17 days ago
Nice job but I think having a wrapper script to run a wrapper program isn't exactly the way to go. Plus it only works for Ubuntu/Debian distros.
I think a better solution would be to make the wrapper a compiled(native) program that doesn't have any dependencies.

The wrapper itself could potentially try to install any system dependencies, but in reality they shouldn't exist in the first place => any sort of package installing is too complicated to support (there are far too many distributions out there).
+2 / -0


FIrankVermind
17 days ago
Yeah. Current instructions are only really for Debian-based distros.
It would be easy for my setup script to support rpm based distros too, I can work on that.

Native programs have the bitness issue (to a lower extent now that almost everyone is 64 bit) and the libc/glibc/whatever versioning.

However, Steam will solve all of these issues, so in the interim, I think a simple open-source bash script that downloads Chobby and creates a shortcut is fine.
It is not a wrapper script, since it will not be used to run Chobby. It just checks/downloads dependencies, and downloads Chobby, and creates a shortcut (.desktop file).

If we want Zero-K / Chobby to be completely depdendency-free, we need to bundle mono, all of the libboost etc things that Chobby and Spring require, which will grow the binary a lot. But this is solved by Steam, so I guess it's not worth doing now.

+0 / -0


JPrankgajop
17 days ago
We already build and distribute static Spring + pr-downloader packages for Windows and Linux, and there are no issues with libc (afaik).
quote:
If we want Zero-K / Chobby to be completely depdendency-free, we need to bundle mono, all of the libboost etc things that Chobby and Spring require, which will grow the binary a lot.

Well we don't need mono if we make it statically linked. Now I know this isn't trivial, I've been trying to solve this for a couple of days now. Producing small, statically linked executables in a cross-platform manner is surprisingly difficult! That said, it's doable, I'm currently looking at a glfw3 + pr-downloader solution that can make very small executables and seems to statically link without issues (the C++ QT5 attempt seemed super difficult to statically link and produced 20MB+ binaries for a simple single window).

quote:
Steam will solve all of these issues

It probably won't solve anything. ZK still uses the wrapper in order to provide analytics, engine restarts and replay running. The current ZK version of Steam relies on the mono wrapper. This situation might change, but still relying on Steam to do your distribution isn't a solution for the rest of Spring, so I still plan on pursuing a C++/native launcher with no dependencies.

PS: I would advise against trying to get a super-intelligent script that can support all distros. You will likely fail in that (too many distros and many edge cases for install/system resource availability).
+2 / -0


AUrankSortale
17 days ago
(edited 17 days ago)

Great work, nice to see

I want to discuss a few thing:

theoretically, a deb file with static chobby.exe can do the same job [I tried to make one recently to some degree of success]

and someone told me in passing in a debian IRC that the script in the deb file can also download latest from server.

if we are only distributing to debian, isn't a deb file the way to go?


+0 / -0


JPrankgajop
17 days ago
No, we already talked about this in detail.
+0 / -0


FIrankVermind
17 days ago
Statically linked libs are just included into the binary, so the binary gets bigger.
Steam bundles various versions of libraries (for running Spring and other games, libSDL2 etc.) in ~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/ . This solves some dependency issues, and in a final package, mono will either need to be installed on the system, provided in the folder of Zero-K, statically linked into Chobby, or provided by Steam in this way.

As for deb, rpm, or other packages, the problem is that then you have a Chobby somewhere in a system-wide install location, and you can never update it without root access, or need to have some sort of downloader script that place stuff in the user's home folder, and wraps around Chobby, making things more complicated. Therefore, some lighter, user-mode packages should be used, if we want to go the packaging route, such as AppImage, Flatpak or Snap (not sure if snaps can install in user mode). The easiest one, no installation just double click to run, is AppImage. Here's some info: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others and some more but more annoying site: https://www.fossmint.com/flatpak-appimage-and-snap-how-do-they-stack/

As always, the trade-off is space vs ease of use. If you already have lots of libs installed on your machine, static linking / bundling duplicates those, increasing space requirements, but makes sure that the right versions of libs are used for the game.

+0 / -0


AUrankSortale
16 days ago
(edited 16 days ago)

JPrankgajop I don't mean making it to a repo, I mean just making a deb file that you can just double-click to install. which utilize the package manager which also mean UI and theoretically less code + easier to maintain.

FIrankVermind I was under the impression that you can dictate the installation path in the deb file. But I shall defer to your better judgment in such matter since you obviously know more than me.

If I somehow able to scrounge up a prototype in say the next 14 days, would you mind giving it a cursory look?
+0 / -0


FIrankVermind
16 days ago
AUrankSortale sounds great. The problem I think there could be with specifying install paths in a user writable place, is that the deb will still have to be installed as root, so those files will be owned by root. Also, I am not sure how to guess which user's folder to install to. Maybe we can use whoami and $HOME if they are not rewritten by sudo.
For non-sudo platforms, with proper root, this gets harder.
+0 / -0


AUrankSortale
16 days ago
in certain pages there mention a step to un-own an executable so that it could be executed by anyone, not just root. I will try it out.

about the directory, I was intending to have it exactly as the download instruction pages.

for all intent and purpose the deb file should do exactly what your script would do except that it's packaged in a deb file.

I'll put a 50% odd on my success
+0 / -0



CHrankAdminDeinFreund
12 days ago
This is nice, would probably work great for itch.io.

Related issue: https://github.com/ZeroK-RTS/Zero-K-Infrastructure/issues/1824
+0 / -0


AUrankSortale
11 days ago
(edited 11 days ago)

https://drive.google.com/file/d/0B8gbickq501_Qy1oRWR0TGo2elk/view?usp=sharing

as promised this is the first draft of my deb file should work on Ubuntu/Linux mint

contain only scripts so please check all the script before you run I don't take responsibility for anything broken because of my deb file [run fine on my virtual machine though]

pro:
A Deb files which can reassure certain kind of people with it familiarity
I made this as per instruction from a guy on the debian mentor channel so this is more similar to an actual Deb file, therefore, It can be used as base for an actual repo deb file should the need arise [I put a very low odd on that though]
Theoretically, should run fine with multiple users on one machine

Con:

Unsure how it will react with self updating since it is using symlink, need CZrankAdminLicho to make a test exe
need internet access [considering chobby need internet access anyway kinda low priority] [also a static version with chobby.exe pre-packaged can be made]
still far from an actual deb file
need root access
basically do exactly what your script does, albeit in a different package [hidding the fact that it is a script can be a good thing or a bad thing depending]

possible improvement:

ask user the directory they want zero-k to be installed and save it in a config file, then use it
removal script implementation

Alternative implementation ideas to be debated over the one above:

1. just package FIrankVermind script and have it run by user.
2. un-own from root the folder containing chobby.exe and have it download stuff there [very bad practice I was told]
+1 / -0


JPrankgajop
11 days ago
Does this properly specify dependencies? I don't see it anywhere.
+0 / -0


FIrankVermind
11 days ago
(edited 11 days ago)

I have checked out the deb, thanks!

Looks like the deb downloads Chobby into /usr/lib/x86_64-linux-gnu/Zero-K/Chobby.exe and includes an icon and a shortcut.

JPrankgajop, dependecies as specified in the DEBIAN/control file (you can see this by opening the deb with gdebi-gtk and click control).
Depends: mono-complete, libsdl2-2.0-0, libopenal1, libcurl3

The deb, when installing, says it's installed, but it does not seem to run properly:

/usr/bin/Zero-K/Zero-K
/usr/bin/Zero-K/Zero-K: 9: cd: can't cd to /home/lagerspe/Zero-K1

That folder does not exist. When I change the script to use Zero-K instead of Zero-K1, then it works.

Lintian is also complaining, for example about the user test/test instead of root/root. Full lintian output: https://pastebin.com/57EQBFzv

Also, if you use the icon name without full path, it allows icon themes to change the look of the icon, which is better than fixing it to the current icon. For example, people can make a monochrome icon for ZK in a theme without having to fight with the package.

Why do you have /usr/bin/Zero-K/Zero-K and not just /usr/bin/Zero-K as the script name?

Chobby is able to download things, but obviously, Chobby will not be able to update itself since the binary is owned by root after install. One approach to fix this would be to have the /usr/bin/Zero-K script copy Chobby.exe from /usr/lib... to $HOME/Zero-K. Then each user will have the version of Chobby downloaded at install time to start with, and it will update itself separately for each user.
+3 / -0


AUrankSortale
11 days ago
Zero-K1 was a test line I must have forgot to fix. Strange that it run fine on my virtual machine. probably due to contamination of multiple tests

I thought I changed permission for chobby from root to user [chmod u+wx]? i.e. chobby can update[write] itself even in root folder if it can get pass symlink [I'll double check in debian mentor irc]

well if we go so far as to have a chobby for each user, might as well package your script, have it auto detect whether it need to download chobby or not and have it download if it does not detect chobby in folder. But I got the impression that people in debian irc frown on it [well they frown on my deb file anyway]


huhm so what should we do moving forward?

packaging your script?

+0 / -0


FIrankVermind
10 days ago
(edited 10 days ago)

Looks like Chobby is root only:

~ % ls /usr/lib/x86_64-linux-gnu/Zero-K/ -la
total 4536
drwxr-xr-x 2 root root 4096 loka 10 14:48 .
drwxr-xr-x 156 root root 131072 loka 10 14:48 ..
-rwxr--r-- 1 root root 4503040 elo 9 14:43 Chobby.exe

But the script has been marked user owned:

~ % ls /usr/bin/Zero-K/ -la
total 112
drwxrwxr-x 2 lagerspe lagerspe 4096 loka 10 15:00 .
drwxr-xr-x 3 root root 102400 loka 10 15:00 ..
-rwxrwxr-x 1 lagerspe lagerspe 311 loka 10 15:00 Zero-K

Your current script is this:

#!/bin/sh
fullPath=$HOME/Zero-K
symlinkpath=$HOME/Zero-K
wgetpath=/usr/lib/x86_64-linux-gnu/Zero-K
if [ ! -d "$fullPath" ];
then mkdir "$fullPath"
#echo "v1"
fi
cd $HOME/Zero-K
if [ ! -f "$symlinkpath/Chobby.exe" ]
then
ln -s "$wgetpath/Chobby.exe" $symlinkpath
#else echo "v2"
fi
mono Chobby.exe

If we download Chobby for the user instead, it would change to this:

#!/bin/sh
fullPath=$HOME/Zero-K

if [ ! -d "$fullPath" ]
then
mkdir "$fullPath"
fi

cd "${fullPath}"
wget -N https://zero-k.info/lobby/Chobby.exe
mono Chobby.exe


The icon, and application file would stay exactly the same. There would be no need to give non-root permissions to any files. Also no need to run installation scripts at deb install time.
The deb just installs dependencies, and places this script to /usr/bin/Zero-K and the icon and desktop file to the right places.

Can you package this? Let's see how it would work.
+0 / -0


AUrankSortale
10 days ago
https://drive.google.com/file/d/0B8gbickq501_dzEtdXcwTjJZQXM/view?usp=sharing


done

I made some change to the zenity part so that it can show actual progress.

as always check script before you run

also you need to remove the old Zero-K deb above else it can't install [file conflict with different deb]
+1 / -0


FIrankVermind
10 days ago
Works great, thanks!

Some issues:

-The .desktop file has stuff about fighting hedgehogs as the GenericName. It should probably have "free real time strategy game" or something similar.
-The .desktop file has MimeType. This should be removed. As a side note, do Zero-K replays (or spring replays) have a mime type?

-The .deb "section" is "base", but it should probably be "games" or "universe/games"
-Typical deb package names are lowercase, should probably be "zero-k"
-Apparently the .desktop should not have exec permissions, probably 0644 is valid
-Exec permissions for the scripts and folders should apparently be 0755, not 0775

+3 / -0


AUrankSortale
10 days ago
https://drive.google.com/file/d/0B8gbickq501_cTAzVkVYVmozTlU/view?usp=sharing

All above issues should be taken cared of

some Lintian problem I don't think we need to fix:

E: zero-k: debian-changelog-file-missing
E: zero-k: no-copyright-file
W: zero-k: extended-description-line-too-long
W: zero-k: unknown-section game
E: zero-k: depends-on-metapackage depends: mono-complete
W: zero-k: non-standard-dir-perm usr/share/pixmaps/ 0775 != 0755
W: zero-k: binary-without-manpage usr/bin/Zero-K

+0 / -0


FIrankVermind
9 days ago
Lintian is good at complaining, but I think the section is "games" not "game".

The changelog and copyright might matter later, but for now it's all good :)
+0 / -0
Page of 2 (28 records)