Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003232Doomseeker[All Projects] Bugpublic2017-09-01 10:402018-10-27 22:53
ReporterWubTheCaptain 
Assigned ToBlzut3 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSDebian GNU/LinuxOS Versionbuster/sid
Product Version1.1 
Target Version1.2Fixed in Version1.2 
Summary0003232: Doomseeker installs architecture-dependent engine libraries to arch-independent directory (multi-arch support)
DescriptionDoomseeker installs and looks for engine libraries from architecture independent directory /usr/share/doomseeker/engines.

/usr/share is reserved for architecture-independent files in the Filesystem Hierarchy Standard. The engine libraries currently in /usr/share/doomseeker/engines are architecture dependent ELF binary objects and should be under /usr/lib structure instead.

Lintian tag: arch-dependent-file-in-usr-share (severity serious, certainty certain)
Steps To Reproduce

  • Compile Doomseeker from source, following instructions in the <code>COPYING</code> file. Build at least one of the supported engines (Zandronum, Chocolate Doom, Odamex, SRB2). (All engines are built by default.)

  • Install to a desired prefix (root path). Check /usr/share/doomseeker/engines in that root path.

  • Alternatively, remove or move engines directory from $HOME/.doomseeker/engines, current build directory and current relative directory. Then run Doomseeker from a terminal. Check the stdout for "Attempting to load plugins from directory" messages.

Additional Information'http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA [^]'

$ ./doomseeker
[13:08:43] Starting Doomseeker. Hello World! :)
...
[13:08:43] Attempting to load plugins from directory: /home/wub/.doomseeker/engines
[13:08:43] Attempting to load plugins from directory: /home/wub/.local/src/doomseeker/doomseeker-1.1/obj-x86_64-linux-gnu/engines

[13:08:43] Attempting to load plugins from directory: engines
[13:08:43] Attempting to load plugins from directory: /usr/share/doomseeker/engines
[13:08:43] Attempting to load plugins from directory: :/engines
...


(Reproducible on vanilla 1.1 sources, my DFSG build removes unused Windows binary objects which is what I now had. I removed ./obj-x86_64-linux-gnu/engines here.)

$ file /usr/share/doomseeker/engines/libzandronum.so
/usr/share/doomseeker/engines/libzandronum.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, BuildID[sha1]=2b7532c81d8d2ec047a540aeae9d8cb6d7261237, stripped
Attached Files

- Relationships
related to 0003301closed libwadseeker shared library dependency is not handled properly at runtime in Doomseeker after "sudo make install" 
child of 0003246acknowledged Debian packaging 

-  Notes
User avatar (0018375)
Blzut3 (administrator)
2017-09-24 22:44

'https://bitbucket.org/Doomseeker/doomseeker/commits/2499674facfe [^]'
User avatar (0018376)
WubTheCaptain (reporter)
2017-09-25 01:08

src/core/datapaths.cpp: Lines 250 and 322 seem like a good idea at first, but no longer allow installing in /usr/{share,lib}/doomseeker and let the sysadmin make local changes to /usr/local/{share,lib}/doomseeker?

src/core/datapaths.cpp: Line 320 uses QCoreApplication::applicationDirPath() directly, while pluginSearchLocationPaths() calls workingDirectory(). Is that what you wanted?

src/core/datapaths.h: Typo "an oreder list" on line 226.

src/core/main.cpp: Line 336 comment is not related to this commit, but it's also possibly misleading.

I'll have to read how multiarch works for Debian, if any changes are required there. E.g. /usr/lib/x86_64-linux-gnu/doomseeker/*.so for x86_64 or /usr/lib/i368-linux-gnu/doomseeker/*.so for i386 to support multiarch. May be something the software doesn't need to care about.
User avatar (0018377)
Blzut3 (administrator)
2017-09-25 01:43

Is making changes in /usr/local to a program installed in /usr a real thing? I know GCC for example bakes its install path somewhere so it can't be easily moved. Behavior seems kind of oddly specific since it wouldn't really apply if not installed to /usr.

I could add an option for specifying a lib directory for multiarch support.

