Closed WPFilmmaker closed 4 years ago
Thanks. You can find an install package and a portable version for windows here. There is also a (mostly) portable version for Debian.
As for having this added to some repos, I've never really thought about that, so I have genuinely no idea what kind of requirements/work are involved in that process. @polarina, what do you think about that? Is that something worth doing? Is it a lot of initial and or maintenance work?
@FluffyStuff Thanks for your reply! Does OpenRiichi work under wine? I will try that! (edit: Latest Wine dev runs OpenRiichi like a charm so far, as long as the next verson of wine or OpenRiichi does not breaks something , still an answer to my question to run ubuntu would be still appreciated ;) )
In the meanwhile I followed the steps but I got stuck:
myusername@myusername-pc:~$ git clone https://github.com/FluffyStuff/OpenRiichi.git Cloning into 'OpenRiichi'... remote: Counting objects: 675, done. remote: Compressing objects: 100% (7/7), done. remote: Total 675 (delta 0), reused 1 (delta 0), pack-reused 668 Receiving objects: 100% (675/675), 42.04 MiB | 3.55 MiB/s, done. Resolving deltas: 100% (313/313), done. Checking connectivity... done. stuff@stuff-VirtualBox:~$ git clone https://github.com/FluffyStuff/Engine.git Cloning into 'Engine'... remote: Counting objects: 493, done. remote: Total 493 (delta 0), reused 0 (delta 0), pack-reused 493 Receiving objects: 100% (493/493), 835.18 KiB | 1.37 MiB/s, done. Resolving deltas: 100% (311/311), done. Checking connectivity... done.
myusername@myusername-pc:~$ cd OpenRiichi && make release valac -o bin/OpenRiichi ../Engine/*.vala ../Engine/Audio/*.vala ../Engine/Files/*.vala ../Engine/Helper/*.vala ../Engine/Properties/*.vala ../Engine/Rendering/*.vala ../Engine/Rendering/OpenGLRenderer/*.vala ../Engine/Window/*.vala ../Engine/Window/Controls/*.vala source/*.vala source/Game/*.vala source/Game/Logic/*.vala source/Game/Rendering/*.vala source/Game/Rendering/Menu/*.vala source/GameServer/Bots/*.vala source/GameServer/GameState/*.vala source/GameServer/Server/*.vala source/MainMenu/*.vala source/MainMenu/Lobby/*.vala --thread --target-glib 2.32 --pkg gio-2.0 --pkg glew --pkg gee-0.8 --pkg gl --pkg SDL2_image --pkg sdl2 --pkg stb --pkg pangoft2 --pkg sfml-audio --pkg sfml-system --pkg zlib --pkg win32 -X -lcsfml-audio -X -lcsfml-system -X -Iinclude -X -lm --vapidir=vapi -X -w -X -DGLEW_NO_GLU -D LINUX
stuff@stuff-VirtualBox:~/OpenRiichi$
What should I do now to run OpenRiichi?
About the repo additon please refer to comment 3 of this ticket for a project I give feedback to: https://github.com/bleachbit/bleachbit/issues/305
Each distro has different way but *buntu distros and debian should use the same way and other based on ubuntu (like Mint) have additional packages added by their maintainers. Therefore supporting debian/ubuntu gives a lot of exposure, if other feel to add the software they can become maintainers for their distros.
In case you want to read more (could be out of date though) https://askubuntu.com/questions/75352/how-to-request-a-package-upgrade-in-the-next-ubuntu-release https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages https://www.kubuntuforums.net/showthread.php/54134-FAQ-Requesting-new-packages-new-versions-new-features
Thanks again for the work you put in :)
@FluffyStuff Packaging for the various distributions is something we can consider. It's a fair bit of initial work though, especially if the goal is to make the package available officially in the distributions' repositories (as opposed to just publishing prebuilt .deb/.rpm files).
There's a lot more involved in publishing a package to the official repositories than just making the .deb/.rpm package. You would need to figure out and follow each distributions' rules and best-practices, integrate with their automatic build systems, convincing the developers that the package won't get abandoned the moment they approve it, etc.
Once all that is done though, maintenance should be minimal. I do expect that distributions will from time-to-time rename/move/split-up packages we'd depend on, thus one would need to be willing and ready to spend an hour or two to fix the build scripts each time that happens without much notice.
This sounds like a lot of work, and I don't think the project is at that stage quite yet (I consider it still very much alpha.) There are a few things in this project that I still need to sink a lot of time into before it would be appropriate to invest time in this. But I will keep this in mind after the next milestone.
I discovered this yesterday and submitted it as a package to the AUR https://aur.archlinux.org/packages/open-riichi-git. Build instructions are clear enough and for installation I resorted to just dumping everything into /opt
.
Also, what's the current state of the three branches master
, development
and next
?
I cleaned up the branches and compilation, so creating packages should be relatively straightforward again (although I plan to delete the makefile and move to cmake instead).
I've decided though that I won't be doing any package maintenance myself. But let me know if there are any issues with creating a package on any distro.
@FluffyStuff I would suggest trying pinging the guys at flathub. From what I understood they do the maintaince of their flatpaks (provided there is one maintainer).
This would have 3 beenfit:
1 provide an easy way to install (flatpak) 2 release you from burden of packaging 3 popularize the game as flathub is a popular platform
I intend to continue maintaining the AUR package. Please just include a mention of any changes specifically interesting for packagers in your release notes.
FYI, the AUR package has been updated and now builds from master
using meson. I'm not too happy with having no executable in /usr/bin
, but the readme says it requires data to be in a Data
subdirectory, so the desktop file will have to do.
@FichteFoll, I added a CHANGELOG.md
file and roughly wrote the most important info there.
Regarding the Data
folder, where would you want it to be stored, and how would you like the application to find it?
It would be easy to do it through a build-time or run-time flag. Finding the path through some sort of settings file would also be possible, but I think just using a flag would be the most convenient.
In any case I would be happy to accommodate your needs, since it's a trivial change.
I think /usr/share/OpenRiichi
would be the proper good place to put these, at least according to my dist's standards.
A compile flag definitely sounds like the right solution to me. I don't know whether that could easily be determined with a prefix=/usr
flag (forninja install
), since I haven't developed system applications so far, but other software I saw meson being used for usually has a DESTDIR="${pkgdir}" ninja -C builddir install
call at the end of the build scripts.
I have added an install target to the meson build file, which should install to the default directories for the distro. I think the behavior is as you described. Could you check if it works properly?
Awesome. In theory I would say yes, but in practice I'm having troubles with submodule handling.
It seems like you made the submodule point to a ref that doesn't exist.
==> Starting prepare()...
Submodule 'Engine' (https://github.com/FluffyStuff/Engine.git) registered for path 'Engine'
Cloning into '/build/open-riichi-git/src/OpenRiichi/Engine'...
done.
fatal: git upload-pack: not our ref 1895cd89beb4701a784f37e06d2d6f36cd20f394
fatal: remote error: upload-pack: not our ref 1895cd89beb4701a784f37e06d2d6f36cd20f394
Fetched in submodule path 'Engine', but it did not contain 1895cd89beb4701a784f37e06d2d6f36cd20f394. Direct fetching of that commit failed.
==> ERROR: A failure occurred in prepare().
Right, I had forgotten to push the Engine repo first. It should work now.
Compiles & installs without issues now. 👍
Great.
Just as a heads up, I took out the dependency on sfml
/csfml
and replaced it with sdl2_mixer
.
I think this will be the only dependency change for the foreseeable future.
I should set some time aside to propose some features or changes while you're still here. :slightly_smiling_face:
Hi, first of all thank you for the hard work @FluffyStuff. I would like to ask whether in the future you plan to provide easy to install packages for Windows and the major linux distros (or even better ask to have OpenRiichi added to the official repos). It would increase the userbase and attract players and contributors I think. Not everyone is able to use terminal. I will try on my Ubuntu and report any feedback/issue I have.