search

corollari / lazy-newb-pack-fedora

A ready-to-go rpm package of Enay's Lazy Newb Pack for Dward Fortress
4 stars 0 forks source link

Failed to start PyLNP on Fedora 32 XFCE Spin #1

Closed kd00r closed 4 years ago

kd00r commented 4 years ago
  1. I installed the rpm correctly.
  2. When I run the command "lazy-newb-pack" from xfce4-terminal, I get the following response: [WARNING] lazy-newb-pack: Failed to start PyLNP

I am on a 64bit machine with 64bit Fedora32 XFCE spin if that helps.

How can I get a more verbose error?

corollari commented 4 years ago

Thanks for reporting the error! Do you have gnome-terminal installed?

kd00r commented 4 years ago

Yes! It was automatically installed with the rpm. I tried running lazy-newb-pack from both the xfce and gnome-terminal, but the error stays the same in both cases.

corollari commented 4 years ago

Could you try removing the file (or renaming it) /usr/share/lazy-newb-pack/PyLNP.user and trying to run lazy-newb-pack again? That's the bit I patched from Enay's pack, so if the error persists it must mean there is something wrong with the pack itself (or my packaging).

kd00r commented 4 years ago

I renamed the file to PyLNP.user.x and tried running the command again, same error. Next I tried running: lazy-newb-pack -d -d for extra verbose errors, this time I get: DEBUG: Namespace(debug=2, df_executable=None, df_folder=None, raw_lint=False, release_prep=False, terminal_test_child=None, terminal_test_parent=None) [WARNING] lazy-newb-pack: Failed to start PyLNP

I do have the fedora packages dwarffortress dfhack dwarftherapist, which I installed earlier. Perhaps a conflict? df_executable=None suggests it does not find dwarffortress executable, but I am not sure.

corollari commented 4 years ago

Next I tried running: lazy-newb-pack -d -d for extra verbose errors, this time I get: DEBUG: Namespace(debug=2, df_executable=None, df_folder=None, raw_lint=False, release_prep=False, terminal_test_child=None, terminal_test_parent=None) [WARNING] lazy-newb-pack: Failed to start PyLNP

I just checked and I'm getting the same output, so I don't believe that's a problem. Still, while checking that I realized that this might be caused by a permissions problem, could you try running sudo chmod 777 /usr/share/lazy-newb-pack/df_linux/ and report the results?

I do have the fedora packages dwarffortress dfhack dwarftherapist, which I installed earlier. Perhaps a conflict? df_executable=None suggests it does not find dwarffortress executable, but I am not sure.

Oh that could be it, the package vendors all of these dependencies (in order to avoid forcing people to have RPMfusion repositories enabled) so I could see a conflict there. I'll install these, try to replicate the problem on my own machine and get back to you.

kd00r commented 4 years ago

I ran sudo chmod 777 /usr/share/lazy-newb-pack/df_linux/ and then lazy-newb-pack but the error persists. I then ran sudo lazy-newb-pack and it worked, I got greeted with LNP. So this could still be a permissions problem.

corollari commented 4 years ago

Then it definitely is a problem with permissions, I had to deal with a lot of them when preparing the package because all files are installed with root as the owner. The problem is probably that LNP is trying to write some file and the syscall is failing, although that should result in an error such as IOError: [Errno 13] Permission denied. In any case, I guess that an easy solution would be to make all files under /usr/share/lazy-newb-pack writable by everyone but that doesn't seem like a great idea, do you have any ideas on what file could be causing problems?

kd00r commented 4 years ago

After about 15 minutes of troubleshooting I finally found something. It turns out that the stderr.txt file needs some other permissions than it had. Run: sudo chmod 777 /usr/share/lazy-newb-pack/stderr.txt Afterwards the LNP can be started with your lazy-newb-pack command (without sudo). :)

EDIT: A wild guess would be that the stderr.txt file was created when I ran it as sudo. Maybe package an empty stderr.txt?

corollari commented 4 years ago

I see, now I was able to reproduce the issue, it effectively seems to be caused by stderr.txt. Tomorrow I'll fix the packaging scripts.

On another note, thanks for taking the time to troubleshoot this with me, I appreciate it.

kd00r commented 4 years ago

No problem, you're welcome! Thanks for the fast replies!

corollari commented 4 years ago

Commit b7b1e57 should fix the issue, I also ended up broadening more the permissions because I realized that there are some cases, such as installing new mods, where PyLNP will write to folders that previously wouldn't be writable.

Also, I've created a new release with the fix for those that want the already compiled rpm.

kd00r commented 4 years ago

That's awesome. Can I install the new rpm over the old one or should I remove the old one first?

corollari commented 4 years ago

First you need to remove the old one with sudo dnf remove lazy-newb-pack-0.1-1.fc32.x86_64. If I managed to get my package in a repository it would be possible to upgrade with a simple dnf upgrade but for now it requires a more manual set up.

kd00r commented 4 years ago

Thanks, I'll remove the old one first. I can not seem to find the new rpm release however.

Edit: There it is, thanks a lot! If I encounter something else I'll create another issue.

corollari commented 4 years ago

Yep, initially I created a release without rpm blob, which I added once I saw your message, my bad.

kd00r commented 4 years ago

I see. I everything seems to be working! You may want to add the fedora dependencies for the utilities in the readme. For instance: mono-devel gtk-sharp2 to be able to run Soundsense GTK C#. (I am quite new to github, shall I close the issue?)

corollari commented 4 years ago

Adding them now!

Edit: Added in b6bbab9. Apart from these, do you know any other dependency required by the utilities that is currently missing? Regarding the github issue, feel free to close it if you think the problem has been resolved (in general github issues are used the same way tickets are in typical trackers such as bugzilla, when the problem is solved the issue is closed)

kd00r commented 4 years ago

Alright, then let's continue for a bit more! What I do know is that DwarfTherapist is giving me a lot of QSslSocket errors like these: QSslSocket: cannot resolve sk_free I belive it has something to do with fedora shipping with a newer version of SSL. The following packages are related with this issue: openssl-devel openssl.i686 or the variants thereof in regards to bit size. I have not figured it out just yet.

EDIT: Figured it out. sudo dnf install compat-openssl10-devel.x86_64 will make DwarfTherapist working. But this package conflicts with openssl-devel.x86_64, so only one of the packages can be installed. I do not need openssl-devel.x86_64, so at least for me it's possible to fix DwarfTherapist with the above command.

corollari commented 4 years ago

It's great to hear that it's been already solved, I found it a bit weird that dwarf therapist would require ssl libraries, so I looked into it's source code. From an initial exploration the only lines that use ssl libs which I was able to find are lines like this, which open webpages such as dwarf therapist's forum thread in a browser environment, so it may be possible to patch therapist and remove this library (however that is totally outside the scope of this project, note that I could also be wrong here as I'm not familiar with therapist's source).

I've also tracked another dwarf therapist package that is on copr and it seems to have no dependencies declared, so that wasn't useful at all.

In any case, I'll add the extra dependencies to the package, thanks for the investigation!

corollari commented 4 years ago

Fixed in b08a5ef.

I've also opened a PR on this other package with your fix, making sure to attribute everything to you.

kd00r commented 4 years ago

That's great, thank you. I'll go ahead and close this issue, as the original problem was solved. I'll keep an eye on the issue in the other package.