Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update debian stuff, make distro scripts not debian specific #1135

Open
wants to merge 1 commit into
base: master
from

Conversation

@illwieckz
Copy link
Member

illwieckz commented Nov 28, 2019

This is a deep revamp of debian scripts, but in a way the work can benefit to other distributions or packaging technologies.

I'm not doing it to support Debian, we would still answer for people having trouble with it that's unsupported. I'm doing it to be sure what we have in repos is on-par with our current game status.

Everything was lacking years behind: there was still references to the qvm or the main/ subdir. It's now gone.

If someone wants to support a distribution or build a package, the gap is far lower than before.

I've tested it successfully on Ubuntu 19.10.

Maybe the arch package can be revamped to rely on those scripts too, ping @Viech.

Basically,

  • the debian packages are able to build again (yeah!),
  • common stuff like scripts, icons and config are stored in a dist/ sub-directory (tell me if you have a better idea for the name),
  • scripts to be installed system-wide read paths from a file named /etc/unvanquished/paths.conf, so you can use the same unmodified scripts in various distro, just by shipping a different paths.conf file,
  • an up-to-date server config is shipped.

Note that unvanquished and unvanquished-server script (and new unvanquished-tty) are now wrappers to an unique unvanquished-helper script to avoid duplication and mistakes.

A systemd service is now shipped for Debian, maybe some work can be done to make it instanciable.

The server config sample was updated, it now adds bots etc. So people can have a working example to refer to.

For the moment I've set the bot names I use on my own server because I'm lacking imagination, feel free to suggests others.

@illwieckz illwieckz force-pushed the illwieckz:scripts branch 2 times, most recently from 8c9a458 to 28ddbbe Nov 28, 2019
@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 28, 2019

The Debian package seed builds and ships both nacl and native c/sgame, it's not really useful for average user since by default c/sgame is loaded from nexe from dpk, but those are shipped so it's possible to run Unvanquished the alternate ways (like debugging).

It looks like I'm not able to build Unvanquished with breakpad on Ubuntu 19.10 anymore.

I faced weird issues by building c/sgame nexes with debuild, basically the debian helpers add some LDFLAGS tweaks to environment that breaks nexe linkage.

For this reason I did a dirty hack where the usual build disables nexe build and a nexe are built in a separate directories after that, with a cleaned-up environment. So, files that are not nexes are built the way Debian expects them and nexe are not.

For reference, this is the linkage error:

pnacl-ld: Unrecognized option: -Bsymbolic-functions

I've discovered that debian helpers set this environment variable this way:

LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro'

This environment variable get translated this way by CMake in CMakeCache.txt ad make time:

CMAKE_EXE_LINKER_FLAGS:STRING=-Wl,-Bsymbolic-functions -Wl,-z,relro
CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,-Bsymbolic-functions -Wl,-z,relro
CMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-Bsymbolic-functions -Wl,-z,relro
@illwieckz illwieckz force-pushed the illwieckz:scripts branch 3 times, most recently from 5b949cc to 59aabc2 Nov 28, 2019
@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Nov 28, 2019

Why do we need this stuff? If we want to commit to the updater, it doesn't seem like a good idea to spend a lot of effort of this especially if it only works for one distro.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 28, 2019

Main reason is knowledge and polishing. This raises some corner cases issues that would make the engine design better if fixed¹.

Also such uncommon usage usually raises bugs some time before common usage raises them: we now have a good example of situation where nacl build does not work out of the box. One day we may have nacl build issue on common scenario.

In any way, most of the work was done on the launch scripts, which I rewrote purposely to be reusable on any distro.

While I'm fully committed to the updater, being able to build a flatpak or something like that would not be bad.


¹ For example it's interesting to discover that to be able to fix mutilib (something we really don't have to care about since we usually don't run shared libs gamecode) the fix is the same as to be able to build game and engine separately (something that I care about). The same fix would fix both: this fix would be multi libpath support. What's interesting in that example is that a single possible feature can fix more than one issue, and very unrelated issues. Fixes that fix other issues for free usually means they are design fixes.

@illwieckz illwieckz changed the title update debian scripts update debian stuff, make distro scripts not debian specific Nov 28, 2019
@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 28, 2019

Other part of this work is to provide an up-to-date server template, which was missing.

@illwieckz illwieckz force-pushed the illwieckz:scripts branch 3 times, most recently from c6e6f3e to be3b036 Nov 28, 2019
@slipher

This comment has been minimized.

Copy link
Contributor

slipher commented Nov 28, 2019

Thanks for the context, sounds good.

Could you point out the updated server template? It's hard to find since there are so many files... If you're talking about the .cfg files, that sounds interesting to integrate into the engine or other installation methods somehow.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 28, 2019

If you're talking about the .cfg files, that sounds interesting to integrate into the engine or other installation methods somehow.

Yes, either dump a template at first startup, either hardcode some value people can override.

The later sounds better, for example to define default bot names.

@illwieckz illwieckz force-pushed the illwieckz:scripts branch from be3b036 to a449bcc Nov 28, 2019
@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 28, 2019

note to myself:

@illwieckz illwieckz force-pushed the illwieckz:scripts branch from a449bcc to b67ed9d Nov 29, 2019
@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Nov 29, 2019

I renamed packaging/ to dist/.

@illwieckz illwieckz force-pushed the illwieckz:scripts branch 2 times, most recently from 5575b3e to 98315bf Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.