[Nix-dev] Ghc-mod and the new cabal-1.22
Hi all, after an upgrade I hit a new problem with ghc-mod. It seems that ghc-mod can work with cabal-1.22 only if we have ghc-7.10. https://github.com/kazu-yamamoto/ghc-mod/issues/417 https://github.com/kazu-yamamoto/ghc-mod/issues/429 So I decided to lookup for possible solution. --- The first thing that came to my mind was patching cabal to the 1.20 version. So, this was my config.nix before: https://github.com/meditans/settings/blob/master/nix-local/config.nix This a dummy version that I wrote after ttuegel's advices on #nixos: https://gist.github.com/meditans/a804a00713bd28996cc5 The problem with this approach (other than the lack of binary cache, which is annoying because I run nixOS in a VM, and compilation is slow) was essentially this installation error I was not able to solve: http://lpaste.net/118812 --- So, for the next approach, I upgraded to haskellng as advised by Peter's posts in the mailing list, and then to ghc 7.10. The problem with this approach is that many libraries I'm using are not ready to be compiled with 7.10, for constraints in versions (example: fgl with the constraint for base). --- The last thing I tried was to use ghc-mod without a cabal file, because I know that ghc-mod works outside of cabal projects. The problem with not recognizing modules rendered this path pretty useless soon. --- So, I have some questions. The first is (no surprise here): - How do you suggest to create an environment that works with ghc-mod (and, added bonus, has a binary cache?). How are you using ghc-mod right now (I mean, with an updated nixos-unstable)? And then, keeping in mind that ghc-mod is, after haskell-mode, the only ide plugin immediately avaiable on nixos for haskell development (Chris Done's tools do not compile), the second question: - Could it be worth to downgrade the cabal to 1.20 as before, until the new version of the compiler stabilizes to the new version? I'm curious to hear your ideas here. Best regards Carlo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskellng ghc 7.10 attribute name
Never mind this question, please. The correct answer was: haskellngPackages.packages.ghcHEAD.ghcWithPackages Bad reading from my part. Thanks to Oliver Charles for pointing out. Best regards Carlo 2015-01-19 22:04 GMT+01:00 Carlo Nucera medit...@gmail.com: Hi all, I'm running nixos unstable, and, to be able to use ghc-mod with the new cabal 1.22 I decided to switch to ghc 7.10. So, I made the transition to haskell ng, and changed the attribute names to not need the old naming conventions. So, I'm trying to change this line posted by Peter self.haskell-ng.packages.ghc763.ghcWithPackages In an attribute path to use with nixos unstable. However, here's what I get with my tries: - with ghcHEAD I get: attribute ‘haskellngPackages.ghcHEAD.ghcWithPackages’ missing - with ghc7101 I get: attribute ‘haskellngPackages.ghc7101.ghcWithPackages’ missing What should I use in nixos-unstable? Best Regards Carlo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)
Well, I will speak for myself: 1 - Particularly I need to learn a lot about Nixpkgs culture. I really like it, but when the thing is easy as a GNU Hello package, I just use NixOS Monitor to updatetest. My biggest contribution was, until now, mpv player and maybe Altcoins (alas, I need to update and search for more of them!). 2 - I am seriously studying to port Mate-Desktop and Trinity Desktop, two huge and confused projects to me. I am doing some hacking here and there, and when they became stable, I will do a huge and serious pull-request! :) 3 - Well, if I can be useful, just talk to me and I will do my best! 2015-01-19 20:11 GMT-02:00 Nikolay Amiantov a...@fmap.me: Doesn't that usually apply to big things that most people skip reviewing due to contributor's good standing and tl;dr (though it shouldn't be like this, too... '^_^)? On 01/20/2015 01:02 AM, Matthias Beyer wrote: On 20-01-2015 01:00:30, Michael Raskin wrote: Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they can focus on more non-trivial things. What keeps you from having a version-bumping branch where all your patches are in and open just one PR for all the patches at once? Pity towards me, who will read a PR of unrelated changes and wonder what saced animal have I crossed in my previous life? Have you ever looked how kernel maintainers do their work? For example greg-kh with his staging-next branch? Do you think someone actually goes through these patches except gregkh himself? ;-) -- Nikolay. ___ 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] Commit access request (Again: Why don't these people have commit access)
I guess I should use this opportunity to ask for commit access! I have been reluctant in the past to ask since I'm somewhat young contributor and even if it wouldn't be the case I still usually want to be sure that I did everything right though PR review. Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they can focus on more non-trivial things. Thanks for consideration! On 01/18/2015 06:03 PM, Michael Raskin wrote: As usual, this is my list of people with a lot of NixPkgs master commits, recent accepted Pull Requests and no commit rights. These are github usernames. I remind everyone, that even with smaller track record than that (I mention those with 50 commits) ikwildrpepper (on IRC; Rob Vermaas otherwise) will likely give commit rights if asked. For some of the things I use I don't even try to get inclusion; but still, there are a lot of fixes we all need and write where usefulness is uncontroversial, so not everything has a reason to go through pull requests. abbradar aforemny AndersonTorres ehmry grwlf iyzsong MarcWeber matejc -- Nikolay (@abbradar on GitHub). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Commit access request (Again: Why don't these people have commit access)
On 20-01-2015 00:46:11, Nikolay Amiantov wrote: Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they can focus on more non-trivial things. What keeps you from having a version-bumping branch where all your patches are in and open just one PR for all the patches at once? -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpJb27hbnTdw.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] Commit access request (Again: Why don't these peoplehave commit access)
I guess we should encourage merge fast policy for PRs like that, though from my experience it is already the case -- if it's just a version bump of a package which wouldn't trigger a libreoffice build or so (though libreoffice depends on everything so it's a bad metric ^_^), it usually would be merged quickly. On 01/20/2015 12:51 AM, Michael Raskin wrote: usual, to bother less contributors so that they can focus on more non-trivial things. (pessimistically) or at least on another set of trivial but useful things! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Commit access request (Again: Why don't these people have commit access)
For this kind of thing the contributor involvement is mostly mechanical and (as I imagine) just requires someone going though all PRs, checking if Travis succeeds and the change is really trivial and merging them en masse. This happens from time to time, but using commit access for this if possible is a better thing in my opinion, since it lessens the number of such (obviously boring) work for maintainers. On 01/20/2015 12:54 AM, Matthias Beyer wrote: On 20-01-2015 00:46:11, Nikolay Amiantov wrote: Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they can focus on more non-trivial things. What keeps you from having a version-bumping branch where all your patches are in and open just one PR for all the patches at once? -- Nikolay. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Commit access request (Again: Why don't these peoplehave commit access)
Doesn't that usually apply to big things that most people skip reviewing due to contributor's good standing and tl;dr (though it shouldn't be like this, too... '^_^)? On 01/20/2015 01:02 AM, Matthias Beyer wrote: On 20-01-2015 01:00:30, Michael Raskin wrote: Nevertheless I want to go though my packages and do version bumps in the near future, and I believe this (and things like grammar fixes) is kind of patches that should be applied more directly than usual, to bother less contributors so that they can focus on more non-trivial things. What keeps you from having a version-bumping branch where all your patches are in and open just one PR for all the patches at once? Pity towards me, who will read a PR of unrelated changes and wonder what saced animal have I crossed in my previous life? Have you ever looked how kernel maintainers do their work? For example greg-kh with his staging-next branch? Do you think someone actually goes through these patches except gregkh himself? ;-) -- Nikolay. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: ghc-mod fail errors: bug: gmeioException
Hi Alan, I did a `cabal clean cabal configure`, then a `cabal clean cabal configure cabal build`, and just to be sure I reinstalled all my haskell environment. The package gets installed in ghcWithPackages, but I still have that error inside emacs with ghc-mod. Is there anything else I could try? Best regards Carlo 2015-01-19 5:30 GMT+01:00 Alan Kim Zimmerman alan.z...@gmail.com: 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] Multiple instances - detecting resource collisions - nixos module system question
On 19/01/2015 10:24, Domen Kožar wrote: This could not be PITA if systemd would have the ability to white list ports for a process (or with network namespaces). It would add a burdon to maintainers of nixos modules. But since we don't have system support, I think it's overall better to avoid further complications. There are a bunch of cases where this thing is going to fail theoretically. It's incomplete in every sense. At least if this is merged, don't enable by default. ___ 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 peopl Well - I did take care - I added the new cups version as opt-in. It was your choice. You were free to keep using the old one. I think history is history.. we should talk about the future which also might affect guix (http://www.gnu.org/software/guix/) In the Vim community people leave over and over again because patches don't get accepted or are not taken care of. Just about 2 days ago there was another case. I think that being able to use nixos as desktop system (which implies being able to print) should be a high priority. We also have a new situation compared to back in the old SVN days: _We have releases_ Thus breaking stuff is still bad, but maybe less bad than before. The problem is: We all need stable systems - thus if everybody uses the stable systems nobody is going to use the less stable - thus less testing will happen. But let's talk about a specific case: My patches to apache httpd module: https://github.com/MarcWeber/nixpkgs/commit/7cdeb3f63ee1e26b6113754995284c56257ef162 The apache one breaks the API because I don't want to mess with port stuff (to not mess with .htaccess) so I just created my own loopback device .. Figuring out how to patch this in a backward compatible way was something I could not afford. My current situation is that I update my system only once every couple of weeks because I cannot afford recompiling everything over and over again. 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. Well - NSA cases and the one fosdem video (what would I do If I had one million $ and if it was my task to compromise the world ..) was fun to watch: http://video.fosdem.org/2014/Janson/Sunday//NSA_operation_ORCHESTRA_Annual_Status_Report.webm Thus to truly improve you also have to start measuring who reviewed commits to maximize value by spent time - and that not only for nixpkgs but also for projects like openssh. There is no way to ensure that an update will not cause a random failure on hardware X which will happen only once a month. One huge benefit from having commit access would be that experimental or complicated stuff could be submitted as topic cranch to increase visibility and that other people can join such effort and help taking it to a level where it can be merged. I love topic branches because they use two files: .topmsg = The commit message which would be created when all commits got collapsed. The nice thing is that each branch documents its purpose on its own. .topdeps A list of other branches it depends on Then there is a tg update command to merge with all dependencies and a tg export command to collapse in order to yield a nice commit which can be reviewed more easily. The wiki contains a longer introduction. I don't say topgit must be used. But I highly recommend having such topic specific file documenting the purpose of a branch That's another story: do we want many official experimental topic branches? Making experimental branches visible to others would improve collaboration a lot. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Request for commit access to nixpkgs
Hi, I want to get commit access to nixpkgs. I got my first PR merged about 2 years ago, since then, I continute makeing exprs for packages, and really enjoyed. Thanks! ___ 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
On 19/01/2015 03:44, Shea Levy wrote: My prediction: This will cause more headaches than it will save. Double quote. ___ 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
This could not be PITA if systemd would have the ability to white list ports for a process (or with network namespaces). It would add a burdon to maintainers of nixos modules. On Mon, Jan 19, 2015 at 10:08 AM, Luca Bruno lethalma...@gmail.com wrote: On 19/01/2015 03:44, Shea Levy wrote: My prediction: This will cause more headaches than it will save. Double quote. ___ 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] Managing private Nix packages outside the Nixpkgs tree
Hi,
Sorry for my late answer. I was a bit busy the last few days. Looks like
Elke's suggestion leads you in the right way. Anyway, if you want to refer
to a custom package registry from a NixOS configuration, you could simply
write a config like this:
{pkgs, ...}:
let
customPkgs = import /home/sander/custom-packages.nix {};
{
boot.loader.grub =
services.openssh.enable = true;
environment.systemPackages = [
customPkgs.mc
];
}
The above NixOS configuration uses the mc package from my private custom
Nix expression, as shown in the blog post.
On Sun, Jan 18, 2015 at 12:17 PM, Matthias Beyer m...@beyermatthias.de
wrote:
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.
___
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] Fwd: ghc-mod fail errors: bug: gmeioException
I know that outside of nix I resolved this by doing a fresh cabal install cabal-install. Basically the dist/config binary file is brittle, and has to be read with exactly the same version that wrote it. So the Cabal library used in cabal and the one in ghc-mod must be identical, because ghc-mod tries to read it, and under certain circumstances will do a configure, so it must be readable by the normal cabal process too. Alan On Mon, Jan 19, 2015 at 6:20 PM, Carlo Nucera medit...@gmail.com wrote: Hi Alan, I did a `cabal clean cabal configure`, then a `cabal clean cabal configure cabal build`, and just to be sure I reinstalled all my haskell environment. The package gets installed in ghcWithPackages, but I still have that error inside emacs with ghc-mod. Is there anything else I could try? Best regards Carlo 2015-01-19 5:30 GMT+01:00 Alan Kim Zimmerman alan.z...@gmail.com: 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 ___ 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
(Slight topic digression: parallel make.) On 01/19/2015 06:59 AM, Michael Raskin wrote: This is also the reason why we have no idea which of the packages are safe to build in parallel except for the few packages where someone explicitly tried. Perhaps I don't understand you, but hydra.nixos.org seems quite successful in finding underspecified makefile dependencies. Vladimir smime.p7s Description: S/MIME Cryptographic 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/19/2015 07:17 PM, Michael Raskin wrote: To find out if a makefile is parallel-safe, we need to try it with parallel building enabled. This can only be done package-per-package, [...] I see. What I said is only true for packages with enableParallelBuilding = true; Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] haskellng ghc 7.10 attribute name
Hi all, I'm running nixos unstable, and, to be able to use ghc-mod with the new cabal 1.22 I decided to switch to ghc 7.10. So, I made the transition to haskell ng, and changed the attribute names to not need the old naming conventions. So, I'm trying to change this line posted by Peter self.haskell-ng.packages.ghc763.ghcWithPackages In an attribute path to use with nixos unstable. However, here's what I get with my tries: - with ghcHEAD I get: attribute ‘haskellngPackages.ghcHEAD.ghcWithPackages’ missing - with ghc7101 I get: attribute ‘haskellngPackages.ghc7101.ghcWithPackages’ missing What should I use in nixos-unstable? Best Regards Carlo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Decision Procedures
On 01/19/2015 09:58 PM, Michael Raskin wrote: Travis is not a good fit to us, as it times out all the time. It's a pity. Yes, for large changes it doesn't work because of limits. hydra.nixos.org is under our administration, so it would be better to run tests in there, but now it's certainly better than without any automated PR builds. I am not sure initial policies for staging are still in effect... I believe we should follow them. Sometimes people forget, etc., but for people developing atop master it's good to keep mass-rebuild changes elsewhere (before finishing the rebuild), and for safe or tested changes it's convenient to push them into a single branch. Vladimir smime.p7s Description: S/MIME Cryptographic 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 20-01-2015 00:10:29, Michael Raskin wrote: * One (or two, or three,... but ideally just one) maintainers have the responsibility that the new-packages branch actually _builds_ and should never commit broken packages onto it. If they fail with this, they are bad. Period. You ask for a strong committment for keeping an eye on a huge stream of changes. How many maintainers a year do you plan to expend this way? Well, that's my point of having not only one person doing it. Anyways, it would be best if only one person would maintain the new-packages-branch, as this simplifies a lot of stuff. Anyways, I don't say that only one person should review the patches, of course! And of course it is committment, but so is everything in developing a distro or software, I guess! On the huge stream of changes part: Is it actually that much already? How many packages are there per week, for example? I don't think it is _that_ much, ... For example, there are currently 25 PRs on github with the tag new-package, only 10 of them from the last 10 days! It is really not that much! -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpD7BLgf2zzr.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] Decision Procedures
On Mon, Jan 19, 2015 at 9:58 PM, Michael Raskin 7c6f4...@mail.ru wrote: We did already some helpful steps (travis for PRs, staging and release branches, ...), but we probably need some more. Travis is not a good fit to us, as it times out all the time. It's a pity. I am not sure initial policies for staging are still in effect... For *you*, I pushed a lot of PR thanks to the travis task. ___ 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'm under the impression that none of the proposal inspired by outside project seem to fit NixOS, because NixOS is a very different project : it is a huge and complex linux distro. The first consequence is that it is impossible to have expert on each part on NixOS, because each tiny part requires a specific expertise. To work on python packaging, you have to be a python developer, to work on kde packaging, you have to be involved in the kde community, and to work on libreoffice packaging you have to be knowledgeable on how libreoffice is built (and very patient). I reckon you'll find much people who are confident enough to review a change on a specific part on NixOS than you'd find in another project. Secondly, the scope of the project is so huge that checking nothing is broken takes forever. I most projects, you expect contributors to run the tests and make sure nothing breaks, but in NixOS, that's much harder. We make travis timeout, and we do not have enough resources to build a tight CI that tests every pull request before merging it. Finally, even the definition of broken is more blurry than in other projets. We usually have a few hundreds failing evaluation in hydra, and the number is quite stable (much fewer than we used to have before the ZHF project, though). Those failures might be linked to unexpected side effects of commits, changes in outside world (a tarball has moved) or any kind of transient failure. It is not possible, as of now, to declare that nothing must break. I fell that any proposal would have to take those points into account to fit NixOS. Sadly, I do not have proposal, except maybe to find a rich benefactor and throw a lot of money at hydra. Georges Dubus 2015-01-19 22:00 GMT+01:00 Matthias Beyer m...@beyermatthias.de: On 19-01-2015 10:15:16, stewart mackenzie wrote: I request that we come up with a detailed and carefully thought out contribution guideline which evolves and grows. I guess that would be the best idea, but I'm just a Users voice if you want to name it this way. So, be careful, Users voice ahead! Generally, I think it would be best to prevent commit access as far as possible. Having more people to be able to commit to master results in many different opinions committing to master, which therefor results in discussions, eventually flamewars and everything. Keeping commit access for only a few people does not mean that things get slower, no way! For example there is the issue with trivial patches discussed in this thread. Trivial patches are generally patches which should go into master as fast as possible, I fully agree with that. New packages may be the same, you want them to be in master as fast as possible. But at some point you have to balance between speed of development and maintaining efforts. It has absolutely _no_ benefit if a trivial patch gets pushed onto master whereas one or two other revert them shortly afterwards because they do not agree. This is software development, not pingpong! What you maybe want, at least from my point of view, is staging branches. Some kind of a hierarchy of maintainers, as you have in the linux kernel. I fully understand that the linux kernel is a _way_ more complex system as nixos/nixpkgs, no discussion here. But if you'd split up responsibilities, you may end up with * A fast _and_ secure development model, as people don't revert back and forth. * Fewer wars because people disagree on things * Less maintaining efforts, because the effort is basically split up in several small problems, which are faster to solve. What I want to say is, basically, you want a well-defined and structured way of how to do things. The costs may be that your development gets a bit slower but you have the benefit that if things break you don't start yelling at eachother (I assume you don't do this, but lets put it this way) because certain people disagree on certain topics. My proposal: Responsibilities should be defined. For me, as simple package contributor, I want to have _one_ place/person/branch/ML/whatever where I can ask questions and contribute packages to, leaving the official NixOS github repo completely alone! I, personally, would even be fine with sending git-patches per mail to a ML where it gets reviewed (, maybe build by a daemon, tried to be merged into a nixpkgs/pkgs-branch) and afterwards committed onto a package-branch of a maintainer, which requests a merge into the master branch every now and then. This workflow would have several benefits: * Less merge noise in the repo * Less PR noise on github * One (or two, or three,... but ideally just one) maintainers have the responsibility that the new-packages branch actually _builds_ and should never commit broken packages onto it. If they fail with this, they are bad. Period. * If you do this on a dedicated ML you have less noise here and also
[Nix-dev] Fwd: Re: Decision Procedures
I have also had Travis fail for dubious reasons, even with small changes On Jan 19, 2015 1:25 PM, Luca Bruno lethalma...@gmail.com wrote: On Mon, Jan 19, 2015 at 9:58 PM, Michael Raskin 7c6f4...@mail.ru wrote: We did already some helpful steps (travis for PRs, staging and release branches, ...), but we probably need some more. Travis is not a good fit to us, as it times out all the time. It's a pity. I am not sure initial policies for staging are still in effect... For *you*, I pushed a lot of PR thanks to the travis task. ___ 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] Decision Procedures
On 19-01-2015 23:58:19, Michael Raskin wrote: We did already some helpful steps (travis for PRs, staging and release branches, ...), but we probably need some more. Travis is not a good fit to us, as it times out all the time. It's a pity. Just let me mention drone[0]! I started developing a lib back in September with some folks at my university and we used travis. It was slow as hell and everything, so we switched to drone (which was still beta back then, don't know what it is right now, though) and it was SO DAMN FAST. We had jobs in travis which took 20 minutes because it was always scheduled (and installed dependencies all the time). Equal complex jobs in drone took about 7 seconds or something. I don't know how much it fits for NixOS, though. And, of course, there is hydra. [0]: drone.io -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpz68goqsPla.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
On 19-01-2015 22:26:00, Georges Dubus wrote: I'm under the impression that none of the proposal inspired by outside project seem to fit NixOS, because NixOS is a very different project : it is a huge and complex linux distro. The first consequence is that it is impossible to have expert on each part on NixOS, because each tiny part requires a specific expertise. To work on python packaging, you have to be a python developer, to work on kde packaging, you have to be involved in the kde community, and to work on libreoffice packaging you have to be knowledgeable on how libreoffice is built (and very patient). I reckon you'll find much people who are confident enough to review a change on a specific part on NixOS than you'd find in another project. That's indeed a problem I've not thought about yet. I see that NixOS is a complex distro and I see that we are short in man power, so I guess my proposal does not fit that well. Secondly, the scope of the project is so huge that checking nothing is broken takes forever. I most projects, you expect contributors to run the tests and make sure nothing breaks, but in NixOS, that's much harder. We make travis timeout, and we do not have enough resources to build a tight CI that tests every pull request before merging it. My point on this part was not that nothing breaks, but that no new packages break. Or at least no trivial new packages. For example, I just packaged ctodo, which is almost dependency-less. These kind of stuff really should not break and I guess it is fairly secure to (kind of) out source that from github, as it generates noise in the repo. Finally, even the definition of broken is more blurry than in other projets. We usually have a few hundreds failing evaluation in hydra, and the number is quite stable (much fewer than we used to have before the ZHF project, though). Those failures might be linked to unexpected side effects of commits, changes in outside world (a tarball has moved) or any kind of transient failure. It is not possible, as of now, to declare that nothing must break. Again, this was not the point. The point was that nothing _new_ breaks. Beeing imperfect is not desired (of course it would be ideal), but getting better is desired. That's a small but important difference, I think. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpci1WcDSOa2.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
On 20-01-2015 00:34:22, Michael Raskin wrote: On the huge stream of changes part: Is it actually that much already? How many packages are there per week, for example? I don't think it is _that_ much, ... For example, there are currently 25 PRs on github with the tag new-package, only 10 of them from the last 10 days! It is really not that much! I am not sure all PRs are tagged properly... I'm sure there are PRs around which are not tagged properly, of course. That was just to get a rough idea of the number! Also, where do version bumps go? Good question. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgp0M8jKf13DL.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
On 19-01-2015 10:15:16, stewart mackenzie wrote: I request that we come up with a detailed and carefully thought out contribution guideline which evolves and grows. I guess that would be the best idea, but I'm just a Users voice if you want to name it this way. So, be careful, Users voice ahead! Generally, I think it would be best to prevent commit access as far as possible. Having more people to be able to commit to master results in many different opinions committing to master, which therefor results in discussions, eventually flamewars and everything. Keeping commit access for only a few people does not mean that things get slower, no way! For example there is the issue with trivial patches discussed in this thread. Trivial patches are generally patches which should go into master as fast as possible, I fully agree with that. New packages may be the same, you want them to be in master as fast as possible. But at some point you have to balance between speed of development and maintaining efforts. It has absolutely _no_ benefit if a trivial patch gets pushed onto master whereas one or two other revert them shortly afterwards because they do not agree. This is software development, not pingpong! What you maybe want, at least from my point of view, is staging branches. Some kind of a hierarchy of maintainers, as you have in the linux kernel. I fully understand that the linux kernel is a _way_ more complex system as nixos/nixpkgs, no discussion here. But if you'd split up responsibilities, you may end up with * A fast _and_ secure development model, as people don't revert back and forth. * Fewer wars because people disagree on things * Less maintaining efforts, because the effort is basically split up in several small problems, which are faster to solve. What I want to say is, basically, you want a well-defined and structured way of how to do things. The costs may be that your development gets a bit slower but you have the benefit that if things break you don't start yelling at eachother (I assume you don't do this, but lets put it this way) because certain people disagree on certain topics. My proposal: Responsibilities should be defined. For me, as simple package contributor, I want to have _one_ place/person/branch/ML/whatever where I can ask questions and contribute packages to, leaving the official NixOS github repo completely alone! I, personally, would even be fine with sending git-patches per mail to a ML where it gets reviewed (, maybe build by a daemon, tried to be merged into a nixpkgs/pkgs-branch) and afterwards committed onto a package-branch of a maintainer, which requests a merge into the master branch every now and then. This workflow would have several benefits: * Less merge noise in the repo * Less PR noise on github * One (or two, or three,... but ideally just one) maintainers have the responsibility that the new-packages branch actually _builds_ and should never commit broken packages onto it. If they fail with this, they are bad. Period. * If you do this on a dedicated ML you have less noise here and also a topic-ML, where only packages are reviewed. This also enables new contributors to collaborate with other package-contributors which is an advantage as they actually can help eachother. * If, on a merge, people disagree, patches can simply be reverted _on that topic branch_, resulting in absolutely _no_ merge noise, PR noise or anything. --- Please note, I'm relatively new to NixOS and the community and if _anything_ of the said pisses you of in _any_ way: It wasn't meant to do so and I'd really like to hear your arguments! If anything I said makes you think that it's written in an angry way or something, it is not, it's certainly just my bad english. I just want to state my point and my oppinions here. -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgp3UnR1LBpF0.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
