Skip to content

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

Merged
merged 1 commit into from
Jul 14, 2017
Merged

ring-daemon: init at 2017-07-11 #27311

merged 1 commit into from
Jul 14, 2017

Conversation

Radvendii
Copy link
Contributor

@Radvendii Radvendii commented Jul 11, 2017

Motivation for this change

RING DAEMON!!! 😁 (I have been trying to get this working for a while)

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • 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 nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

Sorry, something went wrong.

@Radvendii
Copy link
Contributor Author

There are a couple of things that I haven't gotten working yet (video, for example). Should I mark that somewhere?

@Radvendii
Copy link
Contributor Author

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

@Radvendii
Copy link
Contributor Author

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.

@joachifm
Copy link
Contributor

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.

@Radvendii
Copy link
Contributor Author

@joachifm Oh good call. They are actually contained in the src of ring-daemon. Can I include them somehow like ${src}/path/to/path?

@joachifm
Copy link
Contributor

Sure. You need to rearrange things slightly, but in principle you should be able to do that quite simply.

@joachifm
Copy link
Contributor

I'm lazy so I'd simply float the src to the outer scope to make accessing it more convenient.

Copy link
Contributor

@joachifm joachifm left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

@Radvendii Radvendii Jul 11, 2017

Choose a reason for hiding this comment

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

and cping dringctrl.py into $out/bin?

Copy link
Contributor

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.

Copy link
Contributor Author

@Radvendii Radvendii Jul 12, 2017

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 = ''
Copy link
Contributor

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).

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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).

Copy link
Contributor Author

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?

Copy link
Contributor

@joachifm joachifm Jul 11, 2017

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

How so?

Copy link
Member

@Mic92 Mic92 Jul 12, 2017

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor

@joachifm joachifm left a 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";
Copy link
Contributor

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";
Copy link
Contributor

Choose a reason for hiding this comment

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

Please capitalize description

@Radvendii
Copy link
Contributor Author

Is there a reason the checks are failing? It builds on my computer with nix-build -A ring-daemon

@joachifm
Copy link
Contributor

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.

@Radvendii
Copy link
Contributor Author

How do I do that? nix-build --option build-use-sandbox true -A ring-daemon?

@joachifm
Copy link
Contributor

If you use the nix daemon, you must enable it in nix.conf.

@Radvendii
Copy link
Contributor Author

Radvendii commented Jul 13, 2017

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.

@joachifm
Copy link
Contributor

So you're on nixos but don't use the daemon? Hm, okay.

@Radvendii
Copy link
Contributor Author

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

@joachifm
Copy link
Contributor

Unless you went out of your way to disable the daemon, you're likely using it. See e.g, systemctl status nix-daemon.

@Radvendii
Copy link
Contributor Author

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.

@joachifm joachifm merged commit e4229bb into NixOS:master Jul 14, 2017
@joachifm
Copy link
Contributor

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants