Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003232Doomseeker[All Projects] Bugpublic2017-09-01 10:402017-10-12 17:58
ReporterWubTheCaptain 
Assigned ToBlzut3 
PrioritylowSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
Platformx86_64OSDebian GNU/LinuxOS Versionbuster/sid
Product Version1.1 
Target Version1.2Fixed in Version 
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 Informationhttp://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 0003301confirmed libwadseeker shared library dependency is not handled properly at runtime in Doomseeker after "sudo make install" 
child of 0003246assignedWubTheCaptain Debian packaging. 

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

https://bitbucket.org/Doomseeker/doomseeker/commits/2499674facfe [^]
User avatar (0018376)
WubTheCaptain (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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 (developer)
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



Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
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






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker