add nix flake support

[beh-10257]

this fixes my issue here: #71
so what are my questions
am I allowed to add a section about how to use this
basically just something like this

  inputs = {
    umu= {
      url = "git+https://github.com/Open-Wine-Components/umu-launcher/?dir=packaging\/nix&submodules=1";
      inputs.nixpkgs.follows = "nixpkgs";
    };
 }
{
  environment.systemPackages = [  inputs.umu.packages.${pkgs.system}.umu  ];
}

and also possibly a bug since well it will accur in other immutable distros basically now umu copies read only files from /usr/share to .local/share/umu it seems those files can't be modified obviously same with
.local/share/Steam/
so instead of throwing an error
some users will just naivly run it as root
just give the user a message saying
run
chmod -R u+w .local/share/Steam/
chmod -R u+w .local/share/umu/
thats all and thanks

also about that other paricipant well I was stupid enough to put whatever in
"user.name" and "user.email"
so yeah here we are
sorry I have no idea how to fix this mess before creating this

[loathingKernel]

am I allowed to add a section about how to use this
basically just something like this

You will have to explain what "this" does because I think most of us, myself included, are not familiar with NixOS's packaging. I do not understand what the code snippet is doing.

and also possibly a bug since well it will accur in other immutable distros basically now umu copies read only files from /usr/share to .local/share/umu it seems those files can't be modified obviously same with

I do not understand how this works. Normally (as in for non-immutable distros) when something is copied as your user into a writable location, the ownership goes to the user doing the copy, is Nix different in this regard? Is there something else that is different about Nix affecting this issue?

some users will just naivly run it as root

I agree what we could/should not execute anything if run as root and add a message about it but I don't see how it is connected to the issue above as the issue is unclear to me.

I would like some clarifications about these things, it can help us figure out what should be handled by umu itself and what should be part of packaging. Also feel free to explain them in detail as I think most people are not familiar with the intricacies of NixOS.

[R1kaB3rN]

  inputs = {
    umu= {
      url = "git+https://github.com/Open-Wine-Components/umu-launcher/?dir=contrib\/nix&submodules=1";
      inputs.nixpkgs.follows = "nixpkgs";
    };
 }
{
  environment.systemPackages = [  inputs.umu.packages.${pkgs.system}.umu  ];
}

Thanks for this contribution, and I'm very open to having a Flake included. I'll have to look into how it works in a bit though, and I don't think anyone from the team is very familiar with NixOS either.

and also possibly a bug since well it will accur in other immutable distros basically now umu copies read only files from /usr/share to .local/share/umu it seems those files can't be modified obviously same with .local/share/Steam/ so instead of throwing an error some users will just naivly run it as root just give the user a message saying run chmod -R u+w .local/share/Steam/ chmod -R u+w .local/share/umu/ thats all and thanks

Yes, the launcher (umu_run.py) and the wrapper script (umu-run) should easily be able to handle this case -- not running as root.

Also, are file permissions not able to be set in the Flake file? The launcher copies files via copy which respects the file permissions mode, so if permissions are properly setup during packaging phase then we can avoid having to display that message.

[beh-10257]

so I'll make two comments first one explaining what each file does since well why not
and the second one will contain that problem with running as root and write permissions

I'll start with the first comment
so to install this flake the user should add

    umu= {
      url = "git+https://github.com/beh-10257/umu-launcher-nix/?dir=packaging\/nix&submodules=1";
      inputs.nixpkgs.follows = "nixpkgs";
    };

disclaimer (I am using my repo since this is not merged yet)
to his inputs
so what does that mean it tells nix to use git to clone this repo https://github.com/beh-10257/umu-launcher-nix somewhere in /nix/store/
?dir=packaging\/nix tells that the flake.nix exists in packaging/nix directory and submodules=1 tells it to download git submodules
aka: https://github.com/Open-Wine-Components/umu-launcher/tree/main/subprojects
since we don't want an empty directory there
inputs.nixpkgs.follows = "nixpkgs"; you can think of nixpkgs as the repos of a distro this says to nix to ignore the version I provided and use the version in the user config.
this is just so the user doesn't have two version of nixpkgs in their system the version in their config and the one defined in flake.lock here

and next they should add this somewhere in their flake

{ inputs, ... }:
{
  environment.systemPackages = [
    inputs.umu.packages.${pkgs.system}.umu
  ];
}

it basically goes to the umu input and takes the umu package \ ${pkgs.system} translates to x86_64-linux aka the architecture of the package

