Package Details: doomrl 0.9.9.7-11

Git Clone URL: https://aur.archlinux.org/doomrl.git (read-only, click to copy)
Package Base: doomrl
Description: A roguelike game based on the FPS Doom.
Upstream URL: http://drl.chaosforge.org/
Keywords: game roguelike
Licenses: GPL, CCPL:cc-by-nc-sa-4.0
Submitter: None
Maintainer: dark-saber
Last Packager: dark-saber
Votes: 62
Popularity: 0.000185
First Submitted: 2007-02-12 10:19 (UTC)
Last Updated: 2021-09-11 22:09 (UTC)

Latest Comments

dark-saber commented on 2017-04-10 07:32 (UTC)

sgtpep: Fixed, thanks!

sgtpep commented on 2017-04-10 04:57 (UTC) (edited on 2017-04-10 04:57 (UTC) by sgtpep)

On a clean system it complains about missing libGLU.so.1 (provided by package 'glu'): open("/usr/lib/tls/x86_64/libGLU.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libGLU.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64/libGLU.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/libGLU.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

dark-saber commented on 2017-01-06 19:56 (UTC)

ProfessorKaos64: Yes, doomrl.wad should be writable, but it is writable indeed for me. On doomrl launch, the script (https://aur.archlinux.org/cgit/aur.git/tree/doomrl.sh?h=doomrl) checks if ~/.local/share/doomrl directory doesn't exist, in which case (first launch for current user) it copies some doomrl files (configs and doomrl.wad) from /usr/share to ~/.local/share/doomrl with current user's ownership. The only cases in which you won't have write access to doomrl.wad I can think of are: you've ran doomrl as a different user via sudo or you don't have write access to ~/.local/share (very unlikely) or XDG_DATA_HOME points to somewhere your user doesn't have write access to. You should probably try to delete ~/.local/share/doomrl directory. hollunder: I confirm this issue, but other options (like boolean GameSound) do work, so the game at least reads options from config.lua. I guess this should probably be reported upstream (https://github.com/ChaosForge/doomrl).

hollunder commented on 2017-01-05 18:16 (UTC)

Adjusting music volume in the config file does not work (same for sound probably).

ProfessorKaos64 commented on 2016-12-18 02:51 (UTC)

How does this game save? I read it saves on the stairs, but it does not persist between sessions. doomrl.wad probably should be writable.

dark-saber commented on 2016-12-08 10:58 (UTC)

Updated the download links, thank you! I'll look more into building it from source, although it might be quite tricky with Lazarus. Also, with the current trend of copyright claims I won't be surprised if the binary files would eventually be removed from official site, and I'd suggest everyone to save them just in case, as this PKGBUILD will use local:// source links then.

7hePow commented on 2016-12-08 10:23 (UTC)

ChaosForge received a takedown notice from Zenimax: http://www.moddb.com/company/chaosforge/news/bethesda-parent-zenimax-hits-doomrl-the-doom-roguelike-with-takedown-notice This might explain why he published the source. Package doesn't install anymore. Site "moved" from doomrl.chaosforge.com to drl.chaosforge.com ending up with the files in: https://drl.chaosforge.org/file_download/33/doomrl-linux-i386-0997.tar.gz https://drl.chaosforge.org/file_download/32/doomrl-linux-x64-0997.tar.gz&

ProfessorKaos64 commented on 2016-12-07 14:31 (UTC)

This was just opensourced: https://github.com/ChaosForge/doomrl. Once build instructions are known, I hope this package will be updated to a native-build.

X-san commented on 2016-12-03 05:11 (UTC)

This game was crashing for me. It was apparently looking for an outdated version of libts. If anyone else is having this issue, just linking the current version worked for me: # ln -s /usr/lib/libts-1.2.so.0 /usr/lib/libts-1.0.so.0

dark-saber commented on 2016-08-26 16:43 (UTC)

@CyberShadow: Thank you, that was really a huge security flaw in an outdated PKGBUILD. By the way, aliensrl package has the same issue. The new user approach didn't work out for tiles version of the app, so I went the wrapper way. The script is kind of dirty, but I can't think of a better way to get this done, especially since AFAIK upstream is unmaintained for a long time and it always had a strange relationship with Linux conventions anyway. So, I guess, the security issue is fixed and, as a bonus, each user now has his own saves and configs.

CyberShadow commented on 2016-08-23 15:10 (UTC)

Seriously? suid as root? There is no reason why a *video game* should run as root! You could either: - suid as a new doomrl user - make the global directory writable by all (e.g. owned by "games" group, set sticky on directories) - write a wrapper to copy/link game files to a directory under the user's home directory (e.g. ~/.local/share/doomrl/) - patch or badger upstream to respect XDG directory conventions

bsdbeard commented on 2015-03-20 14:56 (UTC)

This PKGBUILD isn't right, it doesn't contain the package() function at all and mkdir -p "$pkgdir/usr/share/doomrl" will complain it can't create directories, here's a fixed PKGBUILD that works: # Contributor: KillaB <xGenoBlast@gmail.com> # Contributor: wizzomafizzo <wizzomafizzo@gmail.com> # Contributor: Nick <nick@screamingfist.org> # Maintainer: Jupotter <jupotter.g@gmail.com> pkgname=doomrl pkgver=0.9.9.7 pkgrel=1 pkgdesc="A roguelike game based on the FPS Doom." arch=('i686' 'x86_64') url="http://doom.chaosforge.org/" license=("custom") depends=("sdl_mixer" "zlib" "lua" "timidity-eawpatches" "sdl_image") conflicts=("doomrl-lq doomrl-ogg") source=("http://doom.chaosforge.org/file_download/33/doomrl-linux-i386-0997.tar.gz" "doomrl" "LICENSE") md5sums=('f1beebc47c63a768752ea66951799f45' '825cac701303cd5c61ec209e461219de' 'eaa0c779f98be421bf34cd0c5800642a') [ "$CARCH" == "x86_64" ] && source=("http://doom.chaosforge.org/file_download/32/doomrl-linux-x64-0997.tar.gz" "doomrl" "LICENSE") [ "$CARCH" == "x86_64" ] && md5sums=('7078b52000b91c468a0041ff667c4f81' '825cac701303cd5c61ec209e461219de' 'eaa0c779f98be421bf34cd0c5800642a') package() { if [ "$CARCH" == "x86_64" ] ; then cd "$srcdir/doomrl-linux-x64-${pkgver//./}" else cd "$srcdir/doomrl-linux-i386-${pkgver//./}" fi # Copy program and required files install -d "$pkgdir/usr/share/doomrl" cp -a * "$pkgdir/usr/share/doomrl" # Copy script used to run program install -D -m755 "$srcdir/doomrl" "$pkgdir/usr/bin/doomrl" # Copy the license file install -D -m644 "$srcdir/LICENSE" \ "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" # This is needed to save games and scores chmod 4755 "$pkgdir/usr/share/doomrl/doomrl" }

r0b0h0b0 commented on 2015-02-24 06:55 (UTC)

:: Checking doomrl integrity... ==> ERROR: Missing package() function in /doomrl/build/folder/ :: failed to verify doomrl integrity

ecastilla commented on 2013-12-28 05:18 (UTC)

I am getting the same problem as stecco. I've tried various attempts at debugging with gdb and setting processor affinity to one core. Game plays fine if you disable all music from the config. Activiting the EAW config did not help. Probably related to how the game plays mp3s as Awebb suggests.

stecco commented on 2013-11-15 09:59 (UTC)

doomrl-lq seems to work fine. could the problem be timidity-eawpatches? It's orphan...

Jupotter commented on 2013-11-15 09:43 (UTC)

The libpng warning comes from the latest version of libpng, it should not affect the program. Did you try using the ogg or lq version for the crash?

stecco commented on 2013-11-15 09:34 (UTC)

I downloaded and compiled successfully the package, but when I try to run from my terminal, after the second screen doomrl crashes and I have this: http://pastebin.com/3VykWjgj Any ideas?

idonthack commented on 2013-03-20 11:57 (UTC)

version 0.9.9.7 is out made a pkgbuild http://ix.io/4Ou

Awebb commented on 2013-01-26 14:19 (UTC)

The arch-specific stuff is indeed messed up, as the package is called …i386…, but the arch is …i686…. One can solve this manually in the PKGBUILD, but we should come up with something more permanent. Another sidenote: It is crucial to activate the EAW config in timidity-eawpatches, as the install note tells you to. You might and will run into segfaults otherwise (when saving stats or entering "The Wall"). I have not had a single segfault, since I did this.

qs9rx commented on 2012-11-15 10:32 (UTC)

I am on i686 and getting: ==> Starting build()... /tmp/packerbuild-1000/doomrl/doomrl/PKGBUILD: line 34: cd: /tmp/packerbuild-1000/doomrl/doomrl/src/doomrl-linux-i686-0996: No such file or directory ==> ERROR: A failure occurred in build(). Aborting... The build failed.

Jupotter commented on 2012-11-07 08:27 (UTC)

I have packaged a version with the OGG conversion script here: https://aur.archlinux.org/packages/doomrl-ogg/

Awebb commented on 2012-11-04 08:40 (UTC)

benke: This would indicate a bug in whatever method doomrl uses to play back MP3. I am now also getting segfaults on my i686 netbook. I will try the ogg trick.

benke commented on 2012-10-30 13:56 (UTC)

I followed following guide to change the music files to ogg instead of mp3. (http://forum.chaosforge.org/index.php?topic=5254.0) This solves the frequent segmentation faults on x64 for me . Here you can find a PKGBUILD integrating the above http://pastebin.com/Sb4MqDHc

Jupotter commented on 2012-10-30 10:06 (UTC)

I'm back. I added proper architecture check to the "cd" line, the $1 to the launcher. I also have uploaded the low-quality version, if you have any problem with the normal one: https://aur.archlinux.org/packages.php?ID=64144

Awebb commented on 2012-10-16 20:05 (UTC)

Could you please be so kind and add a $1 to the launcher, so we can add the switches? It's not too much trouble changing it manually, but it would be nice. /usr/share/doomrl/doomrl $1

dotfloat commented on 2012-10-11 19:57 (UTC)

The LQ version runs fine on x86_64. http://doom.chaosforge.org/downloads (Scroll down to "Low quality downloads (deprecated)")

dotfloat commented on 2012-10-04 17:22 (UTC)

The segfaults only happen in the x64 version. The i386 binaries seem playable.

tycho commented on 2012-10-03 10:53 (UTC)

I'm not really clear on why (I don't know Pascal), but doomrl segfaults after dismissing the "please donate" screen: Program received signal SIGSEGV, Segmentation fault. 0x00000000004623bb in SYSUTILS_EXCEPTION_$__CREATE$ANSISTRING$$EXCEPTION () (gdb) bt #0 0x00000000004623bb in SYSUTILS_EXCEPTION_$__CREATE$ANSISTRING$$EXCEPTION () #1 0x0000000000463f2b in SYSUTILS_RUNERRORTOEXCEPT$LONGINT$POINTER$POINTER () #2 0x0000000000010101 in ?? () #3 0x00000000004410ee in SYSTEM_DO_OPEN$formal$PCHAR$LONGINT () #4 0x0000000000000005 in ?? () #5 0x0000000000468cac in ERRORLOGOPEN (SEVERITY=..., MESSAGE=...) at ../fpcvalkyrie/src/vdebug.pas:177 #6 0x0000000000468cac in ERRORLOGOPEN (SEVERITY=..., MESSAGE=...) at ../fpcvalkyrie/src/vdebug.pas:177 #7 0x0000000000469a74 in UNHANDLEDEXCEPTIONHANDLER (OBJ=0x7f9d35551c00, ADDR=0x468cac, FRAMECOUNT=16, FRAMES=0x7f9d3555cc20) at ../fpcvalkyrie/src/vdebug.pas:279 #8 0x00000000004390b1 in SYSTEM_DOUNHANDLEDEXCEPTION () #9 0x000000000083cb38 in _$VDEBUG$_Ld35 () #10 0x0000000000439408 in fpc_reraise () #11 0x0000000000000000 in ?? () (gdb)

commented on 2012-06-12 21:05 (UTC)

I tried to install it today on my x64 system, but it failed when the build tried to cd into the directory "doomrl-linux-i386-0996" in packerbuild/doomrl/doomrl/src. I changed line 27 in the PKGBUILD to this: cd "$srcdir/doomrl-linux-x64-${pkgver//./}" (it used to be: cd "$srcdir/doomrl-linux-i386-${pkgver//./}") which made it work perfectly. So you might want to perhaps add some architecture check to that line, I guess.

Jupotter commented on 2012-05-01 16:25 (UTC)

I've updated the package and added the x64 link. I'll try to look at the problems pointed out in the comments in the following days.

mpj commented on 2012-02-29 07:29 (UTC)

We're two releases behind: http://forum.chaosforge.org/index.php/topic,5255.0.html

commented on 2011-11-29 00:16 (UTC)

Why does the executable run as root with setuid on? -rwsr-xr-x 1 root root 1745428 Nov 29 02:13 /usr/share/doomrl/doomrl

takemitsu commented on 2011-09-18 08:49 (UTC)

DoomRL doesn't start on my 32 bit machine here. It only starts with root rights. If I try to start it as a normal user, I get a segmentation fault.

keenerd commented on 2011-09-17 23:41 (UTC)

Nevermind, it looks like he pulled the pure 64 bit version. If it ever comes back, here is a pkgbuild: http://kmkeen.com/tmp/PKGBUILD-doomrl And here is a mirror of the (real) 64 bit version: http://kmkeen.com/tmp/doomrl-linux-x64-0994.tar.gz

keenerd commented on 2011-09-07 01:43 (UTC)

0.9.9.4 adds support for an experimental 64 bit release. It appears to work fine, but needs sed -i 's/liblua5.1.so.0/liblua.so.5.1\x00/g' doomrl to get around library silliness.

Count042 commented on 2011-09-06 16:37 (UTC)

0.9.9.4: New upstream release

KillaB commented on 2011-02-13 01:31 (UTC)

0.9.9.2-1: New upstream release

KillaB commented on 2010-12-21 22:32 (UTC)

The lib32-lua package was out of date. It should work now.

Awebb commented on 2010-12-21 22:23 (UTC)

lib32-lua is not on the ftp-path anymore. However, if I get it from somewhere else, it'll build but won't run. No error message.

commented on 2010-04-25 19:58 (UTC)

Variable dependencies by arch didn't work for me. Had to delete x686 row to be able to get pkgbuild to install required files in x86_64.

pinklerose commented on 2010-03-25 17:18 (UTC)

OK, I know where I made mistake. In PKGBUILD I read 'ln -s "/etc/timidity++/timidity.cfg" "$pkgdir/etc/timidity.cfg"' so I copy config to wrong location (/etc/timidity.cfg). When I replace file like you wrote, everything works now.

KillaB commented on 2010-03-25 11:05 (UTC)

Did you make sure to replace /etc/timidity++/timidity.cfg with /etc/timidity++/timidity-eawpats.cfg after installing timidity-eawpatches?

pinklerose commented on 2010-03-25 10:53 (UTC)

Game work only without sound for me. When sound is set for TRUE in doomrl.ini file terminal show error: Critical Error: <TSDLSound/0/0> Can't open SDL_Mixer!

KillaB commented on 2010-03-25 01:30 (UTC)

0.9.9.1-1: New upstream release Added dependencies for building on x86_64