HOWTO compile bzflag from github source on XUbuntu 22.04

[Rotten Pineapple]

There isn't a question here... just passing along some hard won tips from an evening of upgrading...

XUbuntu 22.04 beta (early April 2022) had some issues for me:
[*] Allejo's snap client (2.4.22) install but would fail to load runtime with mismatched library versions
[*] apt install bzflag installs and would run, but freeze up before play

The XUbuntu I installed is a beta and so I hope all that gets fixed on the XUbuntu side.
But, this also suggests that upgrades might not go smoothly....

Meanwhile to get bzflag working, I compiled from source.

Possibly "Important":
[*] Don't forget to save your `config.cfg` bzflag configuration file from your old system if you have bzflag settings that you like.
[*] In ubuntu, you'll want to install the proprietary nvidia drivers if you have a nvidia GPU. The default driver is the open source nouveau driver, and may be too slow for gaming.

Here's what I needed to do to compile on xubuntu 22.04.

Code: Select all

apt install -y git build-essential libtool zlib1g-dev \
    libc-ares-dev libcurl4-gnutls-dev mesa-utils libglu1-mesa-dev \
    freeglut3-dev mesa-common-dev libglew-dev libglfw3-dev libglm-dev \
    libao-dev libmpg123-dev libghc-sdl2-dev
    
git clone https://github.com/BZFlag-Dev/bzflag
cd ./bzflag
# now we can follow the instructions in README.md
./autogen.sh
./configure
make -j4
# sudo su here if necessary; make install wants to write to /usr/local
make install

To build the apt install list, I muddled through various "./configure" errors with google.
Not exactly the ideal method but it worked...

A medium article by Gursimar Singh about how to run X11 apps from docker led me to write this `Dockerfile`.

Code: Select all

FROM ubuntu:22.04
RUN apt update && apt install -y git build-essential libtool zlib1g-dev \
    libc-ares-dev libcurl4-gnutls-dev mesa-utils libglu1-mesa-dev \
    freeglut3-dev mesa-common-dev libglew-dev libglfw3-dev libglm-dev \
    libao-dev libmpg123-dev libghc-sdl2-dev
RUN groupadd --gid 8888 bzflag && \
    useradd --home-dir /bzflag --create-home --uid 8888 \
            --gid 8888 --shell /bin/bash --skel /dev/null bzflag
USER bzflag
WORKDIR /bzflag
RUN mkdir /bzflag/src
WORKDIR /bzflag/src
RUN git clone https://github.com/BZFlag-Dev/bzflag
WORKDIR /bzflag/src/bzflag
RUN ./autogen.sh && \
    ./configure && \
    make -j4
USER root
RUN make install
USER bzflag

This also compiled and worked, but wasn't ideal. There was no sound at all, even when forwarding /dev/snd into the container.
Also docker adds another layer that adds lag. Besides, snap is "marketed" as containerization for linux games and is probably
better integrated with X and sound and lighter on lag...



Rotten Pineapple

[tainn]

I'm not sure how you managed to bring Docker into the story. Perhaps you're misunderstanding different containers? Docker is generally used for services, while Snap is for apps. There is no Docker in the story of running the BZFlag client. It could be in the domain of BZFS, should one decide to run their servers in Docker containers.

As a side note, have you perhaps also tried the latest Flatpak?

[Rotten Pineapple]

Tainn:

A sentence like "I was curious about getting some isolation, without trying to fix the snap." probably would have been helpful.

And the reason I want more isolation... is that I value my computer's privacy and prefer containerization to other options like reading and really understanding the entire bzflag source code. Similarly, I might prefer writing a familiar Dockerfile to learning how to write a snap.

> I'm not sure how you managed to bring Docker into the story.

The post isn't a story. Its not there to entertain or even provide smooth transition. I had time to write a brain dump.
Perhaps that violates some reader expectations but so be it.

> There is no Docker in the story of running the BZFlag client.

You are correct in that Docker is not required to run bzflag and only the first part is needed
to compile the source to binaries.

> Docker is generally used for services, while Snap is for apps.

That might be the general trend.

However many common CLI apps (bash; gcc; cmake; python; rsync) are all on Docker Hub for various reasons: standardization; ease of use on Windows; necessity as a building block in a secure system; testing. The Google Cloud Build service, for instance, allows developers to specify a series of docker containers and parameters but does not directly accept shell scripts or Makefiles.

That doesn't mean programmers should normally prefer to run gcc from a docker container, or that bash run from a container is somehow always inherently more useful.

Rotten Pineapple

[tainn]

Images on Docker Hub are there to either be used as end products, or base images for your own images. The "python" image you mention here is not just python—it's python packaged in a minimal OS, resulting in an opinionated, small image that offers python out of the box.

Yes, containers are often temporarily born during testing for the duration of a test, since services and entire CI/CD processes run on containerized environments. But running persistent client-based apps in containers that feature (minimal) OS alongside whatever functionality you're after seems like unnecessary overhead. Different types of containers exist for a reason. Flatpak is an example, which you didn't reply to.

[blast]

I don't know if Ubuntu really cares about Flatpak since they are pushing Snaps. We (the dev team) should look into why the snap is failing since that's something we maintain.