Anonymous | Login | Signup for a new account | 2024-04-23 21:17 UTC |
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0003232 | Doomseeker | [All Projects] Bug | public | 2017-09-01 10:40 | 2018-10-27 22:53 | ||||
Reporter | WubTheCaptain | ||||||||
Assigned To | Blzut3 | ||||||||
Priority | low | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | x86_64 | OS | Debian GNU/Linux | OS Version | buster/sid | ||||
Product Version | 1.1 | ||||||||
Target Version | 1.2 | Fixed in Version | 1.2 | ||||||
Summary | 0003232: Doomseeker installs architecture-dependent engine libraries to arch-independent directory (multi-arch support) | ||||||||
Description | Doomseeker 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 |
| ||||||||
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 | |||||||||||
|
Notes | |
(0018375) Blzut3 (administrator) 2017-09-24 22:44 |
'https://bitbucket.org/Doomseeker/doomseeker/commits/2499674facfe [^]' |
(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. |
(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. |
(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. |
(0018379) WubTheCaptain (reporter) 2017-09-25 13:25 |
More info on multiarch there:
Even if the lib directory is not configurable, at least Debian's packaging allows to override the install directories. |
(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 [^]' |
(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. |
(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. |
(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. |
(0018494) WubTheCaptain (reporter) 2017-10-09 04:07 |
GNUInstallDirs may also require updating the cmake_minimum_required VERSION macro to 3.0.x. |
(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. |
(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. |
(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. |
(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.
The distinction between /usr and /usr/local is correct. I've not tested cross-compiling yet for other architectures. |
(0018501) WubTheCaptain (reporter) 2017-10-09 05:58 |
Here's my proposal to resolve this ticket as fixed:
|
(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. |
(0018536) Zalewa (developer) 2017-10-11 19:32 |
Quote 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" 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:
What would be the correct approach here? Keep the RPATH to /usr/local/lib/<arch>? Quote from "WubTheCaptain" 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" 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. |
(0018539) WubTheCaptain (reporter) 2017-10-12 05:48 edited on: 2017-10-12 05:54 |
Quote from Zalewa 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 No, it was a mostly irrelevant suggestion. Quote from Zalewa 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 SONAME? (0003242) |
(0018540) WubTheCaptain (reporter) 2017-10-12 05:59 |
'https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html [^]'Quote |
(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. |
(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. |
(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" 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 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. |
(0018546) WubTheCaptain (reporter) 2017-10-12 17:57 edited on: 2017-10-12 17:58 |
Quote from Zalewa This is correct. Quote from Zalewa 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 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 |
(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? |
(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 'https://wiki.debian.org/UpstreamGuide [^]' (but in this case, it's not exactly root except for wadseeker tarballs.) |
(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. |
(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? |
(0019744) WubTheCaptain (reporter) 2018-09-25 02:34 |
Quote from WubTheCaptain 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. |
(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 [^]' |
(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. |
(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. |
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 |
Copyright © 2000 - 2024 MantisBT Team |