Commit by luke-jr on b0_2_8_0 :: armagetronad/src/tools/ (tDirectories.cpp tResourceManager.cpp):
Fix bug in /. detection code
Commit by luke-jr on b0_2_8_0 :: armagetronad/ (3 files in 2 dirs):
Check for more potentially dangerous and/or invalid filepaths
Commit by luke-jr on b0_2_8_0 :: armagetronad/src/tools/tDirectories.cpp:
=> hates me
Warning in tString tPath::GetWritePath(const char*) const in /Users/me/armagetronad/src/tools/tDirectories.cpp:604 :
Could not create path to /Users/me/Library/Application Support/Armagetron Advanced/var/scorelog.txt. Check your user's rights.
Error: Error in int SDL_main(int, char**) in /Users/me/armagetronad/src/tron/gArmagetron.cpp:534 :
var directory not writable or does not exist. It should reside inside your user data directory and should have been created automatically on first start, but something must have gone wrong. Your user data directory is subdirectory named .armagetronad in your home directory.
Thanks, antix. I assume you were installing from autopackage on an AMD64 system? And you have a version of libxml2 earlier than 2.6.12? Then the error would be "normal" (i.e. sad, but expected), please test the two packages from here: http://forums.armagetronad.net/viewtopic.php?t=3174
They should either fail to install with errors or work.
With --nodeps, that's expected behaviour as well
Which other packages did cause trouble? libstdc++5 is a likely candidate, but the package it contains has a different name on each distribution, so we can't make it a dependency in the generic RPM.
z-man wrote:With --nodeps, that's expected behaviour as well
Which other packages did cause trouble? libstdc++5 is a likely candidate, but the package it contains has a different name on each distribution, so we can't make it a dependency in the generic RPM.
oh it was just the libxml2-devel and something else I forget.
I assume that its not needed anyways for arma to run.
So a dependency for the new version of libxml2 should be fine.
Nosy Tree: I know what that forum is, and who probably have access to it, although that doesn't include myself for now. I think I got one more chance than you to get to know it, but I knew of its existence before that. Part of why it is private might be NONE.
I just tried compiling the dedicated server (rc4) for windows in Code::Blocks (gcc). The build completes sucessfully, but the server crashes with a segfault as soon as the round ends.
During compile, I get these warnings:
..\armagetronad\src\network\nNetwork.cpp warning: 'maxrec' might be used uninitialized in this function
..\armagetronad\src\network\nNetwork.cpp warning: 'buff' might be used uninitialized in this function
* The cp provided with Mac OS X does not have an -a or -x flag, so dist-hook fails.
* Again, the cp provided with Mac OS X fails with "cp: the -H, -L, and -P options may not be specified with the -r option." when installing the resources. Using -r throws the cp command into legacy mode causing it to fail, I guess. Using -R would make it succeed.
Lucifer wrote:Can we check for this in configure? You know, same way we check for LN_S and then let configure rewrite LN_S with the appropriate command and options?
Yes it could, but gnu coreutils supports using -R, correct? I'm not too worried about not being able to run make dist.