Re: [Nix-dev] Multiple instances - detecting resource collisions - nixos module system question
My prediction: This will cause more headaches than it will save.
On Jan 14, 2015, at 10:17 PM, Marc Weber marco-owe...@gmx.de wrote:
If you use multiple apaches/nginx/mysql/postgresql/whatever instances
its likely to miss adjusting the port or whatsoever. Therefore I'd like
to implement a simple resource tracking module which fails if a
resource such as tcp/ip port or socket or such gets used multiple times.
It should look like this: http://dpaste.com/10RKJSQ
A test like this:
resources.tcp-ports.80 = {};
causes:
The option `resources.tcp-ports.80.allowCollisions' defined in
`/etc/nixos/nixpkgs/nixos/modules/misc/resources.nix' does not exist.
which I don't get because the dpaste sets a default value for
allowCollisions.
Thus does anybody just spot what I'm doing wrong?
If we are at it: Eelco Dolstra proposed services.mysql.services or
such. What about services.mysqls ? We could deprecade services.mysql
then and ask users to switch slowly. No naming collisions. Naming is
short and could be adopted to other services.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghc-mod fail errors: bug: gmeioException
You need to cabal clean cabal configure again in your project. The dist/config file is now binary, and you have a version mismatch Alan On 19 Jan 2015 01:35, Carlo Nucera medit...@gmail.com wrote: Hi all, I recently did a `nix-channel update` and a reinstall of my programs, and now I have in emacs+ghc-mod this problem: Fail errors: BUG: GMEIOException /home/carlo/code/haskell/helios/dist/setup-config: hGetContents: invalid argument (invalid byte sequence) After a brief search, it's probable that the issue is caused by the new version of cabalInstall. (see https://github.com/kazu-yamamoto/ghc-mod/issues/417) Anyone has had the same problem on nixOS? Best Regards Carlo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
I request that we come up with a detailed and carefully thought out contribution guideline which evolves and grows. It should keep pychopaths under control, expand bottlenecks and make this development process fun! I've suggested Pieter Hintjens C4 and ensuing private discussions made it clear the approach is _not_ compatible with NixOS. Therefore with the C4 in hand might we start editing and adapting it to our needs? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 19 Jan 2015 00:33:04 + Marc Weber marco-owe...@gmx.de wrote: - I have patches pending for apache http and nginx making them more configurable (eg allowing to set the IP to listen to) Do you mean listen address per virtual host ? That would be really great to have. At the moment it is not possible to use multiple HTTPS virtual hosts on the same machine due to the lack of a configurable IP address per virtual host. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iJwEAQECAAYFAlS8sCEACgkQDog4ovJRA8RpNAQAqOm8ZSgexR5KnykVAAE9UU64 DXuumr9FJVV3ImKV6RAWZv5W1l43oChL2yhBDOCgLia/hZo9SD7GNzK+TVKIV/A0 xyZbbVP+jhNjkJFUYtq5jn5YxNy6FI5rvp+xxjNZ2Y4TeAx/pDroYZAG+9+9sL4S HqzOxu/4xBY0/524t0Q= =W0+J -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
I can only speak for myself: In the past the community or some members didn't accept what I did for various reasons. That's why I did no longer run for 'commit' access since then. A summary with some cases (some time has passed, maybe my memory is no longer that accurate - but it should give an idea): - patches about parallel building got stuck = result: 3 people (Lluís Batlle, me , Peter) tried different implementations. The first patch was not accepted for no reply is no ok reason - I didn't get a ok due to minor refactoring of make arguments in builder and because some people feared about purity (it would have been opt-in) I messed up hydra that time (due to some -n -j being interpreted as run as much as possible) It was pretty depressing for me because I had need for -j 4 and not getting it into nixpkgs made it impossible for me to use hydra. - patches about cupsd got stuck (due to using versionedDerivation) = fixed printing for me - was later asked on the mailinglist for) - I did mess up python once and did not have time within 5 days or so to fix it - those had to be reverted by Eelco Dolstra - Work on php-fpm was done twice, by me and by somebody else. My version of php-fpm is more complicated but also very complete because it determines how many php-fpm daemons to start on its own. - I eventually had pushed the zsh/bash patches (which I guess are partially obsolete now) - they allow users to opt-out and allow modules/the admin to define bash/zsh snippets to be added to a global bashrc/zshrc which gets sourced by ~/.bashrc so that users can opt-out from everything or pieces. - I would have fixed eigen(2) in krita of calligra much faster = Thus because I have not had commit access this had to be debugged twice. - I have patches pending for apache http and nginx making them more configurable (eg allowing to set the IP to listen to) To sum up: I tend try to apply the 20/80 rule: 20 percent of effort should yield 80% of the desired result - which seems not always to be good enough. Thus in the past I caused both: goodness and badness - thus its fine for me that my commits get reviewed. Thus if PR's don't get accepted I do no longer take it personally - changes end up in my topic branches instead. I treat Nixos to be a very good option to get some jobs done - still seeing much room for improvements. Eg there are 3 implementations: nixpkgs/a js one and guix. Thus moving towards a global package database more distros could derive package descriptions from is much more important to me than caring too much about policies - because I see Nixos to be a tool only to get a job done. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Marc I think it's the general case of more complex PRs. PR that change too much or add too much tend to be delayed. Not only because they are harder to test, but also harder to agree on by more people. Easy PR are in fact faster to be pushed. Increasing the number of committers is certainly good. Of couse, as a committer, it's not that you have to always push your own complex stuff, instead create a PR. You for example you could certainly push commits that in most cases don't affect much people or that you are ready to revert, ecc. ecc. I was never asked for following any rule, except not triggering mass rebuilds, when got commit access. I tend at committing simple stuff that don't break, otherwise still create a PR. Your unfortunate case is that most of your PR are complex or controversial :P offlinehacker has the same problem, he has different needs and obviously want to push those needs. And many others. Also some PR are basically very hard to test for many people. For example testing new kernel options. Or because committers don't have knowledge on every field, and thus resilient to push. Just to say, it's not lack of trust, or being negative. It's lack of time (or platform) for proper testing and lack of time for proper understanding (linux is becoming too giant) the consequences of a change. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Decision Procedures (was: PR [member] label)
The problem about being cheap and yet being thought is because basically we don't have a policy. For example the recent issue about nginx with Restart and RestartSec. What should be the default Restart for our services? RestartSec? Should they wait for network or not? Ecc. I'd ask everybody about taking a breath and think about a kind of policy, or a kind of process for which we set valid defaults in our codebase and never think about it again. Not to be anything bureaucratic, just have some defined default. That would greatly increase the review process for everyone by removing many doubts. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple instances - detecting resource collisions - nixos module system question
Luca Bruno lethalma...@gmail.com writes: On 15/01/2015 01:23, Nicolas Pierron wrote: On Wed, Jan 14, 2015 at 11:17 PM, Marc Weber marco-owe...@gmx.de wrote: If you use multiple apaches/nginx/mysql/postgresql/whatever instances its likely to miss adjusting the port or whatsoever. Therefore I'd like to implement a simple resource tracking module which fails if a resource such as tcp/ip port or socket or such gets used multiple times. This is awesome! This is a mess: 1) A service can bind to multiple ip and ports. So we can just use a list of ports instead of a single one. 2) There's not only tcp. So two lists? UDP and TCP ports. 3) A service could start listening dynamically on other ports at runtime. This is a valid point. An approach like this needs to trust the services not to lie about their list of used ports. This is enough for saying it's going to be too complicated to check for conflicts with little gain and many false positives. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple instances - detecting resource collisions - nixos module system question
Marc Weber marco-owe...@gmx.de writes:
If you use multiple apaches/nginx/mysql/postgresql/whatever instances
its likely to miss adjusting the port or whatsoever. Therefore I'd like
to implement a simple resource tracking module which fails if a
resource such as tcp/ip port or socket or such gets used multiple times.
It should look like this: http://dpaste.com/10RKJSQ
A test like this:
resources.tcp-ports.80 = {};
causes:
The option `resources.tcp-ports.80.allowCollisions' defined in
`/etc/nixos/nixpkgs/nixos/modules/misc/resources.nix' does not exist.
which I don't get because the dpaste sets a default value for
allowCollisions.
Thus does anybody just spot what I'm doing wrong?
If we are at it: Eelco Dolstra proposed services.mysql.services or
such. What about services.mysqls ? We could deprecade services.mysql
then and ask users to switch slowly. No naming collisions. Naming is
short and could be adopted to other services.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
I really like this idea.
Another use that comes to mind is using it to open ports in the firewall
in a declarative manner. E.g.:
firewall.allowedTCPPorts = [
...
] ++ resources.mysql.tcpPorts
++ resources.httpd.tcpPorts;
(Assuming it uses a list of ports as suggested in my other reply.)
Cheers,
Moritz
signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Managing private Nix packages outside the Nixpkgs tree
Hi Eike,
Thanks for your suggestions. I managed to build my own setup, which
works but is a bit bulky by now.
What I do:
* define what vim-plugins I want to use from upstream (list)
* define own vim plugins (list, lets call it ownPlugins)
* Append the lists (lets call it vimPlugins)
* Override vim
* Append all plugins to the runtimepath, which means
* ownPlugins is one package, so just append the
appropriate RTP here
* Append the appropriate path for each non-ownPlugins vim
plugin package to the RTP
* Append vimPlugins list to the systemPackages
* Append my customized vim to the list of systempackages
I don't know whether the idea append to the vim runtimepath is the
thing that slows down vim at startup, but it seems so. It is a
slow machine, thought.
I will post a blog article about my vim setup maybe next week, I'll
notify you as soon as it is online!
On 17-01-2015 18:49:56, Eike wrote:
AFAICS, its enough to specify your own definitions in
`nixpkgs.packageOverrides'. This takes the original package collection
and returns a map with new/overriden packages. I have this setup:
common.nix (imported in all machine configs):
nixpkgs = {
config = {
allowUnfree = true;
packageOverrides = import ./pkgs;
};
};
then ./pkgs/default.nix looks like this:
pkgs:
let
callPackage = pkgs.lib.callPackageWith(pkgs // custom);
custom = {
cdparanoiax = callPackage ./cdparanoiax {};
...other packages...
};
in custom
Looks sane to me.
As far as I can see, your `custom` is a Set here. But
`environment.systemPackages` must be a list, so how do you convert
it into a list?
Since the callPackage function is redefined that way, you can have
dependencies between your own packages. Then each directory in pkgs is a
package definition just like it is done in nixpkgs. I can then add
`pkgs.cdparanoiax' to `environment.systemPackages'.
Awesome! Having dependencies between own packages sounds good to me, I
will try this out! Thanks for pointing out how it works!
--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer
Proudly sent with mutt.
Happily signed with gnupg.
pgptNv6RPLFpj.pgp
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Pascal Wittmann pascalwittm...@gmx.net writes: On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. I totally agree here: Simple version-updates, fixes, (simple) new packages, etc. should go into master/staging without a PR. We can still create pull requests for bigger changes and/or controversial ideas. signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Michael Raskin 7c6f4...@mail.ru writes: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. Many people come and say that. The sad truth is that we lack the resources to do development like that. Whatever the benefits of this approach, we cannot afford the costs. The low observed rate of PR merges means that we need people who do many correct small updates to perform them directly on master for the project to be able to actually accomplish something except the trivial updates. I entirely agree, Michael. As one of the people who commits directly to master, I have to say that if every small change/fix I wanted to make had to go through a PR, I'd contribute much less, simply due to lack of energy. John ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PR [member] label
On 01/18/2015 11:02 PM, Michael Raskin wrote: I propose to add a [member] label to PR labels. This label is to be applied to pull requests that are created by the project committers. This is a great idea! I agree to 100%. signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Decision Procedures (was: PR [member] label)
Hi Michael, I think we all admit that we have a problem with timely merging of pull requests. my impression is that we have a problem with controversial PRs only, because we lack any kind of organized procedure for making decisions as a group. We merge PRs that no-one objects to quickly, really, but once dissent arises the PR is essentially dead in the water unless someone feels real strongly about it and (a) pushes it through regardless or (b) works real hard to generate consensus. My 2 cents, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] pybrowser : remove network tests
The pybrowser expression in nixpkgs fails in a chroot build when some tests
depending on network access fail. The attached patch removes these tests,
fixing the chroot build.
From 5d38070ad808907c3a15f62a6e1ee1f3f0fb4c38 Mon Sep 17 00:00:00 2001
From: Karn Kallio kkal...@skami.org
Date: Sun, 18 Jan 2015 17:56:39 -0430
Subject: [PATCH] pybrowser: fix chroot builds by removing network dependent
tests.
---
.../pybrowser/remove-network-tests.patch | 68 ++
pkgs/top-level/python-packages.nix | 2 +
2 files changed, 70 insertions(+)
create mode 100644 pkgs/development/python-modules/pybrowser/remove-network-tests.patch
diff --git a/pkgs/development/python-modules/pybrowser/remove-network-tests.patch b/pkgs/development/python-modules/pybrowser/remove-network-tests.patch
new file mode 100644
index 000..117e07c
--- /dev/null
+++ b/pkgs/development/python-modules/pybrowser/remove-network-tests.patch
@@ -0,0 +1,68 @@
+diff -Naur pyBrowserID-upstream/browserid/tests/test_verifiers.py pyBrowserID/browserid/tests/test_verifiers.py
+--- pyBrowserID-upstream/browserid/tests/test_verifiers.py 2015-01-18 16:23:23.101657868 -0430
pyBrowserID/browserid/tests/test_verifiers.py 2015-01-18 17:49:03.741138017 -0430
+@@ -126,14 +126,6 @@
+ # There should be a warning about using this verifier.
+ self.assertEquals(w[0].category, FutureWarning)
+
+-def test_error_handling_in_verify_certificate_chain(self):
+-self.assertRaises(ValueError,
+- self.verifier.verify_certificate_chain, [])
+-certs = decode_json_bytes(EXPIRED_ASSERTION)[certificates]
+-certs = [jwt.parse(cert) for cert in certs]
+-self.assertRaises(ExpiredSignatureError,
+- self.verifier.verify_certificate_chain, certs)
+-
+ @callwith(patched_supportdoc_fetching())
+ def test_well_known_doc_with_public_key(self):
+ assertion = make_assertion(t...@m.com, http://e.com;)
+@@ -196,49 +188,6 @@
+ self.assertRaises(AudienceMismatchError, verifier.verify,
+ assertion, audience=example.com)
+
+-
+-class TestRemoteVerifier(unittest.TestCase, VerifierTestCases):
+-
+-def setUp(self):
+-self.verifier = RemoteVerifier([*])
+-
+-@patch('browserid.netutils.requests')
+-def _verify(self, requests, response_text='', assertion=EXPIRED_ASSERTION,
+-status_code=200):
+-response = Mock()
+-response.text = response_text
+-response.status_code = status_code
+-requests.request.return_value = response
+-
+-return self.verifier.verify(assertion)
+-
+-def test_handling_of_valid_response_from_server(self):
+-response_text = ('{email: t...@m.com, status: okay, '
+- 'audience: http://myfavoritebeer.org}')
+-data = self._verify(response_text=response_text)
+-self.assertEquals(data[email], t...@m.com)
+-
+-def test_handling_of_invalid_json_from_server(self):
+-with self.assertRaises(ConnectionError):
+-self._verify(response_text='SERVER RETURNS INVALID JSON')
+-
+-@patch('browserid.netutils.requests')
+-def test_handling_of_incorrect_audience_returned_by_server(self, requests):
+-response_text = ('{email: t...@m.com, status: okay, '
+- 'audience: WRONG}')
+-with self.assertRaises(AudienceMismatchError):
+-self._verify(response_text=response_text)
+-
+-@patch('browserid.netutils.requests')
+-def test_handling_of_500_error_from_server(self, requests):
+-with self.assertRaises(ValueError):
+-self._verify(status_code=500)
+-
+-def test_handling_of_503_error_from_server(self):
+-with self.assertRaises(ConnectionError):
+-self._verify(status_code=503)
+-
+-
+ class TestDummyVerifier(unittest.TestCase, VerifierTestCases):
+
+ def setUp(self):
diff --git a/pkgs/top-level/python-packages.nix b/pkgs/top-level/python-packages.nix
index c907925..1bb8f9f 100644
--- a/pkgs/top-level/python-packages.nix
+++ b/pkgs/top-level/python-packages.nix
@@ -11958,6 +11958,8 @@ let
sha256 = 0nyqb0v8yrkqnrqsh1hlhvzr2pyvkxvkw701p3gpsvk29c0gb5n6;
};
+patches = [ ../development/python-modules/pybrowser/remove-network-tests.patch ];
+
buildInputs = with self; [ mock unittest2 ];
propagatedBuildInputs = with self; [ requests ];
--
2.1.4
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PR [member] label
Some projects have committer sponsorships, where new committers are taken under the wings of long-term members (i.e. Contributors of 3 or more merged PRs) so that they can be trained on the project standards and conventions and have a better chance of getting their PR merged. I'll be happy to help draft/improve PR guidelines, we can chat about it during FOSDEM downtime ;-) On 18 Jan 2015, at 23:02, Michael Raskin 7c6f4...@mail.ru wrote: I propose to add a [member] label to PR labels. This label is to be applied to pull requests that are created by the project committers. Rationale: it is a good idea to look at long-standing non-member PRs. And ideally long-standing means half a week. 1. I think we all admit that we have a problem with timely merging of pull requests. 2. I hope we all agree that we want to attract new committers. A first-time contributor feeling ignored often has no idea what are the chances to get the PR merged or even to get any feedback. There are times when negative feedback is the best reaction; but lack of feedback to the first-time PR submitter is never something we _want_, it just happens. If a long-time member creates a PR, it is a clear signal that quick merge is not seeked; there is a discussion to be had, and if there are no opinons, merging own PRs is always an option. If a fresh committer creates a PR, quick merge may be or may not be a desired outcome; but anyway there is some confidence and some understanding about whom to ping and some other small fixes can be pushed in the meantime. To solve this problem some of the project members try to look at PRs and merge as much as possible. To make this as straightforward as possible we should have a label to filter out PRs not intended for speedy reaction. I think [member] label is a good approximation. It can be applied without thinking, it is convenient to filter by -label:member, I hoped there is a way to just write something like -author:in-team:nixpkgs-committers, but apparently Github doesn't have this and we need to emulate this manually. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
On Sun, Jan 18, 2015 at 07:53:35PM +0100, Moritz Ulrich wrote: Pascal Wittmann pascalwittm...@gmx.net writes: On 01/18/2015 06:19 PM, Nathan Bijnens wrote: While I don't mind that we expand the number of people with commit access, I firmly oppose doing changes directly on master, any change should first be a PR. If there're more people who can close a PR, those PRs will be open for a shorter amount of time. What is the advantage? IMO this would create an enormous overhead. E.g. I just updated abiword from 3.0.0 to 3.0.1 and only changed the version number and hash. Is this worth a pull request? I don't want to merge those pull requests, they only cover the discussion-worthy pull requests. I totally agree here: Simple version-updates, fixes, (simple) new packages, etc. should go into master/staging without a PR. We can still create pull requests for bigger changes and/or controversial ideas. Remember that we use a comfortable VCS, and it is quite easy to take back things if the changes seem not to work well. And they can be reapplied again later if they were doing the right thing, etc. As for me, let the listed contributors commit to master! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