---

next I'll explain what the files commited to this repo do
first flake.nix

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };

this says to the flake to use the unstable version of nixpkgs
the specific commit of nixpkgs is fixed if flake.lock
just making a quick look at flake.lock pretty much explains everything

for exemple it fixes the revision so without adding this line inputs.nixpkgs.follows = "nixpkgs"; in the user config
as was mentioned before
it will download nixpkgs with this commit
"57e6b3a9e4ebec5aa121188301f04a6b8c354c9b"

---

next in flake.nix we have this line
umu-package = nixpkgs.legacyPackages.x86_64-linux.callPackage ./umu-launcher.nix { umu-launcher=( builtins.toPath "${self}/../../"); };
this defines a variable (the type is a package btw; yes paths and packages are actual variable type in nix language)
anyway this basically just calls umu-launcher.nix for the package definition and passes along some variables
umu-launcher is just the name of the path to the source of this repo aka: https://github.com/Open-Wine-Components/umu-launcher
it will be used in umu-launcher.nix file obv
builtins.toPath "${self}/../../" basically is the path to that source in the /nix/store as I said in the beginning
${self} returns where is flake.nix specifically
heres an example

in this exemple ${self} is "/nix/store/2kgj382l1931vdjf5vi6rrpycs6n6sxy-source/packaging/nix"
thats why we should add ../../
also toPath since well we should transform strings to paths if we want to build the thing
anyway this all passes along to umu-launcher.nix

---

{stdenv , umu-launcher, pkgs, ...}:
stdenv.mkDerivation {
  pname = "umu-launcher";
  version = "0.1";
  src = umu-launcher;
  depsBuildBuild = [
    pkgs.meson
    pkgs.ninja
    pkgs.scdoc
  ];
  dontUseMesonConfigure = true;
  dontUseNinjaBuild = true;
  dontUseNinjaInstall = true;
  dontUseNinjaCheck = true;
  configureScript = "./configure.sh";
}

so as you can see its taking the aforementioned umu-launcher variable
stdenv.mkDerivation is basically the regular build enviroment in nix to use make and that kinda stuff (what this project is using)
src is umu-launcher aka the path to the repo aka what was said before (toPath and stuff)

  dontUseMesonConfigure = true;
  dontUseNinjaBuild = true;
  dontUseNinjaInstall = true;
  dontUseNinjaCheck = true;
  configureScript = "./configure.sh";

all other variables are self explanatory right ?? (basically nix is stupid and I have to tell him not to do stuff automatically)
this all now provides

which is great but when I run this in an actual game
we get this error

NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld

anyway yeah that link brings me here: https://nix.dev/guides/faq#how-to-run-non-nix-executables
basically generic libraries can't be run in nix beside the fact it doesn't follow FHS standard

I guess the executable in question is

so yeah I followed that page to create an FHS like enviroment

thats the next variable in flake.nix, another package and I named the variable umu-run
and it take the original package as an input and is defined in umu-run.nix
so between let in I can define variables and well

  ldPath = lib.optionals stdenv.is64bit [ "/lib64" ] ++ [ "/lib32" ];
  exportLDPath = ''
    export LD_LIBRARY_PATH=${lib.concatStringsSep ":" ldPath}''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
  '';

this basically adds /lib64:/lib32: to the start of that variable (this is basically stolen on how steam is packaged in nix)
but I mean it makes sense in my head

except that fact I just did this as well

to see the difference

/run/opengl-driver/lib:/run/opengl-driver-32/lib:/etc/sane-libs:/nix/store/cvalskd4xbqf5f7srlzl60213s0s3fwz-pipewire-1.0.4-jack/lib
after exporting
/lib64:/lib32:/run/opengl-driver/lib:/run/opengl-driver-32/lib:/etc/sane-libs:/nix/store/cvalskd4xbqf5f7srlzl60213s0s3fwz-pipewire-1.0.4-jack/lib

anyway next name="umu" umu is what should the user run to be in the enviroment and not have NixOS cannot run dynamically linked executables intended for generic linux environments

---

next

  runScript = writeShellScript "umu-env" ''
    ${exportLDPath}
    ${package}/bin/umu-run "$@"
  '';

the ${package} here is the path to umu-package aka

"/bin/umu-run" goes to the binary as you can image and "$@" passes whatever is after umu
aka here
umu path_to_exe "$@" is replaced with path_to_exe I guess
so now we have a working command umu which runs umu correctly

