Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xow: init at 0.2 #76185

Closed
wants to merge 1 commit into from
Closed

xow: init at 0.2 #76185

wants to merge 1 commit into from

Conversation

pmiddend
Copy link
Contributor

Motivation for this change

I have first tested xow on my local machine and it worked flawlessly. Then I created the package and my first NixOS service with it. I tested this service using a VM and it worked.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

nixos/modules/services/hardware/xow.nix Show resolved Hide resolved
pkgs/misc/drivers/xow/default.nix Outdated Show resolved Hide resolved
pkgs/misc/drivers/xow/default.nix Outdated Show resolved Hide resolved
@pmiddend
Copy link
Contributor Author

Thanks for the thorough review @infinisil!

nixos/modules/services/hardware/xow.nix Outdated Show resolved Hide resolved
nixos/modules/services/hardware/xow.nix Outdated Show resolved Hide resolved
pkgs/misc/drivers/xow/default.nix Outdated Show resolved Hide resolved
nixos/modules/services/hardware/uinput.nix Outdated Show resolved Hide resolved
nixos/modules/services/hardware/uinput.nix Outdated Show resolved Hide resolved
sha256 = "03ajal91xi52svzy621aa4jcdf0vj4pqd52kljam0wryrlmcpbr3";
};

makeFlags = "BUILD=RELEASE";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
makeFlags = "BUILD=RELEASE";
makeFlags = [
"INSTALL_PATH=${placeholder ''out''}/bin"
"SERVICE_PATH=${placeholder ''out''}/lib/systemd/user"
"BUILD=RELEASE"
];

will allow you to use the default installPhase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly, not really:

cp: cannot create regular file '/nix/store/jd1mrvsb21pcxn4s1x6681rkypybj455-xow-0.2/lib/systemd/user': No such file or directory

I'm not sure about fixing this, though. Should the xow author do this in the Makefile?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, it is not trying to create the dirctetory. You will also need to add mkdir -p $out/lib/systemd/user into preInstall.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, apparently, the install target also tries to enable and start the service, which is an incredibly bad practice:

https://github.com/medusalix/xow/blob/897eee07351f88a04eb16a02b8bca0b91f91cad4/Makefile#L32-L33

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, developer here. Could you please explain why this is a bad practice?

Copy link

@medusalix medusalix Jan 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation. I've fixed some of the issues in the install branch, though I'm still unsure about the udev rules. We've basically got three options:

  1. Make uinput and USB devices r/w for all users (current option, similar to ds4drv).
  2. Make uinput and USB devices r/w for current user (udev tag uaccess). What do we do in the service file? Only specify a single user?
  3. Make uinput and USB devices r/w for a single group (could be named xow).

What do you think? What's the best option (both for NixOS and users building from source)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not a udev expert but I have seen uaccess recommended over GROUP and MODE in other PRs. Though apparently, the filename must be ordered before 73-seat-late.rules according to systemd/systemd#4288 (comment). As for the service, would it be possible to make it a user service? That way, it would already run under plugdev group (I understand is required for udev access).

Copy link

@medusalix medusalix Jan 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, with user services we would get a service instance of xow for each user session that is currently active. That's quite problematic because only one instance can have the USB device open at the same time. I'm now using systemd's DynamicUser (which should be safer than running as root), but that didn't work with uaccess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would SupplementaryGroups=plugdev work? Otherwise, I would try writing to systemd ML.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It certainly works, but it's limited to Ubuntu and Debian and is deprecated according to systemd.

rev = "v${version}";
sha256 = "03ajal91xi52svzy621aa4jcdf0vj4pqd52kljam0wryrlmcpbr3";
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In postPatch we should fix the path in the service file:
https://github.com/medusalix/xow/blob/897eee07351f88a04eb16a02b8bca0b91f91cad4/xow.service#L5

Also, an issue should be opened upstream.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's a better path for the executable in the service file in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path should be based on the INSTALL_PATH passed to make, instead of the hardcoded /usr/local/bin.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean make should change the service file to adapt the path and install that to the proper location?

Copy link
Contributor

@jtojnar jtojnar Dec 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This is usually done by having foo.service: foo.service.in target and creating foo.service from foo.service.in by replacing the template values. Though, usually, the value to replace is set in configure step with Autotools.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. Instead of patching this systemd and Makefile file in lots of places, I'd like to open an issue upstream and see if we can get the whole file + installation process fixed for the next xow release.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any improvements to the build process are welcome, though I'd like to keep the Makefile as simple as possible (part of the reason I didn't consider Autotools).

pkgs/misc/drivers/xow/default.nix Show resolved Hide resolved
services.hardware.uinput.enable = true;

systemd.services.xow = {
wantedBy = [ "multi-user.target" ];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should use the upstream service definition via systemd.packages and only override those values that are wrong/missing.

nixos/modules/services/hardware/xow.nix Outdated Show resolved Hide resolved
pkgs/misc/drivers/xow/default.nix Outdated Show resolved Hide resolved
pkgs/misc/drivers/xow/default.nix Outdated Show resolved Hide resolved
@pmiddend pmiddend force-pushed the xow-init branch 2 times, most recently from 65909b1 to 5359329 Compare December 28, 2019 09:09
@medusalix
Copy link

Please put this issue on hold until I've figured out the licensing issues (medusalix/xow#15). I forgot to add the necessary disclaimer for Mediatek's firmware that's included with xow, so we'll have to wait and see if Mediatek approves its distribution. If they do, then this package will probably end up in the unfree section of nixpkgs.

@medusalix
Copy link

Since I didn't hear back from Mediatek (sent multiple mails to different people), I guess they are fine with the current license terms.

@pmiddend Please take a look at the changes to the Makefile in xow v0.3. I've extracted some of the hardcoded paths to variables which should make the packaging much easier for you.

Copy link
Member

@infinisil infinisil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me

@infinisil
Copy link
Member

@jtojnar Looking good for you too?

Copy link
Contributor

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xow 0.3 was released which sets the bindir in the service file correctly. We should update to that and drop our service settings.

@jansol
Copy link
Contributor

jansol commented Mar 29, 2020

@pmiddend Do you have time to update this PR so we can get it merged? If not and you don't mind, I can take over.

@pmiddend
Copy link
Contributor Author

@jansol Sorry, xow sadly isn't even something I need anymore. If you like, please take over.

@jansol jansol mentioned this pull request Mar 30, 2020
10 tasks
@jansol
Copy link
Contributor

jansol commented Mar 30, 2020

Continuing work in #83732, this PR can be closed.

@jtojnar jtojnar closed this Mar 30, 2020
@pmiddend pmiddend deleted the xow-init branch March 30, 2020 06:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants