0.2.8.0 final: Release process and bugs

[Z-Man]

I'd like to do the initial build on Wednesday. The only pending problem is gnorty's compile trouble, otherwise, rc4 is looking good. Usually, I build on weekends, but I'll probably be pretty busy otherwise on this one.

[Luke-Jr]

Polling for category default... 'unsorted' is just too plain unreasonable.

http://forums.armagetronad.net/viewtopic.php?t=3191

[Z-Man]

Maybe, but it's irrelevant for 0.2.8.0. It was too late when you brought it up the last time, it's too late now.

[wrtlprnft]

Errm. Once we release 0.2.8, it's too late forever.
If a new version comes out after that and it changes that behavior it will break all maps that don't have a category tag defined...

[Z-Man]

No Old maps will still reference the old DTD, and the default and whether the filed is required or not is defined there, so they won't break. Just like the beta1 maps aren't broken yet, although the top level map structure has completely changed since then.

[Luke-Jr]

Maybe, but it's irrelevant for 0.2.8.0. It was too late when you brought it up the last time, it's too late now.

It was supposed to be "" all along.

[2020]

i'm excited....

[Luke-Jr]

Trying to finish up the Gentoo ebuild... running into problems :\

First off, how am I ending up with both these paths being installed? Shouldn't it be one share-dir or the other?
/usr/games/share/doc/armagetronad
/usr/share/games/armagetronad/resource/included/AATeam/map-0.2.8.0_rc4.dtd

In Gentoo's case, at least, the /usr/share/games is correct... Apparently the doc installation is buggy?

Configure line:

Code: Select all

./configure --prefix=/usr/games --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share/games --sysconfdir=/etc/games --localstatedir=/var/games --disable-master --enable-main --disable-memmanager --disable-music --disable-krawall --enable-sysinstall --disable-useradd --enable-etc --enable-desktop --enable-initscripts --disable-restoreold --disable-games --with-glout --enable-uninstall="emerge --clean =games-action/armagetronad-0.2.8.0_rc"

[Luke-Jr]

Where is 'rcd_config' supposed to be getting installed? It's not...

[Lucifer]

In the autopackage installer for rc4, when running in text-only mode:

$ sudo ./armagetronad-0.2.8.0_rc4.x86_64-generic-linux-gnu.package -t
[02:38] <anjori> # Preparing: Armagetron Advanced
[02:38] <anjori> # Checking for required C library versions ... failed
[02:38] <anjori> # FAIL:
[02:38] <anjori> # Your copy of glibc, a core system library, is too old for this package.
[02:38] <anjori> # You need at least the following symbols in glibc: GLIBC_2.2.5.
[02:38] <anjori> #
[02:38] <anjori> # This error normally means that whoever built the package did not build it correctly.
[02:38] <anjori> # Please report the contents of this message to the provider of this package, and
[02:38] <anjori> # ask them to rebuild it using apbuild.
[02:38] <anjori> #
[02:38] <anjori> # Upgrading glibc is highly dangerous, so we recommend in this situation that you
[02:38] <anjori> # compile the app you want to install from the sources if possible. Sorry

[Z-Man]

Lucifer: I'm positive I checked the build output for warnings that indicate this error will happen for some clients, but I'll recheck. For the test build, statically linked with libxml2, from the other thread, this would be expected, but not for the other test build or the rc4 build.

Luke: Docs are not data and therefore, the --prefix argument is used for the placement directly, --datadir has no influence. We can add a --docdir switch, but later. Maybe just "--prefix /usr" and no "--disable-games" does what you want? It should

rcd_config should go where the other scripts are going, into <main program dir>/scripts.

[Lucifer]

Ok, most detailed bug report ever.

Trying to build rc4 on Mepis, which is debian based. A backtrace doesn't show any armagetron functions in it, instead it points at stuff inside libGLU. Tried switching out to mesa's version and it didn't work.

Getting a segfault, so SDL is throwing up its hands and crying.

Working it over, we narrowed it down to these lines in gArmagetron.cpp:

Code: Select all

        rSysDep::ClearGL();
        rFont::s_defaultFont.Select();
        rFont::s_defaultFontSmall.Select();
        gLogo::Display();
        rSysDep::ClearGL();

Starting about line 238 in welcome().

The backtrace is here:

Code: Select all

[04:13] <anjori> (gdb) backtrace
[04:13] <anjori> #0  0x452a5ee6 in strtof_l () from /lib/tls/libc.so.6
[04:13] <anjori> #1  0x452a31c8 in __strtod_internal () from /lib/tls/libc.so.6
[04:13] <anjori> #2  0xb7efd6ad in __gluTessErrorString () from /usr/lib/libGLU.so.1
[04:13] <anjori> #3  0x00000000 in ?? ()
[04:14] <Lucifer_arma> that doesn't tell me shit :(

near as I can tell, he's got the same exact SDL packages as I've got. libsdl1.2debian and friends. This is the same system that had the autopackage error I reported earlier (as evidenced by the irc snippets).

beta4, run from .deb runs fine. I'll see if he can try building beta4 from source in the next few days and see what comes of that. I half expect that if Klax showed up with a Sarge package, then anjori would have something to run.

I probably know more in a better organized fashion, but I'm really sleepy right now. Let me know if you need more.

[anjori]

Just installed the autopackage "armagetronad-0.2.8_alpha20060310.i686-generic-linux-gnu.package" in text-only mode from http://forums.armagetronad.net/viewtopic.php?p=44331#44331. Install completed without any problems.

Code: Select all

# Checking for required C library versions ... passed
# Checking for Standard C++ library ... passed
# Checking for Simple DirectMedia Layer (SDL) ... passed
# Checking for OpenGL Graphics Toolkit ... passed
# Checking for OpenGL Utility Library ... passed
# Checking for SDL Image Library ... passed
# Checking for libpng graphics library ... passed
# Checking for zlib compression library ... passed

On a side note: holy shit, the textures sure have changed since beta4.

[Z-Man]

Lucifer: Looks like it's the same as this one. Tree built from source, otherwise I'd say it's a library version hell problem as described here. My vmware installation was broken until sunday, I already fetched Ubuntu, FC4 and a debian netinstall CD, all waiting for installation.

anjori: Do you have two systems (one 32 and one 64 bit), did you try to install the 64 bit binary on a 32 bit machine or are you a different anjori than the one from irc?

[Z-Man]

$ sudo ./armagetronad-0.2.8.0_rc4.x86_64-generic-linux-gnu.package -t
[02:38] <anjori> # Preparing: Armagetron Advanced
[02:38] <anjori> # Checking for required C library versions ... failed
[02:38] <anjori> # FAIL:
[02:38] <anjori> # Your copy of glibc, a core system library, is too old for this package.
[02:38] <anjori> # You need at least the following symbols in glibc: GLIBC_2.2.5.
[02:38] <anjori> #
[02:38] <anjori> # This error normally means that whoever built the package did not build it correctly.

Rechecked and rebuilt, there was no error message from the build program. Indeed, the minmal version compatible with the build is glibc 2.2.5, it would be something like 2.3 without the autopackage tools. Since this is not my system, I can't install an older glibc and force linking with that. I'll do some webresearch on what I can do, but maybe just someone else will have to do the 64 bit builds.