---

anyway now the problem we have is this

in our Path
this is confusing and not helpful
so we should find a solution we can do this in flake.nix to fix the problem

{
  description = "umu universal game launcher";
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    umu-launcher = {
      flake = false;
      url="git+https://github.com/Open-Wine-Components/umu-launcher?submodules=1";
    };
  };
  outputs = { self, nixpkgs, umu-launcher }:
  let
    umu-package = nixpkgs.legacyPackages.x86_64-linux.callPackage ./umu-launcher.nix { umu-launcher=umu-launcher; };
  in
  let
    umu-run = nixpkgs.legacyPackages.x86_64-linux.callPackage ./umu-run.nix { package=umu-package; };
  in{
    packages.x86_64-linux.umu-run = umu-run;
    #packages.x86_64-linux.umu-package = umu-package;
  };
}

this will basically remove umu-run from PATH but also man umu will not work since well man page comes from umu-package and that line is now commented out which is a problem since I want man pages to work

---

basically
we want the binary from umu-run and the man pages from umu-package
btw all other functionality works
since umu-package is a dependency of umu-run so everything is there its just not exposed so we should expose it
so yeah there is obviously a solution now to the final part
I'm defining a package called umu package (the only exposed output in the commited flake.nix)
its as always talking combine.nix and taking two variables 2 packages the environment and the actual package
combine.nix is obvious I think like read it anyway
the final output is a working umu and man page

so yeah great
I think I explained everything
yay it works

[loathingKernel]

Thank you for the very detailed description, personally I will need to read it a few times to comprehend it. In the meantime, one easy to fix issue that I missed before is that we already use the packaging directory for packaging related stuff. Please use that instead of contrib to keep things tidy.

[beh-10257]

anyway now running as root and the read only problem
as you can see first of all

/nix/store directory is read only aka immutable distro and remember basically everything related to system (including packages including umu) is symlinked to /nix/store
also

and
heres the actual problem


so

yay this works now
anyway as far as I'm concerned we can just make a disclaimer in the installation section about immutable distros
and the least we can do is to never allow users to use umu with sudo

[beh-10257]

@loathingKernel done

[loathingKernel]

So if I understand correctly the issue is that Nix, doesn't have the writable bit for user. @R1kaB3rN maybe this can simply be fixed by using os.chmod() to set the correct bits on the user-local files after being copied. All we need is write for user for the whole .local/share/umu directory, preferably through a mask to retain the execute permission on each file. This could be useful to other distros too.

[beh-10257]

so should I edit
https://github.com/Open-Wine-Components/umu-launcher/blob/main/README.md

if I will at which section should I add this
as far as I can see there is no specific section for installing for distros
can I just through it in installing section or something
or maybe in a new section where there will be nix flatpak in that section aka how to install

[loathingKernel]

IMHO, a new section after Building, titled Packages or something similar would be the better approach for this, and a subsection for NixOS. We can add more later as they become available.

[R1kaB3rN]

There's many ways to go about it in the README. If it were me, I'd combine the Installing and Installing as user section to a make section then have the next section be NixOS.

For example:

Install

make

NixOS

[loathingKernel]

Looks good to me content-wise. Only nitpick is that since #75 is merged in main now, if it would be possible to rebase the changes on it, it would result in a cleaner hsitory. This isn't a blocker though as we could also squash-merge, it's up to you.

[beh-10257]

@loathingKernel I mean I think I already did so
in here: https://github.com/beh-10257/umu-launcher-nix/commits/main/

(thats why I was messing around with git rebase in the first place)
also the reason they are 24 commits is well I managed to somehow have a couple of the same commits committed at the same time
I have no idea why is that and I am so sorry for messing it up (I am very new to using git so yeah)

[R1kaB3rN]

@beh-10257 Before I merge this, to clarify again, you weren't able to get man pages to work?

[R1kaB3rN]

@beh-10257 Thanks for your contribution! I'll be closing this as its been merged at 81707ad

[beh-10257]

@R1kaB3rN no
man pages are working properly
its just that the executable name is umu instead of umu-run
and man umu works perfectly fine
sorry for not explaining well enough

[beh-10257]

@R1kaB3rN you forgot about this I supposed e85a921

I checked already done sorry sorry

[beh-10257]

basically this

[R1kaB3rN]

@R1kaB3rN you forgot about this I supposed e85a921

Fixed in 237d574