Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

net.dengine.stdlib not found [Ubuntu]

kUbuntu 19.10
doomsday "Doomsday Engine 2.3.0 [#3260] (Unstable 64-bit) Dec 6 2019 01:36:14"
loaded from repository "deb http://ppa.launchpad.net/sjke/doomsday/ubuntu eoan main"

Every time I try to start, I get a message saying "Package net.dengine.stdlib not available".
I removed/purged everything connected with doomsday, including ~/.doomsday, reinstalled, and the problem persists. There are packages "doomsday-data" and "doomsday-common", but these seem to be older versions coming from the ubuntu repositories. Doing a locate for net.dengine.stdlib shows the file indeed does not exist.
I am not getting a doomsday.out file in ~/.doomsday/runtime, only a message on the command line that says:

App init failed:
"[NotFoundError] (in PackageLoader::load) Package \"net.dengine.stdlib\" is not available"

Edit: Doing a search on the files installed by the package, I do see:

/usr/share/doomsday/net.dengine.stdlib.pack

so the file is there, it's just not being found.

Comments

  • edited 2019 Dec 6
    I'll have a look, it's possible that there's some misconfiguration in the PPA package script causing net.dengine.stdlib not to be found.
  • edited 2019 Dec 10
    I didn't find anything amiss with the PPA debs... If I install them on my Ubuntu 19.10, it seems to work fine and finds net.dengine.stdlib.pack from the correct place (/usr/share/doomsday).

    Any DOOM* environment variables set?

    You could also try launching with these options:
    -stdout -vvv
    
    That will enable full log verbosity and print output directly to stdout and not in the log file.
  • OK, ran "doomsday -stdout -vvv >doomsday.log" and zipped the file.
    I do not see any DOOM environment variables set. (env | grep DOOM and env | grep doom produce nothing)

    The bbs says it will not allow me to upload files, I have tried .zip, .log, and .txt.
    So I am not sure how to send it. Please advise.




  • edited 2019 Dec 11
    I think I have found the problem, but not the solution. I used to keep my WAD files in /usr/share/doomsday/data. If I remove the data directory, doomsday starts, but no WADs. If I create an empty /usr/share/doomsday/data directory, doomsday crashes with the net.dengine.stdlib not found error. So, where do I put the WAD files?

    Nevermind, I found the settings and added the wads.
    Works fine now. The problem was the /usr/share/doomsday/data directory, which apparently must not exist in order for the program to work.
  • edited 2019 Dec 11
    Hmm, yeah I can see how that could interfere with Doomsday's data path mappings: app.cpp line 272

    I think there was some alternative installation layout where a data subdirectory was used here, but it's not needed in the PPA builds.

    Thanks for the info, I'll add it to the bug tracker but probably as a low priority issue.

    https://tracker.dengine.net/issues/2367
  • Hate to revive a dead thread, but I just hit the same bug today when upgrading an old 1.6 package to 2.2.2--- the /usr/share/doomsday/data directory wasn't cleared out, causing the same error described by OP.

    The packaging isn't doomsday's fault, but on the other hand it's not a very graceful failure (and the error message isn't particularly helpful aside from leading users to this post). Is there any reason not to just comment out the "else" on line 276 of app.cpp? It may be a low-priority issue, but it's also low-hanging fruit.
  • edited Oct 13, 07:28
    I think the use case for the "data" subdirectory is no longer relevant on Linux, and the directory setup shouldn't check for it any longer. Instead, it should just use whatever App::nativeBasePath() returns like in the MACOSX ifdef.

    I'll apply the change for 2.3.
Sign In or Register to comment.