-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
ring-daemon: init at 2017-07-11 #27311
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
Conversation
There are a couple of things that I haven't gotten working yet (video, for example). Should I mark that somewhere? |
Also, I'm not sure if restbed should be a different package, but I'm using a super specific version of it and somehow I doubt it will be useful to anyone else |
Should dringctrl.py be a separate package? It's a little script that you can use to control dring without using the dbus interface directly. |
The patches do not look nixpkgs specific. Please do not check them into the repository. If you are the author, consider submitting the patches upstream, otherwise provide an external source. |
@joachifm Oh good call. They are actually contained in the src of ring-daemon. Can I include them somehow like ${src}/path/to/path? |
Sure. You need to rearrange things slightly, but in principle you should be able to do that quite simply. |
I'm lazy so I'd simply float the src to the outer scope to make accessing it more convenient. |
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.
Added a few notes for your consideration.
mkdir $out/bin | ||
ln -s $out/lib/ring/dring $out/bin/dring | ||
cp -R ./tools/dringctrl/ $out/ | ||
echo -e "#!${bash}/bin/bash\n${python}/bin/python $out/dringctrl/dringctrl.py \"\$@\"" > $out/bin/dringctrl |
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 about patching the python interpreter path directly into the script instead of this indirection? Wrappers are best avoided if at all possible.
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.
and cp
ing dringctrl.py into $out/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.
The standard build sequence involves scanning outputs for shebangs that can be patched, so if you're lucky you could simply copy the python script to $out/bin
and it'd Just Work.
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 wasn't automatically patching the shebang, and the python file needs the other files in dringctrl to run, so I copied the whole thing into $out and then symlinked it into $out/bin/. I also had to manually change the shebang as patchShebangs
wasn't doing anything.
speexdsp | ||
]; | ||
|
||
preConfigure = '' |
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.
Have you tried the autoreconfHook
? It removes some of the boilerplate (adding autotools to the build environment, running autogen).
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.
Keeping the working version for now makes sense.
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 had just taken out a package that was necessary. autoreconfHook works
}; | ||
|
||
buildInputs = [ | ||
which |
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.
Tools that run only on the build host can be added to nativeBuildInputs
(only really matters for cross compilation).
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.
Does this go for all of them, or just which
? Or do I have to test each one?
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.
A rule of thumb is that tools that are used only as part of the build process (hence only runs on the build machine) can/should be added to the native inputs. Consider the case where build and host machines differ (incompatible). In that case, a which
built for the host would fail to run on the build machine, so if which
was intended to be used during the build, you'd need to mark it as native. If which
is intended to run on the host (suppose the program you're building shells out to which
at runtime) you'd add it to buildInputs
.
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.
So if a tool is needed in both contexts (building and running), should it be put in both nativeBuildInputs and buildInputs?
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.
Done... I think. Not entirely sure what goes where, but I made educated guesses
@@ -0,0 +1,133 @@ | |||
{ stdenv | |||
, lib |
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.
lib
is typically accessed via stdenv.lib
.
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.
done
@@ -0,0 +1,133 @@ | |||
{ stdenv | |||
, lib | |||
, callPackage |
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.
callPackage
is primarily intended to be used at the toplevel, not within package expressions, where explicit import
is typically used instead.
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.
done.
|
||
patchdir = "${src}/contrib/src"; | ||
|
||
restbed = import ./restbed.nix { |
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.
import
inside a package prevents the use ring-daemon.override {}
. It might be a better idea to make restbed
a dedicated package in all-packages
.
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.
How so?
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.
For clarification: it prevents someone from overriding restbed
in ring-daemon.override{}
. It also prevents restbed.overide{}
since restbed
is used without callPackage
.
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.
Yeah. I'm using a really specific version of restbed though, so I figured it wasn't worth making into a package. And then someone on IRC agreed with me. I'm happy to make a separate package though if that's the consensus.
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's also an old version of restbed
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.
Final nits, then I have nothing further on this.
|
||
stdenv.mkDerivation rec { | ||
name = "restbed-${version}"; | ||
version = "34187502642144ab9f749ab40f5cdbd8cb17a54a"; |
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 guess this is strictly an internal component, but in general using revisions for version strings is not recommended. It is important that new > old
so that name based package management will be able to pick up on updated versions. You can use the date of the revision in year-month-day
format instead.
''; | ||
|
||
meta = with stdenv.lib; { | ||
description = "a Voice-over-IP software phone"; |
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.
Please capitalize description
Is there a reason the checks are failing? It builds on my computer with |
Travis can't complete if there are large rebuilds going on. In general, if the failure doesn't look related to your change, ignore it. But please consider enabling sandboxing when testing locally, it helps identify implicit dependencies. |
How do I do that? |
If you use the nix daemon, you must enable it in nix.conf. |
I don't, so it looks like using the command line option works fine (from what I read in the nix manual). Alright, I tested using that and it still works fine. |
So you're on nixos but don't use the daemon? Hm, okay. |
Not that I'm aware of at least? It said in the manual that the daemon is for multi-user systems where people don't have wheel or something. I might be wrong about all this, I'm not very familiar with the inner workings of nixos |
Unless you went out of your way to disable the daemon, you're likely using it. See e.g, |
Oh I see now. The command line option seemed to work fine, but now I added the option to my configuration.nix and built again. Everything seems fine. |
Thank you |
Motivation for this change
RING DAEMON!!! 😁 (I have been trying to get this working for a while)
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)