Determine what files are client side or server side

[Nicky]

Hi, in my spare time I'm trying to package AssaultCube as a snap. What I'm currently trying to do is a separate client snap and a separate server snap, given that not everyone who installs the game wants the server and vice versa.

My problem is that it's difficult to figure out what files are client side or server side, they are mixed in the same project and it's a mess. I need to know exactly what are ALL the files used in the client and what files are used in the server to make two proper and separate packages to install, avoiding to waste space.

Thanks in advance.

[stef]

a) a lot of files are used by both server and client. Packaging server and client separately would require you to double the files - and therefore to waste space.

b) please read the AssaultCube License. You are not allowed to add or remove files during repackaging. Sorry.

c) it's impossible to package a client that would not also work as a server. It's just the way it is.

If you really want to package a server, the first step would be to create a script and a setup that would allow "installed" binaries to properly run a server in the first place. Current packages (like deb) horribly fail in that department. Hint: for the most recent release version 1.2, you will probably have to use the client binary to run the server. Or wait for the next version...

[Nicky]

a) a lot of files are used by both server and client. Packaging server and client separately would require you to double the files - and therefore to waste space.

b) please read the AssaultCube License. You are not allowed to add or remove files during repackaging. Sorry.

c) it's impossible to package a client that would not also work as a server. It's just the way it is.

If you really want to package a server, the first step would be to create a script and a setup that would allow "installed" binaries to properly run a server in the first place. Current packages (like deb) horribly fail in that department. Hint: for the most recent release version 1.2, you will probably have to use the client binary to run the server. Or wait for the next version...

First of all, thank you for taking your time for response. Let me clarify some points and raise new questions:

a) I did not clarify well here, sorry. When I meant to not waste space is as server only. Suppose you have a little PC (Raspberry Pi for example) and you want to run a server on there. The current situation requires to install the hole game, that is around 50 MB. It's not really a problem, but it occupies more space than it should.

b, c) Ok, so instead to do two separate packages I will do only one package with all the files and no exclusions. But I have some new problems. Every snap app don't depend on other packages and must include inside all dependencies to run. Currently I'm including: libgl1-mesa-dri, libsdl1.2debian, libsdl-image1.2, zlib1g, libgg0, libvorbis0a, libopenal inside a usr directory in the root of the project. That could be a problem? If there are problems here I won't be able to publish the package.

