Re: [Nix-dev] NixPkgs Monitor is down (monitor.nixos.org)
Sweet! I can confirm that Rob is correct and of right now monitor lives. Rob, what's the issue with the updater? Anything we can help fix? Aloha, RK. On Mon, Jul 28, 2014 at 5:40 PM, Rob Vermaas rob.verm...@gmail.com wrote: Monitor site should be up again. Note however, that the updater of monitor is broken for a while already, so it is not uptodate atm. Cheers, Rob On Mon, Jul 28, 2014 at 1:30 AM, Raahul Kumar raahul.ku...@gmail.com wrote: It's still down, it won't even load.I just pinged it and got nothing back. It's dead. On Mon, Jul 28, 2014 at 5:12 AM, Michael R nixos...@webhippo.net wrote: Folks, As far as I can tell monitor.nixos.org has been down for a few days. Any idea why? If anyone willing to share credentials I am happy to look into it. -- michael ___ 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 -- Rob Vermaas [email] rob.verm...@gmail.com ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixPkgs Monitor is down (monitor.nixos.org)
Hi, I am not 100% sure. Phreedom will know more about this. Cheers, Rob On Mon, Jul 28, 2014 at 9:45 AM, Raahul Kumar raahul.ku...@gmail.com wrote: Sweet! I can confirm that Rob is correct and of right now monitor lives. Rob, what's the issue with the updater? Anything we can help fix? Aloha, RK. On Mon, Jul 28, 2014 at 5:40 PM, Rob Vermaas rob.verm...@gmail.com wrote: Monitor site should be up again. Note however, that the updater of monitor is broken for a while already, so it is not uptodate atm. Cheers, Rob On Mon, Jul 28, 2014 at 1:30 AM, Raahul Kumar raahul.ku...@gmail.com wrote: It's still down, it won't even load.I just pinged it and got nothing back. It's dead. On Mon, Jul 28, 2014 at 5:12 AM, Michael R nixos...@webhippo.net wrote: Folks, As far as I can tell monitor.nixos.org has been down for a few days. Any idea why? If anyone willing to share credentials I am happy to look into it. -- michael ___ 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 -- Rob Vermaas [email] rob.verm...@gmail.com -- Rob Vermaas [email] rob.verm...@gmail.com ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] GHC Darwin binaries on Hydra are broken (was: Override package in local default.nix)
Hi Alfredo, Running Haddock for hscolour-1.20.3... Preprocessing library hscolour-1.20.3... haddock: unrecognized option `--package=hscolour-1.20.3' unrecognized option `--verbose' Usage: haddock [OPTION...] file... you are working on Darwin, right? If that's the case, then you've run into https://github.com/NixOS/nixpkgs/issues/2689. Basically, Hydra serves broken GHC binaries on Darwin. The closure comes with an ancient version of Haddock for reasons nobody quite understands. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how does NixOS ensure focus?
On 07/28/2014 03:55 AM, hasufell wrote: However, since I'v seen a lot of things gone wrong in distros (primarily gentoo), I am curious if you have a concept for ensuring that NixOS stays focussed. [...] A lot of projects (some successfully) ensure focus by limiting the number of core developers to the absolute minimum, which means decision-making is pretty easy. At the same time they open up the gates for random collaboration. This implies a well designed review workflow with very responsive and active developers for this to function properly, otherwise people will give up on overcomplicated contribution procedures/channels and do their own thing. I'd pretty much say that the linux kernel runs this model successfully, although reasons for this are probably a bit more complicated. As has been said, there are no hard rules. We still just rely on judgement of those with commit rights and some agreements from before. My view: the kernel model is infeasible for us (ATM). People and even companies use nix(os) to do what they want/need, and their improvements are contributed back (partly?). It's more of a symbiosis of people where each has his/her own focus and aims. Decisions in such a model can become difficult, but fortunately nix(os) is very handy in supporting multiple different solutions independently. Now a few clarifications: On 07/28/2014 05:37 AM, Mathnerd314 wrote: Perhaps this has already started in the form of Guix; they have their own instance of Hydra, their own Guix packages, etc., but still use Nix, the underlying software, basically out of the box. Guix doesn't use the nix *language*, and so they have their own counterpart of nixpkgs. IIRC they write expressions in guile, but generate the same primitive *.drv files, so they share the nix store and the process of building outputs from *.drv derivations. (i.e. the amount of sharing is relatively *very* small) Personally, I consider it the only known real fork of nixos.org stuff (perhaps not in typical sense of fork). NixOS is pretty small now (only 21 people, according to https://github.com/orgs/NixOS/people) so there hasn't been much need to write it down. True, the number of people with lots of contributions aren't high. In the github NixOS organization there are 36 people, actually, as some have selected private membership. (I've got no idea what it's good for, when everyone can see what people commit, but I guess most people didn't notice/care about the choice.) Vlada 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] NixPkgs Monitor is down (monitor.nixos.org)
I'm currently trying to get my dev instance back up. Fixes should follow shortly. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Moving /nix/store to another partition
Hi, List! Looks like I've made not wise choice of locating /nix/store in root (/) partition on my build server. Now all 'no space left on a device' are my friends. Is it possible to relocate /nix/store's contents into /home (located on a much larger partition) without re-installing the entire system? In other words, I want my /nix/store to be a symlink pointing to /home/nix/store. Is it safe to just boot from the CD, move /nix/store to /home and drop the symlink ? Is there a well-known algorithm of solving this administration task? Store symlink management is the main thing I am worrying about. Regards, Sergey PS Currently, mount | grep /dev/sda1 outputs the following: /dev/sda1 on / type ext4 (rw,relatime,data=ordered) /dev/sda1 on /nix/store type ext4 (ro,relatime,data=ordered) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Moving /nix/store to another partition
Sorry, forgot to CC to all. -- Forwarded message -- From: Sergey Mironov grr...@gmail.com Date: 2014-07-28 14:34 GMT+04:00 Subject: Re: [Nix-dev] Moving /nix/store to another partition To: Luca Bruno lethalma...@gmail.com 2014-07-28 13:59 GMT+04:00 Luca Bruno lethalma...@gmail.com: On 28/07/2014 11:54, Sergey Mironov wrote: Relocating means rebuilding everything from scratch. The other possibility is to bind mount /home/nix/store to /nix/store. The problem is that the nix store is needed in initrd. So the bind mount is not easy, you may end up with the system not booting. Interestingly. I didn't think about initrd. In theory, I may try to customize the initrd script to do bind mount (I hope I have HDD driver compiled in kernel). What do you think, will it be sufficient? Should I do the bind mount once again during stage2 ? Regards, Sergey ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fwd: Moving /nix/store to another partition
On 28/07/2014 12:35, Sergey Mironov wrote: Interestingly. I didn't think about initrd. In theory, I may try to customize the initrd script to do bind mount (I hope I have HDD driver compiled in kernel). What do you think, will it be sufficient? Should I do the bind mount once again during stage2 ? Sorry, forget what I said. /nix/store should not be needed in stage1, as it uses busybox. I do something similar in fact :D I've installed nixos in a subdirectory of my existing partition, therefore I bind mount /nixos to /. So you can perfectly do the bind mount of /nix/store. Here's the pull request: https://github.com/NixOS/nixpkgs/pull/3143 The current problem is that stage1 does not know the order of mount. That is, you must mount / first, then bind mount /nix/store. That PR is trying to address this ordering problem. Probably that exact PR inverts the order and that's not what you want. However you can modify it somehow to your needs. I hope Eelco will +1 on setting an explicit order between mounts in the initrd instead of sorting them out magically. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Better support for Ruby
On 26/07/2014 20:43, Charles Strahan wrote: Hi all, There was some recent talk about difficulty with Nix+Ruby http://thread.gmane.org/gmane.linux.distributions.nixos/13381, and from the looks of it, it's been a couple years since the Ruby infrastructure in Nixpkgs was last touched (the `nix' rubygems plugin itself was last released in 2011). I will be using/supporting Ruby in my soon-to-be job (after about 7 months of fantastic funemployment time :D), so it's very important to me that Nix has good ruby/gem/bundler support. As I will be pushing for the production use of NixOS, I'll have quite some skin in the game. Given both my own interests in the success of Ruby on Nix and my experience with Ruby and its packaging, I would like to coordinate development efforts in this area. I would love to hear about particular use cases and any problems with the current setup, and what features you don't care for (that way we aren't limited by legacy design choices). I will soon begin work on an alternative to the old `nix' gem, and I'll see if I can get Bundler working well too. Feel free to further develop this thread, or if you want to quickly hash things out, you can find me on #nixos as cstrahan. I get alerts on my phone when my name is mentioned, so I should be fairly responsive. -Charles ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Excellent timing, I was just recently lamenting the... lacking state of nix+rubygems and documentation on using it. I can't say I have much to add, although something like the haskellPackages hierarchy for gems would certainly be nice to have, if that's on the cards. - B ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Better support for Ruby
Excerpts from Charles Strahan's message of Sat Jul 26 19:43:29 + 2014: Hi all, Well - depends on what you're looking for. nixpkgs-ruby-overlay has been in use by me for a long time and often does a resanobly good job https://nixos.org/wiki/nixpkgs-ruby-overlay There are some minor problems such as you having to download a dump of RubyForge (which I don't update regularly right now). It does not support lockfiles yet - but you could turn lockfiles into that such .nix code. The best thing would creating a mirror and fetching package descriptions on the fly via API on demand - but with defined revision so that results can be reproduced. I started this alternative approach after giving up on the generate .nix files for nixpkgs for both Haskell/ruby. I also tried this for Python, but that time I failed because dependency information on PyPi was weak or dynamic (determined by setup scripts) often. Thus the way to move forward would be creating a global package database which contained all information for everyone. (And also make C/C++ gnome and whatnot folks use it ..) That's my view - it could be incomplete. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Moving /nix/store to another partition
Thanks! I'll try to relocate it this way.
Regards,
Sergey
2014-07-28 14:41 GMT+04:00 Eelco Dolstra eelco.dols...@logicblox.com:
Hi,
On 28/07/14 11:54, Sergey Mironov wrote:
Hi, List! Looks like I've made not wise choice of locating /nix/store
in root (/) partition on my build server. Now all 'no space left on a
device' are my friends. Is it possible to relocate /nix/store's
contents into /home (located on a much larger partition) without
re-installing the entire system? In other words, I want my /nix/store
to be a symlink pointing to /home/nix/store. Is it safe to just boot
from the CD, move /nix/store to /home and drop the symlink ?
/nix/store or /nix cannot be symlinks, but they can be bind mounts. So you can
boot from the CD, move /nix to /home, and add an entry like:
fileSystems./nix =
{ device = /home/nix;
fsType = none;
options = bind;
};
to configuration.nix. Also set the neededForBoot option on the /home
filesystem
to true, otherwise it won't be mounted in stage 1 of the boot, and the bind
mount will fail.
You can then run nixos-install to rebuild the configuration (which shouldn't
take long since the only change was to fileSystems).
You can probably also do this without the CD by: 1) updating configuration.nix
as above; 2) running nixos-rebuild boot; 3) copying /nix to /home/nix; 4)
rebooting.
--
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
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] Better support for Ruby
On Saturday, July 26, 2014 15:43:29 Charles Strahan wrote: Hi all, There was some recent talk about difficulty with Nix+Ruby http://thread.gmane.org/gmane.linux.distributions.nixos/13381, and from the looks of it, it's been a couple years since the Ruby infrastructure in Nixpkgs was last touched (the `nix' rubygems plugin itself was last released in 2011). I will be using/supporting Ruby in my soon-to-be job (after about 7 months of fantastic funemployment time :D), so it's very important to me that Nix has good ruby/gem/bundler support. As I will be pushing for the production use of NixOS, I'll have quite some skin in the game. Given both my own interests in the success of Ruby on Nix and my experience with Ruby and its packaging, I would like to coordinate development efforts in this area. I would love to hear about particular use cases and any problems with the current setup, and what features you don't care for (that way we aren't limited by legacy design choices). I will soon begin work on an alternative to the old `nix' gem, and I'll see if I can get Bundler working well too. There's nothing inherently wrong with the old nix gem if you treat it as a way to quickly generate/update some gem expressions which you might have to fix by hand a bit. Projects tend to keep their gems in a separate file and update them as necessary, so there's already a large overlap with the way bundler and rvm are used in practice. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how does NixOS ensure focus?
Ertugrul Söylemez: Hi there hasufell, NixOS works quite differently. Let me explain the technical part first. Whenever you install NixOS, you're really forking it, and your installation becomes your own distribution. You can then choose to merge some or all changes in the official NixOS channel into yours (you might call this upgrading). That also works the other way around. Contributing to NixOS really means that you make a change to your own distribution and send a patch or pull-request. So unlike other distributions we do not actually have contributors or maintainers in the traditional sense. As far as I can tell, this model is unique. We have a similar concept in gentoo where you can overwrite ebuilds (package definitions) by adding 3rd party repositories called overlays. So you can in fact mix gentoo with funtoo with sabayoon with pentoo, set priorities of those overlays and even force package foo from a specific overlay. However, this usually gives a lot of complicated problems where packages rely on certain behavior or even patches of other packages. Maybe NixOS doesn't have these problems due to it's technical concept, but I find it hard to tell at this stage. In addition, most user overlays have very poor quality (pretty much what arch linux has with AUR) and regularly break non-trivial libraries like SDL for example. I see that as a big problem of decentralized packaging: quality assurance and consistency (consistency in a very low-level sense, as in: packages work with each other). From my experience it doesn't work to randomly review other peoples work and encourage them to more QA etc. There has to be a very strong attraction for people to have their work merged at some point. The concept extends from packaging to application development, deployment and host management. When you want to deploy a service, you write a NixOS module. This is still in your own fork. When the module is useful to others, you send a patch or PR, and everybody else benefits from it. In any case you do not depend on anyone in the NixOS community, you do not have to gain any sort of status before you can get to work. And if your changes are not merged, you don't lose anything. I made my first contribution within about a week of installing NixOS for the first time. I made the change and sent a PR. Now to the community structure: There are official committers to the Nixpkgs repository. We do not have something like an election process. We have forks, and people just implement ideas. When others agree with them, they can help with development. It's just a fork after all. Then the official committers can choose to merge the changes, if they agree with them. If they don't, the project isn't doomed, but can simply continue as a separate fork, and smaller changes can still be exchanged. I don't think this happened in practice yet, but when it does, nothing bad happens. In particular if you want to make a distribution based on NixOS, neither do you have to start from scratch, nor do you have to give up the upstream Nixpkgs. You would just maintain a Nixpkgs fork with your own customisations. NixOS users can even merge your customisations without switching to your distribution or giving up Nixpkgs. And when they're unhappy, they can remove your changes again. In conclusion, our development methodology is very different, so a comparison to Gentoo is difficult or even unfair. My personal opinion is that this is a great model. It gives me freedom and independence and makes it easy for me to contribute and influence the direction NixOS is taking -- not by talking, but by doing stuff. The decentralised nature of our development process allows a small community like ours to be very productive. Forks and branches are not seen as fragmentation, but rather as addons everybody can use. In fact to be honest, after well over 13 years of Linux usage, I never contributed to other distributions, simply because I couldn't be bothered to gain any kind of social status before I'm allowed to do so. Expanding on your story, when I have an idea that I consider great, I just want to do it. I don't want others to get in my way. No elections, no discussions. It's my idea and I want to figure out in a practical setting whether it works. And when it does, I want a short and easy path from my implementation to the official repository. NixOS makes this possible. After half a century we have mostly figured out how to develop software productively, using decentralised methods, forks, branches, merges, etc. Compared to this almost all distributions still use stone-age methodologies. NixOS is a step into the right direction, not only regarding packaging, development and deployment, but also community structure. This sounds great, in a way. However, worst case scenario is that there are so many forks and people working on so different ideas
Re: [Nix-dev] Better support for Ruby
Excerpts from phreedom's message of Mon Jul 28 13:54:21 + 2014: There's nothing inherently wrong with the old nix gem if you treat it as a way No, that time it took runnig a gem command (the very first implmentation) made me look for an alternative. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how does NixOS ensure focus?
On Mon, 28 Jul 2014 14:08:38 + hasufell hasuf...@gentoo.org wrote: Whenever you install NixOS, you're really forking it, and your installation becomes your own distribution. You can then choose to merge some or all changes in the official NixOS channel into yours (you might call this upgrading). That also works the other way around. Contributing to NixOS really means that you make a change to your own distribution and send a patch or pull-request. So unlike other distributions we do not actually have contributors or maintainers in the traditional sense. As far as I can tell, this model is unique. We have a similar concept in gentoo where you can overwrite ebuilds (package definitions) by adding 3rd party repositories called overlays. So you can in fact mix gentoo with funtoo with sabayoon with pentoo, set priorities of those overlays and even force package foo from a specific overlay. However, this usually gives a lot of complicated problems where packages rely on certain behavior or even patches of other packages. Maybe NixOS doesn't have these problems due to it's technical concept, but I find it hard to tell at this stage. This can happen in the form of state (configuration) interactions. For example it's probably a bad idea to run two versions of the same program, when they share a state directory. To prevent this some programs use/allow version-specific state directories. For example I remember seeing directories like ~/.kde3 and ~/.kde4. However versions aren't the only things that affect this. The set of available plugins may, too. What NixOS can do for you here is to ensure that there are no unintended stateless interactions. This includes libraries, programs, stuff you would normally find in /usr/share, etc. In other words, there are no package-level problems. In addition, most user overlays have very poor quality (pretty much what arch linux has with AUR) and regularly break non-trivial libraries like SDL for example. I see that as a big problem of decentralized packaging: quality assurance and consistency (consistency in a very low-level sense, as in: packages work with each other). From my experience it doesn't work to randomly review other peoples work and encourage them to more QA etc. There has to be a very strong attraction for people to have their work merged at some point. This has to be done on the community level. For example everything that eventually makes it into Nixpkgs is reviewed by the committers. I don't think we have any formal standards here, but that may well establish at some point. Of course that doesn't mean that third-party forks don't screw things up. The current NixOS state of the art is that Nixpkgs is a safe choice and for regular operation you don't need extra sources. Forks are usually used to update or add new packages, and then they are merged. What does happen primarily outside of the upstream Nixpkgs is experiments and custom site-specific customisations. This is the normal and accepted way to do it. [...] After half a century we have mostly figured out how to develop software productively, using decentralised methods, forks, branches, merges, etc. Compared to this almost all distributions still use stone-age methodologies. NixOS is a step into the right direction, not only regarding packaging, development and deployment, but also community structure. This sounds great, in a way. However, worst case scenario is that there are so many forks and people working on so different ideas that none of these can compete with up2date distributions and that getting a consistent experience involves a lot of research, manual fiddling and following unofficial tutorials and hacks. I don't want to paint things too black, I'm just saying that it really depends on details and what actually happens, probably even a culture thing. This is a theoretical possibility, but our current workflow and community mindset makes such a scenario unlikely. I'm pretty confident that it will stay this way for the foreseeable future. But I guess I'd have to get involved in order to actually know. You could install NixOS and pick a program that you would like to see in Nixpkgs. Then just add it to your local installation and send a patch/PR to Nixpkgs, just to get a feeling of how it works, both technically and socially. Greets, Ertugrul -- Ertugrul Söylemez ert...@gmx.de ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
