I sent you an email

[Redhawk18]

Sorry for the offtopic issue, but I saw you are active in this repo. I sent you an email about trying to package edopro.

[TLATER]

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]

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

• controller support (it doesn't work with my controller, but it might for someone, who knows)
• sound (both backends fail to compile)
• card assets (not sure where to find these)
• optional: we might not need the font required, the asset release comes with a font
• optional: ai support ( I don't understand why mono is required this is all c++)

{ 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]

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]

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]

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]

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]

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

1. wrap the entire package around nix-ld
2. extract the already linked images from the official binary
3. download images at compile time
4. download images at runtime (our current option)
5. writing a custom obfuscated compiled program to download them and embed at compile time (best of both worlds?)
6. writing manual instructions (👎)
7. I asked on the nixos discord and @kiwiduckie responded that this package injects a sercet so its hidden from the user at all times, maybe something like this

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]

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]

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]

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]

Are you not in the maintainer list? I don't see you.

[Redhawk18]

I sent you a discord friend request so I can send you the secret asset links

[Redhawk18]

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]

Also a pro of using ygoprodeck is that it permits you to use http instead of https