Also to be able to launch the client I need a new client launcher (And probably a new server launcher but I haven't focused on it yet). Given that I cannot add more files, the only approach would be to modify the current launcher. To clarify, it just sets one variable and adds a logic to skip the dependencies check in the system when in snap enviroment (Given that the package already contains the dependencies on it). Those changes don't break anything. Would you accept that changes in a PR?

If any of the above is not allowed, I think the only way to publish AssaultCube as a snap package is directly package and publish it by the AC team and that would be great.

[stef]

Additional scripts and launchers to start the game can be considered part of the packaging and therefore aren't prohibited by the license. The goal of the license is to prevent someone to just replace the binaries or some media files and then redistribute the whole thing under a new name (like Victor does, for example).

However, since AC isn't really that picky when it comes to version numbers of support libraries - why would you want to make a composite package including the libraries? That kind of sabotages the functioning of the regular package system. What is the problem that you aim to solve by creating a snap package?

[Nicky]

Snappy is a new packaging system for the new era and future of binaries distribution, it tries to solve the problem of version freeze in every launch of distributions, it aims to be portable accross different Linux distributions without any changes to any package, allow to older releases that support snappy to update to the latest binaries, allow upstream developers to release directly instead of the traditional distribution method, sandboxing, etc. For more information please visit snapcraft.io

Snappy it's not like debs or rpm, its packages are self contained (Like .exe in Windows)

Ubuntu announced several months back that they will use snappy as the main method of distribution in the mid-long term. I think it would be nice to have AC as a snap with all the benefits of snappy, so I started to package it and later ask you, the developers if in the future this could be an official way (And also Flatpaks :D) to distribute this great game (I'll ask you in the future)

[stef]

I did read up on snap packages after your first post, but I still see no upside over classic packages - only the usual downsides of composite packages.

Btw, an exe is not a package.

[Nicky]

Well, there's no problem then. If you still like traditional distribution management that's good and I will take care of distribute AC myself as a snap for others that prefers to use snappy. But before that happens there's still the question about whether the license allows me to include the necessary dependencies inside to run the game. I hope so, this is the only remaining limitation to me.

Edit: In the process of packaging and before distributing where should I ask you better than this thread?

[stef]

I'm curious - which dependencies would you want to package with the game? For example, the client binary is linked to over 50 libraries... would you package all of them? What's the criteria?

Did you check, how often one of those dependencies received security updates since the last AC release?

As for contacting devs... if it's a topic, that's interesting for other people, use the forum - if it's offtopic in the forum, use PM - to chat in realtime, use IRC.

[Nicky]

I'm curious - which dependencies would you want to package with the game? For example, the client binary is linked to over 50 libraries... would you package all of them? What's the criteria?

Ideally only the minimum set of libraries to run the client and server. There is a core set of libraries that don't need to be provided inside every package (Low level stuff like libc, network libraries, etc). Graphic libraries do need to be provided inside the package, because they are not provided by the core, this is because snappy aims to be a general purpose packaging system, also focused on CLI apps.

Currently I'm bundling inside the debian packages that I mentioned before. I'm including them because it's needed as it says in AC download page (except libgl1-mesa-dri) http://assault.cubers.net/download.html
- libgl1-mesa-dri        --> Needed to run on systems with open source graphic drivers
- libsdl1.2debian
- libsdl-image1.2
- zlib1g
- libgg0
- libvorbis0a
- libopenal
For now including debian packages as libraries is the recommended way to package snap apps. I could compile every library from source too, but this saves time and work. For what exact libraries to include inside every package, it seems to be a proof-error process at first. I'm starting to learn how to package snaps, so I'm not the right person to say what is the right way to do this.

Did you check, how often one of those dependencies received security updates since the last AC release?

Sincerely no. I'll need a way to stay up-to-date with the latest security updates and patches to provide updates as soon as possible to end users. Anyway if any snap package is compromised, it can't compromise in any way the OS or other apps due to heavy sandboxing security.

[stef]

I'll need a way to stay up-to-date with the latest security updates and patches to provide updates as soon as possible to end users.

My guess: you will wait for the debian packages that you included to update (and those updates to be distributed, like every other user). Do you agree, that this is an additional step, that is only delaying the deployment of security fixes to users?

Anyway if any snap package is compromised, it can't compromise in any way the OS or other apps due to heavy sandboxing security.

You have fallen prey to the snappy advertising. Any compromised application endangers the user's data - which is the relevant part. A compromised debian package can affect OS and other installed stuff, but that's what package signing is for. A compromised application is a problem with or without snappy, since history shows, that there are always unfixed privilege escalation bugs around somewhere.

[Nicky]

My guess: you will wait for the debian packages that you included to update (and those updates to be distributed, like every other user). Do you agree, that this is an additional step, that is only delaying the deployment of security fixes to users?

For now and as I use debian libraries (Actually ubuntu libraries as I'm building on Xenial) yes, I will wait for patches and then launch a new update. Yeah, I agree this is an additional and possibly unnecessary step. Once I get a working build of AC, then I'll ask Launchpad/Snapcraft engineers a way to build and launch new updates automatically when one of those libraries gets a security patch.

You have fallen prey to the snappy advertising. Any compromised application endangers the user's data - which is the relevant part. A compromised debian package can affect OS and other installed stuff, but that's what package signing is for. A compromised application is a problem with or without snappy, since history shows, that there are always unfixed privilege escalation bugs around somewhere.

I totally agree user data is the most critical part to protect, snappy is just focused on integrity of OS and apps, but not its data itself, there's no magical software that can do everything well (Yet...). I don't want to say more things about snappy, just focus on package AC, but even apps that have root can't access what it's not allowed to (Except its own data, of course).

As I see it right now, the sandbox it's not a way to protect apps forever, it's just a protection mechanism to give enough time to developers to launch security updates, but yeah, it doesn't protect the package's own data if compromised and I know the sandbox it's not perfect and might have security bugs, but It's better than nothing, don't you think? Now the most important part: Is there any kind of sensible data that might get saved on AC?

Now I just want to focus on package AC, ask snappy engineers recommendations, pass your requirements, upload to the store and keep updating it. I'll send you what I'm working on if you're interested when I finish it.

PD: Can we continue to have this conversation on PM or another thread? I think this thread is not appropriate to talk about this and I want to close it.

[stef]

If you have privacy concerns, use PM. Otherwise this thread is fine.

Btw, don't get me wrong. I agree, that container packages like snappy are the simplest solution for some problems - like upgrading LibreOffice on a feature-frozen distribution like Ubuntu LTS. I just don't see any benefits for using it to package AC.

[Nicky]

Actually there doesn't have to be any reason to package AC as snap. It's just my journey to learn to package applications, contribute to open source software in some way and giving more options to users. More options doesn't hurt anyone :-) I just felt the need to give users some easy and secure way to install AC and keep the OS untouched.

Talking about the source code, there are two directories screenshots/ and demos/ that are currently empty. Are them necessary to include in the final package? I'm saying this because once AC is installed in the system, its installation directory is read only.

[Nicky]

I'm unable to find the official icon of AC. Not assault.cubers.net or wiki.cubers.net or github. I'm not sure where to find it from official sources.

[grenadier]

I'm unable to find the official icon of AC. Not assault.cubers.net or wiki.cubers.net or github. I'm not sure where to find it from official sources.

It can be this https://github.com/assaultcube/assaultcu...s/icon.png or https://github.com/assaultcube/AC/blob/n...c/icon.png , if there is needed small icon with a little better quality.

Talking about the source code, there are two directories screenshots/ and demos/ that are currently empty. Are them necessary to include in the final package? I'm saying this because once AC is installed in the system, its installation directory is read only.

No, they aren't necessary untill they are empty.

[Nicky]

Thank you! I'm hosting my build files of AC (Not the AC source code) on my repository of github under GPL3 license. You can take a look here, I'm working on "snapcraft.yaml" branch for now.

https://github.com/nikalon/assaultcube-s...craft.yaml

I'd like to include that icon in my repository. First I need to attribute the authors but I don't know how to do it properly. Can you point me how to do it well, please? Second, I'm concerned about GPL3 and CC BY-NC-SA 3.0 seems to be incompatible. Is there any way to include the icon without license problems?

Sorry if I'm asking too many questions, I'm newbie at licenses.

[Nicky]

For now I'm including the icon directly in the repo. After all I'm just packaging software.

I already have a working client and server and I think this can be the last question on this thread:

The server seems to work just fine, but the game sometimes crashes randomly. I found on other thread that setting ACDEBUG=true flag during compilation solves the issue, but now it shows more messages on the log. On the server it gets worse, it shows a lot of debug messages and it can be frustrating to admins. Is there any other workaround that doesn't show debug messages?

Thank you for your patient.

[stef]

You are building your own binaries and they crash randomly? Please don't distribute those...

Why are you building your own binaries?

Also, even without having seen your server, I highly doubt, that it is working properly :)

[Nicky]

You are building your own binaries and they crash randomly? Please don't distribute those...

Don't worry, I said I have an almost usable game/server ready to test. Not a distributable ready thing :) It's far from ready yet.

Why are you building your own binaries?

Because I want the latest stable fixes. I'm building from the latest commit of master branch. I readed that it is stable and contains fixes that doesn't break the current client-server protocol. If this isn't the right way to build the latest stable AC, please point me to the right instructions.

The game is crashing with some official maps when compiled from the latest commit of master and executed directly (I only tested in my PC though)

Also, even without having seen your server, I highly doubt, that it is working properly :)

Right, I only tested locally, no masterserver. But again, don't worry, I'm not distributing anything until everything is rigorously tested and stable.

I'll appreciate so much some help.

[Nicky]

What I'm currently doing to compile AC is enter source/src and make && make install. Then copy all relevant files to the package.

[stef]

Thing is, if we thought, it would be a good idea to distribute the current master version, we would have released it ourselves. If you just pick any version from the repository and start distributing it, you really need to know what you're doing.

You should keep in mind, that most players who run into some problems end up in our IRC channel. Once I notice, that someone is not using our release, I'll advise to reinstall from our package - simply, because I will not provide support for someone elses release - no matter if it was created from our repository. Anyone who uses your version does not know how you created it - or that it is not the original version - and therefore, when asking for help, will not tell us upfront, that he is using some custom version. This will waste a lot of our time when we help players with problems.

If you do not use our released binaries, you need to label your package as "experimental" or something similar. (Also, on a sidenote, the media license does not allow distributing full packages with modified binaries.)

Of course, anyone can checkout master (or any other branch), compile it and play with it - even online, since the protocol ist still mostly compatible. But anyone who does this, knows that it's not the vanilla release version - and will mention it while seeking help.

Feel free to read some reported problems (on the forum or on github, for example). You will notice, that, for whatever reason, most players try to tell as little as possible about their setup (and the problem itself). Every new different version that is distributed, adds to that problem.

Btw, right now, there is no newer version in the repository that i would recommend to be distributed. If you want to test new stuff, use "next" - and if you just want to play, use the released 1.2.0.2.

The "master" branch is mostly stale - and may not even build properly on newer systems, as you have noticed. Fixing that would be easy, but still be a waste of time, since there will be no more releases from "master". The next release will be based on "next".

[Nicky]

So probably my binaries are crashing due to compiling AC on newer systems, good to know that, this can be a blocker to me for generating binaries automatically. But if the current release of AC is stable and won't update anymore (until next version) then I can use the Linux tarball package directly. I'm not modifying original binaries but replacing the launcher scripts and adding dependencies inside as I mentioned before in this thread.

To indicate to users that this is not the original package of AC I can put a description indicating that it's not the official version and maybe set "assaultcube-unofficial" as the name of the package in the store or something like that.

I've been thinking about giving another direction, for example distribute AC "next" latest builds instead of the last stable version. This version should indicate to users that it's only meant to be used to test new stuff and not reporting bugs/asking for help upstream. This way users can safely try the latest coming features of AC easily without having to mess their systems compiling stuff or messing up their current configuration of AC. What do you think about this?

[stef]

If you're using our binaries, there's no need to somehow flag the result as special. Just make sure, that users know, that issues with the packaging should be reported to you while issues with the game should use the usual channels.

Packaging "next" is not really helpful to users, since it's the testing branch. Anyone using it should better clone the repository and compile for himself (we have a thread in this forum about how to do that on various platforms) - since, during development bursts, updates can come at high frequency. And most important, if someone finds and reports a bug during testing "next", the fix will also be committed to the repository - so that anyone with git and a compiler can test the fix without having to wait for a package update.

[Nicky]

Finally I decided to not use "assaultcube" as the name of the package in the store because I'm going to launch the official binaries (With my subtle additions) to the stable channel and release "AC next" automatic daily builds made by me on the edge channel.

The default channel for everyone is stable. If people want to try the game in the edge channel they must indicate it explicitly when installing AC. I'm giving the two worlds for everyone. Of course I will indicate that bugs of this package should be reported to me.

Thank you for your help and your patient :P