As for the workingDirectory thing, as the comments I've added to the header file says that has been a bit of a misnomer. In the early days there was a logical "cd" happening with it, but then we added "./" as search paths anyway while never renaming the variable. Renaming it now would break ABI. It is added to the plugin search directories since that's where they're expected to be on Windows. The actual working directory is added in the next line.
User avatar (0018378)
WubTheCaptain (reporter)
2017-09-25 13:13

/usr/local is for local additions (sorry, not changes!) to a package, which should ensure to take precedence over the equivalents in /usr. Packages themselves must not install to /usr/local. This is said in Debian Policy Manual v4.1.0.0, section 9.1.2. Site-specific programs.

One may want to install Doomseeker and its bundled plugins to /usr, but add non-bundled or custom engine plugins not from the packaging system to /usr/local. I'm not sure how sensible it is to require installing Doomseeker to /usr/local to support this use case. It's a little bit difficult for me to interpret this.

Multiarch is somewhat dynamic and transparent to the program from /etc/ld.so.conf.d/* configuration, so the linker doesn't have to care where the files are placed.

At least with libvpx4 package (an example), the multiarch library placement is done at configuration time (autoconf) with configure_flags --target=generic-gnu and making a shell call to dpkg-architecture. That said, it's not a strict requirement to support this. An example from a CMake package would be mariadb-10.1, debian/rules:

cmake -DCMAKE_INSTALL_PREFIX=/usr \
$(CMAKEFLAGS) \
-DWITH_SSL=bundled \
-DCOMPILATION_COMMENT="$(DEB_VENDOR) $(RELEASE)" \
-DMYSQL_SERVER_SUFFIX="-$(DEB_VERSION_REVISION)" \
-DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
-DCMAKE_SYSTEM_PROCESSOR=$(DEB_HOST_ARCH) \
-DBUILD_CONFIG=mysql_release \
-DINSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH) \
-DINSTALL_PLUGINDIR=lib/$(DEB_HOST_MULTIARCH)/mariadb18/plugin \
-DINSTALL_MYSQLTESTDIR=share/mysql/mysql-test \
-DPLUGIN_AUTH_SOCKET=STATIC \
-DDEB=$(DEB_VENDOR) ..'


Notice especially -DCMAKE_SYSTEM_PROCESSOR, -DINSTALL_LIBDIR and -DINSTALL_PLUGINDIR options.
User avatar (0018379)
WubTheCaptain (reporter)
2017-09-25 13:25

More info on multiarch there:


  • https://wiki.debian.org/Multiarch

  • https://wiki.debian.org/Multiarch/Implementation

  • https://wiki.ubuntu.com/MultiarchSpec



Even if the lib directory is not configurable, at least Debian's packaging allows to override the install directories.
User avatar (0018380)
WubTheCaptain (reporter)
2017-09-25 13:40

There's also /opt in FHS for "add-on packages that contain static files", but it's rarely used and not available in OpenBSD at least.

CMake's module GNUInstallDirs also has CMAKE_INSTALL_LIBDIR among others, unlike the mariadb-10.1 example above.'https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html [^]'
User avatar (0018487)
Blzut3 (administrator)
2017-10-08 23:32

Addressed the multiarch issue in:'https://bitbucket.org/Doomseeker/doomseeker/commits/2a58d7c832d9635ee4dea69baaa85f47ce4298cb [^]'

As for /usr/local, I'm going to have to mark that is out of scope for this ticket as that's a fairly nuanced suggestion. Right now Doomseeker only loads plugins from one directory and there's no elegant way for us to say "oh I got plugin X from an earlier directory therefore I should skip loading the one I found later." I don't know how symbol visibility plays into this, but I suspect that more needs to be done than load everything an unload/reject if the plugin matches something we loaded earlier. In any case this seems like a new feature not a packaging issue.
User avatar (0018492)
WubTheCaptain (reporter)
2017-10-09 03:28
edited on: 2017-10-09 03:30

Zalewa, please review. I will test if later if the code is good.

User avatar (0018493)
WubTheCaptain (reporter)
2017-10-09 03:39
edited on: 2017-10-09 03:47

Actually, I should also ask: Does Doomseeker even need to know about lib or multiarch paths in src/core/datapaths.cpp, because ldconfig cache knows about those anyway? If not so, could I not activate libc's "ldconfig" trigger to ensure the ldconfig cache is updated? Seems slightly reduntant, because lintian wants me to do this anyway during Debian packaging. Obviously this was not the case with /usr/share (previous behavior), where Doomseeker had to explicitly know of .so files installed there.

Multiarch support in the build system is a welcomed addition.

User avatar (0018494)
WubTheCaptain (reporter)
2017-10-09 04:07

GNUInstallDirs may also require updating the cmake_minimum_required VERSION macro to 3.0.x.
User avatar (0018495)
Blzut3 (administrator)
2017-10-09 04:31

My build of CMake 2.8.12.2 has it. Have not verified if it produces the correct results, but 2.8.12 works fine for building.
User avatar (0018496)
WubTheCaptain (reporter)
2017-10-09 05:03
edited on: 2017-10-09 05:13

Doomseeker fails to execute on Xubuntu 16.04.3 LTS LiveCD, after sudo make install as instructed in COMPILE.txt.

Its default install prefix is /usr/local, so libwadseeker.so gets installed there too and it can't find it. Odd.

-DCMAKE_INSTALL_PREFIX=/usr works fine.

User avatar (0018497)
Blzut3 (administrator)
2017-10-09 05:11

Guess CMake isn't as smart about the RPATH as I thought it was (does a pretty decent job at figuring out what it should be at build time though). I'm not sure this is the ticket for that issue, but I guess I should look into if there's a way we can determine if the install prefix is part of the default library search path or not.
User avatar (0018499)
WubTheCaptain (reporter)
2017-10-09 05:28
edited on: 2017-10-09 05:29

True, that's a seperate issue.

I've tested the current behavior on a native arch x86_64 machine.


  • CMAKE_INSTALL_PREFIX at /usr/local (default with Xubuntu 16.04.3 LTS LiveCD) installed engines under /usr/local/lib/doomseeker/engines/ and libwadseeker to /usr/local/lib/libwadseeker.so.

  • CMAKE_INSTALL_PREFIX changed to /usr (-DCMAKE_INSTALL_PREFIX=/usr) installed engines under /usr/lib/x86_64-linux-gnu/doomseeker/engines and libwadseeker to /usr/lib/x86_64-linux-gnu/libwadseeker.so.



The distinction between /usr and /usr/local is correct. I've not tested cross-compiling yet for other architectures.

User avatar (0018501)
WubTheCaptain (reporter)
2017-10-09 05:58

Here's my proposal to resolve this ticket as fixed:


  1. Fix the "oreder" typo introduced in commit 2499674facfe.

  2. Wait for Zalewa to comment on "Do we care about this on other platforms?"
     and/or remove the comment in code (commit 2a58d7c).

  3. Test a cross-compile to another architecture. (I don't know yet how to go about doing this with CMake.)

  4. Check if Doomseeker is now needlessly reinventing ldconfig cache functionality (related to previous, because /usr/local is not in /etc/ld.so.conf.d/*), or open another issue for this.

  5. Open another issue about RPATH or us not triggering libc's ldconfig.

  6. Mark this ticket as resolved.

User avatar (0018502)
WubTheCaptain (reporter)
2017-10-09 06:43

Blzut3: Also note there's no sanity check for INSTALL_LIBDIR now in src/core/datapaths.cpp, while one was added for INSTALL_PREFIX.
User avatar (0018536)
Zalewa (developer)
2017-10-11 19:32

Quote

Wait for Zalewa to comment on "Do we care about this on other platforms?"
 and/or remove the comment in code (commit 2a58d7c).

The other platforms should not care about this, which either means that they should not receive it or it should be silently ignored. Context decides which is more appropriate. The question is: what would create more risk of causing unexpected behavior when the software is modified in the future?

Engines plugins on Windows are located in "engines/" directory located next to doomseeker.exe. We also try to load plugins from other directories, but on Windows there should be no reason to put any plugins anywhere else. Windows doesn't need to know about LIBDIR.

The comment can be changed to inform that "other platforms ignore this value, but it's provided for more convenience", or, the -DINSTALL_LIBDIR line can be 'if-UNIXed'.

Quote from "WubTheCaptain"
Doomseeker fails to execute on Xubuntu 16.04.3 LTS LiveCD, after sudo make install as instructed in COMPILE.txt.


I can reproduce this in Docker as well. Programs should run when make-installed after compiling them with defaults (even if explicit `ldconfig` is needed after make-installing), so I think this problem needs to be addressed.

It used to work before commit 2a58d7c832d9, after all. We can observe that /usr/local/lib is in ld.so.conf, but the arch directory is not:


root@33190085998f:/build# tail -n +1 /etc/ld.so.conf.d/*
==> /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf <==
/usr/lib/x86_64-linux-gnu/libfakeroot

==> /etc/ld.so.conf.d/libc.conf <==
# libc default configuration
/usr/local/lib

==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

==> /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf <==
/usr/lib/x86_64-linux-gnu/mesa-egl

==> /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf <==
/usr/lib/x86_64-linux-gnu/mesa

==> /etc/ld.so.conf.d/x86_64-linux-gnu_mirclientplatform.conf <==
/usr/lib/x86_64-linux-gnu/mir/clientplatform/mesa


What would be the correct approach here? Keep the RPATH to /usr/local/lib/<arch>?

Quote from "WubTheCaptain"

Does Doomseeker even need to know about lib or multiarch paths in src/core/datapaths.cpp, because ldconfig cache knows about those anyway?

Is it your suggestion that we should determine the correct path in the runtime instead? It should be doable, but Doomseeker will need to be self-aware about its own arch.

Quote from "Blzut3"

Right now Doomseeker only loads plugins from one directory and there's no elegant way for us to say "oh I got plugin X from an earlier directory therefore I should skip loading the one I found later." I don't know how symbol visibility plays into this, but I suspect that more needs to be done than load everything an unload/reject if the plugin matches something we loaded earlier. In any case this seems like a new feature not a packaging issue.


I can imagine someone wanting to put custom-built plugins into /usr/local/lib/, or even somewhere in $HOME. I can also imagine that probability of someone needing and/or doing this is... low.

1. Naive way: compare filenames, reject if the same filename is encountered more than once. Won't protect from `sudo cp libsrb2.so libsrb2_2.so`, but then again, screwing things up by doing this is possible already.

2. We already have an implicit requirement on plugins providing an unique string to be stored in doomseeker.ini. We can compare if this string duplicates and unload the duplicating plugin. Shared libs should leave no junk after unloading, unless we programmed them badly.
User avatar (0018539)
WubTheCaptain (reporter)
2017-10-12 05:48
edited on: 2017-10-12 05:54

Quote from Zalewa
What would be the correct approach here? Keep the RPATH to /usr/local/lib/<arch>?


Good question.

/usr/local/lib is not meant to have tuples. That's not happening here, it's working as intended. Consider Debian doesn't use {,/usr}/lib64 (only the dynamic linker does), but /usr/lib/<tuple>[/<package>] and /usr/local/lib.

Here's an example from Debian buster/sid:

$ tail -n +1 /etc/ld.so.conf.d/*                                            
==> /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf <==
/usr/lib/x86_64-linux-gnu/libfakeroot

==> /etc/ld.so.conf.d/libc.conf <==
# libc default configuration
/usr/local/lib

==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

==> /etc/ld.so.conf.d/zz_i386-biarch-compat.conf <==
# Legacy biarch compatibility support
/lib32
/usr/lib32


RPATH will be gone from all libraries and executable binaries post-install. This is the intended/desired behavior.

sudo make install with default install prefix is not a very sane approach to install software anyway. If I created a Debian package out of this (using dpkg suite), it would be installed to /usr/lib/<tuple>/doomseeker of course and that wouldn't be an issue.

CMake's macro CMAKE_INSTALL_PREFIX defaults to /usr/local on UNIX.'https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html [^]'

Now I don't remember anymore after few days why linking failed to libwadseeker in this scenario, but I've known this issue since 1.1 because of lintian.

E: doomseeker: package-must-activate-ldconfig-trigger usr/lib/x86_64-linux-gnu/libwadseeker.so


Quote from Zalewa
Is it your suggestion that we should determine the correct path in the runtime instead? It should be doable, but Doomseeker will need to be self-aware about its own arch.


No, it was a mostly irrelevant suggestion.

Quote from Zalewa
even somewhere in $HOME


Irrelevant to this issue. Doomseeker already does dynamic linking for engines? Exporting LD_LIBRARY_PATH may be required for this use scenario anyway.

Quote from Zalewa
Naive way: compare filenames, reject if the same filename is encountered more than once. Won't protect from `sudo cp libsrb2.so libsrb2_2.so`, but then again, screwing things up by doing this is possible already.


SONAME? (0003242)

User avatar (0018540)
WubTheCaptain (reporter)
2017-10-12 05:59

'https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html [^]'

Quote
Packages containing shared libraries should either install them into /usr/lib or should require binaries built against them to set RPATH to find the library at run-time.
User avatar (0018541)
WubTheCaptain (reporter)
2017-10-12 06:14
edited on: 2017-10-12 06:16

Zalewa: By the way, default instructions to sudo make install is broken in Doomseeker 1.1 too on this LiveCD.

Works after ldconfig trigger as it should.

User avatar (0018542)
WubTheCaptain (reporter)
2017-10-12 06:23

Consider everything I said about Xubuntu LiveCD being broken to be out of scope for this ticket. It's a documentation issue with ldconfig step missing from COMPILE.txt. User-error of mine for forgetting to do it in first place.
User avatar (0018545)
Zalewa (developer)
2017-10-12 17:24
edited on: 2017-10-12 17:26

Post-2a58d7c832d9 it doesn't even work after `sudo ldconfig` for me, so 1.1 is less "broken".

1. ldconfig is not recursive
2. /usr/local/lib/x86_64-linux-gnu path is not in the default configuration
3. /usr/local/lib/x86_64-linux-gnu is the default path where Wadseeker is installed now.

Quote from "WubTheCaptain"
SONAME? (0003242)

The solution should be platform-agnostic - it should be possible to retrieve the equivalent PE executable metadata through WinAPI, but I'm not sold on anything that requires to write too much platform-dependant code.

Quote from "WubTheCaptain"
Doomseeker already does dynamic linking for engines?

Doomseeker doesn't have any dependancy on engines and has no knowledge of them whatsoever until they are loaded. The engines are loaded by listing files in known directories and trying to load those files as dynamic libraries with POSIX dlopen or WinAPI LoadLibrary, depending on the OS. See PluginLoader::filesInDir(), PluginLoader::PluginLoader() and PluginLoader::Plugin::Plugin(). This means that if you copy and paste chocolatedoom library 3 times you will end up with 3 Chocolate Dooms in your Doomseeker.

User avatar (0018546)
WubTheCaptain (reporter)
2017-10-12 17:57
edited on: 2017-10-12 17:58

Quote from Zalewa
ldconfig is not recursive


This is correct.

Quote from Zalewa
/usr/local/lib/x86_64-linux-gnu path is not in the default configuration


This is also correct, it should not be in the default configuration. libc choice, and that path is bogus.

If post-2a58d7c832d9 installs to /usr/local/lib/x86_64-linux-gnu (which it doesn't on my machine/Xubuntu LiveCD), that's a bug. I can see there could be a way for this to happen at the moment.

Quote from Zalewa
/usr/local/lib/x86_64-linux-gnu is the default path where Wadseeker is installed now.


That shouldn't happen, and it didn't happen for me with Xubuntu LiveCD. We have a bug.

I tested this again with a Xubuntu LiveCD using Mercurial commit 1d768e9 for Doomseeker (2a58d7c832d9 + 11 newer commits).

-- Installing: /usr/local/lib/libwadseeker.so


User avatar (0018640)
Blzut3 (administrator)
2017-10-29 01:07

CPack generated debs should now trigger ldconfig and when installing outside of /usr there should be an RPATH set to keep the wadseeker link valid. Did I forget anything?
User avatar (0018652)
WubTheCaptain (reporter)
2017-10-29 18:10
edited on: 2017-10-29 18:12

'https://bitbucket.org/Doomseeker/doomseeker/commits/2ee1fdeb200abe873671ee368226fb9e284f20fe [^]'
'https://bitbucket.org/Doomseeker/doomseeker/commits/33e6ab19ce75772b2b75156ba0a725014aa62f8a [^]'

I intent to review and test this later. I have a bad feeling about "something", but I'll test it first.

Quote from UpstreamGuide
Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on Debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).


'https://wiki.debian.org/UpstreamGuide [^]' (but in this case, it's not exactly root except for wadseeker tarballs.)

User avatar (0018654)
Blzut3 (administrator)
2017-10-29 18:38

I could capitalize the directory name or something. Ultimately the only thing that matters to me is the file name is triggers since CPack only gives me the ability to dump files into the control archive with the name they have on disk.
User avatar (0019743)
WubTheCaptain (reporter)
2018-09-25 02:31

I don't know, is this resolved?

Still loading from ~/.local/share on Debian GNU/Linux (buster/sid), which is arch-independent. There is ~/.local/lib available, though.

Pre-install:

$ ./doomseeker
[02:20:25] Starting Doomseeker. Hello World! :)
[02:20:25] Setting up data directories.
[02:20:25] Cache directory: /home/wub/.cache/doomseeker
[02:20:25] Config directory: /home/wub/.config/doomseeker
[02:20:25] Data directory: /home/wub/.local/share/doomseeker
[02:20:25] Attempting to load plugins from directory: /home/wub/.local/share/doomseeker/engines
[02:20:25] Attempting to load plugins from directory: /tmp/doomseeker-debian/doomseeker-1.2/obj-x86_64-linux-gnu/engines

[02:20:25] Loaded plugin: "Chocolate Doom"!
[02:20:25] Loaded plugin: "Odamex"!
[02:20:25] Loaded plugin: "Sonic Robo Blast 2"!
[02:20:25] Loaded plugin: "Turok 2 Remaster"!
[02:20:25] Loaded plugin: "Zandronum"!
[02:20:25] Listening to Zandronum's LAN servers broadcasts on port 15101.
[02:20:25] Initializing configuration file.
[02:20:25] Setting INI file: /home/wub/.config/doomseeker/doomseeker.ini
[02:20:25] Loading translations definitions
[02:20:25] Reading localizations definitions file: translations.def
[02:20:25] Initializing IP2C database.
[02:20:25] Initializing passwords configuration file.
[02:20:25] Initializing configuration for plugins.
[02:20:25] Initializing IRC configuration file.
[02:20:25] Setting IRC INI file: /home/wub/.config/doomseeker/doomseeker-irc.ini
[02:20:25] Starting refreshing thread.
[02:20:25] Preparing GUI.
[02:20:27] Please wait. IP2C database is being read. This may take some time.
[02:20:27] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[02:20:27] IP2C database read in 85 ms. Entries read: 158337
[02:20:27] Init finished.
================================
[02:20:27] IP2C parsing thread has finished.
[02:20:27] IP2C parsing finished.
[02:20:27] Total refresh initialized!
[02:20:30] Finished refreshing. Servers on the list: 557 (+1 custom, +0 LAN). Players: 47.


Lintian doesn't have an issue with ldconf:

$ lintian | grep ldconf
$


After install:

$ doomseeker
[02:30:47] Starting Doomseeker. Hello World! :)
[02:30:47] Setting up data directories.
[02:30:47] Cache directory: /home/wub/.cache/doomseeker
[02:30:47] Config directory: /home/wub/.config/doomseeker
[02:30:47] Data directory: /home/wub/.local/share/doomseeker
[02:30:47] Attempting to load plugins from directory: /home/wub/.local/share/doomseeker/engines
[02:30:47] Attempting to load plugins from directory: /usr/bin/engines
[02:30:47] Attempting to load plugins from directory: engines
[02:30:47] Attempting to load plugins from directory: /usr/lib/x86_64-linux-gnu/doomseeker/engines
[02:30:47] Loaded plugin: "Chocolate Doom"!
[02:30:47] Loaded plugin: "Odamex"!
[02:30:47] Loaded plugin: "Sonic Robo Blast 2"!
[02:30:47] Loaded plugin: "Turok 2 Remaster"!
[02:30:47] Loaded plugin: "Zandronum"!
[02:30:47] Listening to Zandronum's LAN servers broadcasts on port 15101.
[02:30:47] Initializing configuration file.
[02:30:47] Setting INI file: /home/wub/.config/doomseeker/doomseeker.ini
[02:30:47] Loading translations definitions
[02:30:47] Reading localizations definitions file: translations.def
[02:30:47] Initializing IP2C database.
[02:30:47] Initializing passwords configuration file.
[02:30:47] Initializing configuration for plugins.
[02:30:47] Initializing IRC configuration file.
[02:30:47] Setting IRC INI file: /home/wub/.config/doomseeker/doomseeker-irc.ini
[02:30:47] Starting refreshing thread.
[02:30:47] Preparing GUI.
[02:30:47] Please wait. IP2C database is being read. This may take some time.
[02:30:47] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[02:30:47] IP2C database read in 81 ms. Entries read: 158337
[02:30:47] Init finished.
================================
[02:30:47] IP2C parsing thread has finished.
[02:30:47] IP2C parsing finished.
[02:30:47] Total refresh initialized!
[02:30:50] Finished refreshing. Servers on the list: 557 (+1 custom, +0 LAN). Players: 52.


Uhh, /usr/bin/engines?
User avatar (0019744)
WubTheCaptain (reporter)
2018-09-25 02:34

Quote from WubTheCaptain
I don't know, is this resolved?


1.2~beta-180925-0123 (e3f5bac45caa) if I may add (Mercurial source at default branch tip).

And no, I don't think this is resolved yet.
User avatar (0019999)
Blzut3 (administrator)
2018-10-08 05:31

The /usr/bin/engines thing was expected since that's just part of the normal search order (look in binary directory first and then check the install prefix). That said I suppose I could add logic to detect when we're installed and force the use of the installed plugins.

I think the ~/.local/share is just a hold over from when we didn't have a distinct concept of plugin search paths. Arguably we should support ~/.local/lib but like with /usr/local before, that's out of scope and would require support for multiple plugin directories to be useful.

'https://bitbucket.org/Doomseeker/doomseeker/commits/5532461c42b7cf453f269e44c90eb19bacf6f57f [^]'
User avatar (0020005)
WubTheCaptain (reporter)
2018-10-08 09:59

Only "Attempting to load plugins from directory: /usr/lib/x86_64-linux-gnu/doomseeker/engines" remains after install, this is good. Thank you.
User avatar (0020006)
WubTheCaptain (reporter)
2018-10-08 10:01

And "Attempting to load plugins from directory: /tmp/doomseeker-debian/doomseeker-1.2/obj-x86_64-linux-gnu/engines" pre-install, good.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2017-09-01 10:40 WubTheCaptain New Issue
2017-09-01 16:29 Zalewa Relationship added child of 0003246
2017-09-06 02:30 Blzut3 Assigned To => Blzut3
2017-09-06 02:30 Blzut3 Status new => assigned
2017-09-06 02:31 Blzut3 Target Version => 1.2
2017-09-24 22:44 Blzut3 Note Added: 0018375
2017-09-24 22:44 Blzut3 Status assigned => needs testing
2017-09-25 01:08 WubTheCaptain Note Added: 0018376
2017-09-25 01:43 Blzut3 Note Added: 0018377
2017-09-25 01:43 Blzut3 Status needs testing => assigned
2017-09-25 13:13 WubTheCaptain Note Added: 0018378
2017-09-25 13:25 WubTheCaptain Note Added: 0018379
2017-09-25 13:40 WubTheCaptain Note Added: 0018380
2017-10-08 23:32 Blzut3 Note Added: 0018487
2017-10-08 23:32 Blzut3 Status assigned => needs review
2017-10-09 03:28 WubTheCaptain Assigned To Blzut3 => Zalewa
2017-10-09 03:28 WubTheCaptain Status needs review => assigned
2017-10-09 03:28 WubTheCaptain Note Added: 0018492
2017-10-09 03:28 WubTheCaptain Status assigned => needs review
2017-10-09 03:30 WubTheCaptain Note Edited: 0018492 View Revisions
2017-10-09 03:39 WubTheCaptain Note Added: 0018493
2017-10-09 03:43 WubTheCaptain Note Edited: 0018493 View Revisions
2017-10-09 03:47 WubTheCaptain Note Edited: 0018493 View Revisions
2017-10-09 03:50 WubTheCaptain Additional Information Updated View Revisions
2017-10-09 04:07 WubTheCaptain Note Added: 0018494
2017-10-09 04:21 WubTheCaptain Summary Doomseeker installs architecture-dependent engine libraries to arch-independent directory => Doomseeker installs architecture-dependent engine libraries to arch-independent directory (multi-arch support)
2017-10-09 04:26 WubTheCaptain Assigned To Zalewa => Blzut3
2017-10-09 04:26 WubTheCaptain Status needs review => assigned
2017-10-09 04:31 Blzut3 Note Added: 0018495
2017-10-09 05:03 WubTheCaptain Note Added: 0018496
2017-10-09 05:10 WubTheCaptain Note Edited: 0018496 View Revisions
2017-10-09 05:11 Blzut3 Note Added: 0018497
2017-10-09 05:13 WubTheCaptain Note Edited: 0018496 View Revisions
2017-10-09 05:28 WubTheCaptain Note Added: 0018499
2017-10-09 05:29 WubTheCaptain Note Edited: 0018499 View Revisions
2017-10-09 05:58 WubTheCaptain Note Added: 0018501
2017-10-09 05:58 WubTheCaptain Status assigned => needs review
2017-10-09 06:43 WubTheCaptain Note Added: 0018502
2017-10-11 19:32 Zalewa Note Added: 0018536
2017-10-12 05:48 WubTheCaptain Note Added: 0018539
2017-10-12 05:53 WubTheCaptain Note Edited: 0018539 View Revisions
2017-10-12 05:54 WubTheCaptain Note Edited: 0018539 View Revisions
2017-10-12 05:59 WubTheCaptain Note Added: 0018540
2017-10-12 06:14 WubTheCaptain Note Added: 0018541
2017-10-12 06:15 WubTheCaptain Note Edited: 0018541 View Revisions
2017-10-12 06:16 WubTheCaptain Note Edited: 0018541 View Revisions
2017-10-12 06:23 WubTheCaptain Note Added: 0018542
2017-10-12 06:45 WubTheCaptain Relationship added related to 0003301
2017-10-12 17:24 Zalewa Note Added: 0018545
2017-10-12 17:26 Zalewa Note Edited: 0018545 View Revisions
2017-10-12 17:57 WubTheCaptain Note Added: 0018546
2017-10-12 17:57 WubTheCaptain Status needs review => assigned
2017-10-12 17:58 WubTheCaptain Note Edited: 0018546 View Revisions
2017-10-29 01:07 Blzut3 Note Added: 0018640
2017-10-29 01:07 Blzut3 Status assigned => needs review
2017-10-29 18:10 WubTheCaptain Note Added: 0018652
2017-10-29 18:12 WubTheCaptain Note Edited: 0018652 View Revisions
2017-10-29 18:38 Blzut3 Note Added: 0018654
2018-09-25 02:31 WubTheCaptain Note Added: 0019743
2018-09-25 02:34 WubTheCaptain Note Added: 0019744
2018-09-25 03:34 Blzut3 Status needs review => assigned
2018-10-08 05:31 Blzut3 Note Added: 0019999
2018-10-08 05:31 Blzut3 Status assigned => needs testing
2018-10-08 09:59 WubTheCaptain Note Added: 0020005
2018-10-08 09:59 WubTheCaptain Status needs testing => resolved
2018-10-08 09:59 WubTheCaptain Resolution open => fixed
2018-10-08 10:01 WubTheCaptain Note Added: 0020006
2018-10-13 19:05 WubTheCaptain Fixed in Version => 1.2
2018-10-27 22:53 WubTheCaptain Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker