-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
xow: init at 0.2 #76185
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
Conversation
Thanks for the thorough review @infinisil! |
pkgs/misc/drivers/xow/default.nix
Outdated
sha256 = "03ajal91xi52svzy621aa4jcdf0vj4pqd52kljam0wryrlmcpbr3"; | ||
}; | ||
|
||
makeFlags = "BUILD=RELEASE"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
- Make uinput and USB devices r/w for all users (current option, similar to ds4drv).
- Make uinput and USB devices r/w for current user (udev tag
uaccess
). What do we do in theservice
file? Only specify a single user? - 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)?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"; | ||
}; | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
services.hardware.uinput.enable = true; | ||
|
||
systemd.services.xow = { | ||
wantedBy = [ "multi-user.target" ]; |
There was a problem hiding this comment.
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.
65909b1
to
5359329
Compare
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. |
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. |
There was a problem hiding this 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
@jtojnar Looking good for you too? |
There was a problem hiding this 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.
@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. |
@jansol Sorry, xow sadly isn't even something I need anymore. If you like, please take over. |
Continuing work in #83732, this PR can be closed. |
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
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)