Open Redhawk18 opened 1 week ago
TLATER
commented
6 days ago Hm, awkward, mind repeating what you wanted to ask about here? I do have a mostly finished package here: https://github.com/TLATER/dotfiles/blob/master/pkgs/applications/edopro.nix
Redhawk18
commented
5 days ago I reimpl'ed some of yours so it would work within nixpkgs for a future commit. Also theres a bug in your edopro script, you create a directory called ~ you aren't accessing the home directory. Let me just past my module below here, all I'm missing at the moment is
{ lib
, stdenv
, fetchFromGitHub
, # build deps
premake5
, writeShellScriptBin
, runCommandLocal
, symlinkJoin
, imagemagick
, # edopro deps
bzip2
, curl
, flac
, fmt_9
, freetype
, libevent
, libgit2
, libGL
, libGLU
, libjpeg
, libpng
, libvorbis
, libXxf86vm
, lua5_3
, nlohmann_json
, noto-fonts-cjk-sans
, openal
, SDL2
, sqlite
, # Irrlicht deps
wayland
, egl-wayland
, libxkbcommon
, libX11
,
}:
let
# the assets repo has a font instead
font = "${noto-fonts-cjk-sans}/share/fonts/opentype/noto-cjk/NotoSansCJK-VF.otf.ttc";
pkgs = import <nixpkgs> { };
assets = {
pname = "assets";
version = "40.1.4";
src = fetchTarball {
url = "https://github.com/ProjectIgnis/edopro-assets/releases/download/40.1.4/ProjectIgnis-EDOPro-40.1.4-linux.tar.gz";
sha256 = "sha256-vZhkWJ1ZoNEwdc5kM1S0hyXnWmupiTOanCi9DCuqw/k=";
};
};
irrlicht-edopro = stdenv.mkDerivation {
pname = "irrlicht-edopro";
version = "1.9-custom";
src = fetchFromGitHub {
owner = "edo9300";
repo = "irrlicht1-8-4";
rev = "7edde28d4f8c0c3589934c398a3a441286bb7c22";
hash = "sha256-Q2tNiYE/enZPqA5YhUe+Tkvmqtmmz2E0OqTRUDnt+UA=";
};
buildInputs = [
libGLU
libX11
libxkbcommon
libXxf86vm
wayland
];
enableParallelBuilding = true;
# Dynamic linking causes compile errors so we statically link.
# However it can be re-enabled with adding `sharedlib` to `buildFlags`.
buildFlags = "NDEBUG=1";
makeFlags = "-C source/Irrlicht -j16";
installPhase = ''
mkdir -p $out/{bin,include}
cp lib/Linux/libIrrlicht.* $out/bin
cp -r include/* $out/include
ls -lah lib/Linux/
'';
};
edopro = stdenv.mkDerivation rec {
pname = "edopro";
version = "40.1.4";
src = fetchFromGitHub {
owner = "edo9300";
repo = pname;
rev = version;
hash = "sha256-2E1cjG0FONu/fbr67/3qRCKQ1W/wPznClEWsMa1FAzo=";
fetchSubmodules = true;
};
nativeBuildInputs = [ premake5 ];
buildInputs = [
bzip2
curl
flac
fmt_9
freetype
irrlicht-edopro
libevent
libgit2
libjpeg
libpng
lua5_3
libvorbis
nlohmann_json
openal
SDL2
sqlite
];
# nixpkgs' gcc stack currently appears to not support LTO
postPatch = ''
sed -i '/LinkTimeOptimization/d' ./premake5.lua
'';
# TODO sound, can't get it to work with either SDL2 or sfml
preBuild = ''
premake5 gmake2 \
--architecture=x64 \
--bundled-font='${font}' \
--no-core \
--no-joystick=false
'';
enableParallelBuilding = true;
NIX_CFLAGS_COMPILE = "-I ${irrlicht-edopro}/include -L ${irrlicht-edopro}/bin";
buildFlags = "config=release_x64 ygoprodll";
makeFlags = "-C build -j16";
installPhase = ''
mkdir -p $out/{bin,lib}
cp bin/x64/release/ygoprodll $out/bin
'';
};
edopro-script =
let
assetsToCopy = lib.concatStringsSep "," [
"config"
"deck"
"COPYING.txt"
"expansions"
# We grab the ocgcore from the official release bundle, on
# upstream suggestion; this is completely static and has no
# dependencies, so it should be fine.
"libocgcore.so"
"lflists"
"notices"
"puzzles"
"fonts"
"script"
"skin"
"sound"
"textures"
];
in
writeShellScriptBin "EDOPro" ''
set -eu
EDOPRO_DIR="$HOME/.local/share/edopro"
echo $HOME
if [ ! -d $EDOPRO_DIR ]; then
mkdir -p $EDOPRO_DIR
cp -r ${assets.src}/{${assetsToCopy}} "''${EDOPRO_DIR}/"
find $EDOPRO_DIR -type d -exec chmod u=rwx,go-rwx {} +
find $EDOPRO_DIR -type f -exec chmod u=rw,go-rwx {} +
rm $EDOPRO_DIR/config/io.github.edo9300.EDOPro.desktop.in
fi
export LD_LIBRARY_PATH=$EDOPRO_DIR:'${
lib.makeLibraryPath [
egl-wayland
libGL
libX11
libxkbcommon
libXxf86vm
wayland
]
}';
echo $LD_LIBRARY_PATH
exec ${edopro}/bin/ygoprodll -C "''${EDOPRO_DIR}" $@
'';
edopro-desktop = runCommandLocal "io.github.edo9300.EDOPro.desktop" { } ''
ls -lah ${assets.src}
ls -lah ${assets.src}/config
cp ${assets.src}/config/io.github.edo9300.EDOPro.desktop.in desktop-template
sed '/Path=/d' -i desktop-template
sed 's/Exec=.*/Exec=EDOPro/' -i desktop-template
sed 's/Icon=.*/Icon=EDOPro/' -i desktop-template
install -D desktop-template $out/share/applications/io.github.edo9300.EDOPro.desktop
'';
in
symlinkJoin {
name = "edopro-application";
paths = [
edopro
edopro-script
edopro-desktop
];
postBuild = ''
mkdir -p $out/share/icons/hicolor/256x256/apps/
${imagemagick}/bin/magick \
${assets.src}/textures/AppIcon.png \
-resize 256x256 \
$out/share/icons/hicolor/256x256/apps/EDOPro.png
'';
}I can close this issue and we can make a thread on the nixos discord or really anywhere if this is too offtopic for this repo.
TLATER
commented
5 days ago It's somewhat offtopic, but a PR might be better to discuss this, happy to take your changes to a nixpkgs PR.
Addressing points:
Also theres a bug in your edopro script, you create a directory called ~ you aren't accessing the home directory
Ah, good point, but we should retain the XDG base dir functionality instead of hard-coding ~/.local/share:
EDOPRO_DIR="''${XDG_DATA_HOME:-$HOME/.local/share}/edopro"sound (both backends fail to compile)
Not on my end, but I recall having issues around this. I have since fixed this, what commit did you base your changes on? What's the actual compilation error?
I'm not using nix-ld or anything, so there shouldn't be any differences outside of your code changes.
card assets (not sure where to find these)
This is the main reason I didn't just make a package in nixpkgs. These are deliberately not included because upstream wants to avoid DMCA (claims should technically be invalid if they happen, but when has that ever stopped companies?). We could in theory grab the string from their pre-compiled binaries, but we should not.
The alternative is something like the ygoprodeck database, but they very explicitly say you should not hammer their API, and adding this as a nixpkgs package would cause additional churn for them, so I don't necessarily think that's a good idea either.
I considered writing a module, and simply making it something that has to be defined downstream and needs to be supplied via path instead of string so that people don't accidentally put links in their dotfiles, or make it a source which needs to be added with nix-store --add or whatever. All of those options make it not particularly likely to be a very good upstream package, so I've not really bothered to go much further.
Personally I've just added the string to my config/configs.json by hand for now. Note the URL string is supposed to be a format string, the card ID is substituted in the URL where you place a {}.
optional: we might not need the font required, the asset release comes with a font
Yes, but I figure it's best to have one compiled in just in case.
Redhawk18
commented
5 days ago I was reading more on how konami views dmca's since every company is different. https://www.reddit.com/r/yugioh/comments/d5h58v/why_isnt_konami_claiming_copyrights_to_ygopropercy/
A while ago nintendo DMCA'ed the yuzu emulator and that was a very active package in nixpkgs, so I believe our feeling on this is pedantic. A big reason I wanted to add this to nixpkgs is because this program is a giant nightmare to setup, I understand why. However I already asked @edo9300 about this and I'm waiting for a respond if we can use that website, I guess we play it by ear based off what he says.
Redhawk18
commented
5 days ago I'm going to hold off on the pr for a few days to give edo time to respond. I believe what we are doing is very reasonable, since how if understand that website is hit by n users of edopro already. So we wouldn't be hurting their website since it's designed to just host that artwork.
TLATER
commented
5 days ago However I already asked @edo9300 about this and I'm waiting for a respond if we can use that website, I guess we play it by ear based off what he says.
I asked a few weeks ago. The answer was that they can't stop us, but the intent is clearly not to publish any of these links, that's why they're hidden as secrets in the upstream build process. They also aren't very fond of NixOS, so I would caution prodding around there too much; we're more or less officially unsupported, making annoying support requests is a good way to get changes that make edopro even more tricky to get to run.
I agree that without this, the package isn't really usable, since it would need instructions on how to get stuff working, which we also wouldn't be able to provide. Which is why I didn't create a package to begin with, and why I'm still doubtful this is a good idea. Again, a third party repo/flake is probably more appropriate. You could even provide a cache that has the link-as-a-source pre-loaded so end users don't end up having to specify the link manually.
Why companies are doing what is entirely up to interpretation. By not hosting anything konami has copyright over, DMCA claims are thoroughly invalid. They hold copyright over card texts and images, not the nebulous concept of game rules, so edopro's core is pretty safe. Once you start providing the other stuff, even just as links, things get more nebulous depending on the laws where you are, and that's clearly a grey are upstream has been avoiding.
Yuzu was a completely different story, iirc they were sued since there was literal software piracy going on in the background, with non-clean-room reverse engineering being involved, so as part of a plea the creators took the emulator's main repository down since Nintendo clearly did hold copyright over the reverse engineered software. None of that is happening with edopro. Copyright law is messy, I don't want to be involved in poking any dragons.
Redhawk18
commented
4 days ago I asked a few weeks ago. The answer was that they can't stop us, but the intent is clearly not to publish any of these links, that's why they're hidden as secrets in the upstream build process. They also aren't very fond of NixOS, so I would caution prodding around there too much; we're more or less officially unsupported, making annoying support requests is a good way to get changes that make edopro even more tricky to get to run.
I'd like to hide the link if its possible somehow but I'm not sure how. In other news I'm not sure if edopro has been busy or just got annoyed with my struggling to link the core but he stopped responding to me a long time ago.
I agree that without this, the package isn't really usable, since it would need instructions on how to get stuff working, which we also wouldn't be able to provide. Which is why I didn't create a package to begin with, and why I'm still doubtful this is a good idea. Again, a third party repo/flake is probably more appropriate. You could even provide a cache that has the link-as-a-source pre-loaded so end users don't end up having to specify the link manually.
I'm unsure, because we'll also removing the link thats embedded in the compiled binary. Ultimately I don't believe the difference in a nur or nixpkgs really changes anything. However the more eyes that link touches is for the worse. Some ways we could try to better this are
I don't think we can make everyone happy here, a lot of the time people just tell me "just use ubuntu or arch, why would you use a niche os no one else uses?" Doing this would help out users of nixos that use edopro, not doing it would not help anyone. While I'm on edopro's side with wanting to keep the assets hidden, I also want this program to be easy to setup.
edit: My point is that for another app it lowers the barrier of entry into nixos because its one less chance they have to read an article on nix-ld. When I was new to nixos I couldn't figure out nix-ld and it was a skill issue but those are a sign something is just too hard to begin with.
Why companies are doing what is entirely up to interpretation. By not hosting anything konami has copyright over, DMCA claims are thoroughly invalid. They hold copyright over card texts and images, not the nebulous concept of game rules, so edopro's core is pretty safe. Once you start providing the other stuff, even just as links, things get more nebulous depending on the laws where you are, and that's clearly a grey are upstream has been avoiding.
The text and names are already embedded in the game without those card assets, they already have ground in that case. How legal people see it is one millimeter over the line is the same as a mile.
TLATER
commented
4 days ago wrap the entire package around nix-ld
I mean, if you are already using nix-ld you can just use the binary published on the edopro website and it will work out of the box. I left instructions about it on their discord, if you're just looking for a convenient way to run it; I forgot the exact libraries you needed to add, but something like this should work:
{ pkgs, ... }: {
programs.nix-ld = {
enable = true;
libraries = with pkgs; [
wayland
egl-wayland
libxkbcommon
# Some sound libraries
];
};
}I mainly built this package from source because I wanted to fix some issues I had with edopro and have a convenient way of running downstream branches, though I've since decided that long-term just implementing a UI on top of the lua stuff from scratch is going to be more reasonable.
a lot of the time people just tell me "just use ubuntu or arch, why would you use a niche os no one else uses?"
It's ultimately your responsibility to know how to work around issues that arise from using off-the-beaten-path tools. I don't begrudge the edopro folks for their opinion, they should not need to take on maintenance for our issues.
Doing this would help out users of nixos that use edopro
If that's the primary objective, let's just write a NixOS wiki page once you've figured out which libraries need to be added to nix-ld?
Redhawk18
commented
4 days ago a lot of the time people just tell me "just use ubuntu or arch, why would you use a niche os no one else uses?"
It's ultimately your responsibility to know how to work around issues that arise from using off-the-beaten-path tools. I don't begrudge the edopro folks for their opinion, they should not need to take on maintenance for our issues.
I brought this up because I've never had a problem with nixos, the things I've had problems with are buggy software or undocumented code/build systems. I always get blamed for the issues since I'm using nixos but it's never has been me.
If I do end up making this a package do you want to be a maintainer? It's a by name package so it should never need maintenance.
TLATER
commented
4 days ago If I do end up making this a package do you want to be a maintainer
Sure, assuming we find a proper solution to this image problem. I was preparing to make a PR until I realized how difficult this is to solve.
My other repo just uses an fhs env, which would probably be nicer for a general purpose package, though I've learned a lot since and could probably do a better job from scratch: https://github.com/TLATER/tlaterpkgs/blob/3f24cedcca1b29cf639a7ec164532f1e192e7e7f/pkgs/edopro.nix#L41
At the very least I'd like to know about the PR if you create one so I can point out the remaining issues I know about. The asset copying thing isn't perfect either, iirc as-is it results in issues with updates.
Also this was a fair bit of work and I'd like some credit ;p
Redhawk18
commented
4 days ago Are you not in the maintainer list? I don't see you.
Redhawk18
commented
4 days ago I sent you a discord friend request so I can send you the secret asset links
Redhawk18
commented
3 days ago Also I was looking at how they download assets in edopro, and we actually met the rules ygoprodeck explains in their api docs, we would only download each image and store it locally.
Redhawk18
commented
3 days ago Also a pro of using ygoprodeck is that it permits you to use http instead of https
Redhawk18
commented
3 days ago I fixed it, making the pr now
Redhawk18
commented
3 days ago More talk on the discord and it seems the edo community is less scared about sharing their rehosted image links than we are. So for the time being we could set it to ygoprodeck, the owner of that site was said to hate using cards for sims. It's likely that the edopro people do not truly care along as it is to support edopro itself and not a fork, but I'm waiting for edopro9300 to respond on discord.
Sorry for the offtopic issue, but I saw you are active in this repo. I sent you an email about trying to package edopro.