Re: [Nix-dev] environment.allowedLicenses ?
I also prefer the current approach of meta.license = stdenv.lib.licenses.unfree, in some companies it's not always allowed to use some 'viral' licenses (the opposite case of license.unfree). N. --- nat...@nathan.gs | nathan.gs http://nathan.gs?utm_source=footerutm_medium=emailutm_campaign=n | @nathan_gs http://twitter.com/nathan_gs | linkedin.com/in/nbijnens On Mon, Jan 26, 2015 at 2:19 PM, Matthias Beyer m...@beyermatthias.de wrote: On 26-01-2015 14:00:10, Eelco Dolstra wrote: Hm, I have the impression the license checking code is becoming pretty heavy at this point. For instance, what (realistically) is the use case for whitelisting? Whitelisting a non-free license. Even a basic NixOS system configuration probably has dozens of (free) licenses, and I can't imagine users going to the trouble of specifying them all. Also note that all this license checking is on the mkDerivation critical path, so anything we do there slows down nix-env -qa. Of course things have to be optimized here. I actually think we should *remove* meta.license entirely (because it doesn't provide useful info to users and tends to be wrong or incomplete anyway), and replace it with attributes that have operational meaning: I'm heavily against this. Having the license in the package information is (IMHO) the right way to do this. Removing the license of a package is removing information about the package, which I do not consider a good idea at all. You could remove the maintainer and version, too, if you remove the license. -- 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] environment.allowedLicenses ?
Hi, On 26/01/15 14:19, Matthias Beyer wrote: On 26-01-2015 14:00:10, Eelco Dolstra wrote: Hm, I have the impression the license checking code is becoming pretty heavy at this point. For instance, what (realistically) is the use case for whitelisting? Whitelisting a non-free license. Doesn't that also require whitelisting all free licenses used by a configuration? I actually think we should *remove* meta.license entirely (because it doesn't provide useful info to users and tends to be wrong or incomplete anyway), and replace it with attributes that have operational meaning: I'm heavily against this. Having the license in the package information is (IMHO) the right way to do this. Removing the license of a package is removing information about the package, which I do not consider a good idea at all. You could remove the maintainer and version, too, if you remove the license. Well, those have an actionable meaning (namely, who to contact regarding problems in the package, and whether nix-env -u should consider a package newer). OTOH, most users don't care whether a package is licensed under the 3-clause or 2-clause BSD license. People who do care about the exact license of a package should use a tool like Ninka do extract the actual license, rather than depend on meta.license (since, as I said, it tends to be incomplete or wrong). -- 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
Re: [Nix-dev] postfix - generating alias tables in store and some additional changes
At Mon, 26 Jan 2015 09:29:21 +, Marc Weber wrote: Is anybody interested in these? https://github.com/MarcWeber/nixpkgs/commit/1bb2f95c9ab792422a89c11e1f629dcff2cbf322 marc-nixos/postfix Yes, please. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Pulseaudio broken in 14.12: Daemon already running
Kirill Elagin kirela...@gmail.com writes: Do you use a desktop manager or start your X session manually? The important thing is to make sure that your X server is running on _the same virtual terminal_ your logind session was opened on, otherwise you won’t get permissions to access hardware. Desktop managers take care of this and recent versions of `startx` (starting from xinit-1.3.4 IIRC) also do. `loginctl show-session session-id -p VTNr` tells you what logind thinks is your session’s terminal. I believe that the default of X is still to choose the first available terminal, so you have to explicitly pass it `vtyour-session-terminal-number` (`startx` does exactly this). From what I understand, there's no way to use `startx' with systemd. That's my preference, but I don't know how to configure NixOS to allow that. For DMs, I've tried both slim and lightdm. I have the same pulseaudio issues under both. `loginctl' reports that I have a seat and that my session's terminal is 7. X is also running on VT 7, but it's running as *root*! Could X running as root be the problem here? $ nixos-version 14.12.343.47c741f (Caterpillar) $ X -version X.Org X Server 1.16.2.901 (1.16.3 RC 1) -- Peter Jones, Founder, Devalot.com Defending the honor of good code ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] environment.allowedLicenses ?
I actually think we should *remove* meta.license entirely (because it doesn't provide useful info to users and tends to be wrong or incomplete anyway), and replace it with attributes that have operational meaning: People who do care about the exact license of a package should use a tool like Ninka do extract the actual license, rather than depend on meta.license (since, as I said, it tends to be incomplete or wrong). How do the attributes solve this issue? One can specify an incorrect attribute, no? I don’t see a problem. If a Nix package specifies a wrong license, fix it. If you use a tool like cabal2nix and the problem is upstream, then send a patch upstream. I did this for yesod-markdown, no big deal. pgpnVvU4QOK2j.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] pulseaudio not reading /etc/pulse/default.pa [Was: pulseaudio broken in 14.12: Daemon already running]
Peter Jones mli...@pmade.com writes: Pulseaudio stopped working for me after upgrading to 14.12. It seems that all PA clients start their own server, which eventually fails because the pulseaudio daemon is already running. I believe I've tracked down the root problem. It appears that if you have a ~/.config/pulse/default.pa file then pulseaudio will not read /etc/pulse/default.pa. This wasn't the case in previous versions. Even an empty ~/.config/pulse/default.pa file will prevent pulseaudio from reading the one in /etc and thus it will start with no cards. Sounds like a bug in pulseaudio. -- Peter Jones, Founder, Devalot.com Defending the honor of good code ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Announcing New Ruby Support
I've opened https://github.com/NixOS/nixpkgs/issues/5985 to address documentation regarding this change. PS: we should also migrate redmine to the new infrastructure: https://github.com/NixOS/nixpkgs/issues/5984 On Thu, Jan 22, 2015 at 9:03 AM, Matthias Beyer m...@beyermatthias.de wrote: Hi, On 21-01-2015 23:29:55, Charles Strahan wrote: Hello all, I'm pleased to announce that the Pleasant Ruby PR has landed on master. this is awesome news! The new feature - bundlerEnv - allows one to package Ruby applications with Bundler. To use the new system, first create (or copy over) a Gemfile describing the required gems. Next, create a Gemfile.lock by running `bundler package --no-install` in the containing directory (this also creates two folders - vendor and .bundle - which you'll want to delete before committing). Now, you'll need to dump the lockfile as a Nix expression. To do so, use Bundix in the target directory: A $(nix-build 'nixpkgs' -A bundix)/bin/bundix That will drop a gemset.nix file in your current directory, which describes the sources for all of the gems and their respective SHAs. Finally, you'll need to use bundlerEnv to build the gems. The following example is how we package the sup mail reader: [...] Is there a way to even automat these steps? Ideally (for me as user) would be to be able to nix-env -iA pkgs.rubyGems.insert arbitrary gem and nix figures out everything, including dependencies and so on. I don't know whether this is possible or not, but I guess it would be really cool and also beneficial in manner of packaging/maintaining effort. Anyways, nice to hear that Ruby support gets better! -- 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] parallel make
Hi Michael, I would sometimes [like to] try to build my system with maximum parallel building enabled just to record what breaks this time. yes, it would be great if that were possible. As of today, the only way to enable parallel building for all packages is to override the default for enableParallelBuilding in the generic builder, but if you do that you'll end up with a different stdenv. That is unsatisfactory. If /etc/nix/nix.conf would offer an option to determine the default value of enableParallelBuilding, then we could have the best of both worlds. By default, parallel building would be enabled only for those packages that explicitly request it. For the purposes of testing and development, however, one could flip the switch and have parallel building enabled for all packages that don't explicitly disable it. In other words, users would be able to switch between opt-in and opt-out. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Can recursive attribute sets refer to quoted attributes?
Hi,
consider the following recursive attribute set:
rec
{
foo.bar = test;
}
Is there any way to refer to foo.bar within that set? The obvious
attempt
rec
{
foo.bar = test;
foobar1 = foo.bar; # undefined reference
foobar2 = foo.bar;# doesn't refer too foo.bar
}
won't work.
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] postfix - generating alias tables in store and some additional changes
Is anybody interested in these? https://github.com/MarcWeber/nixpkgs/commit/1bb2f95c9ab792422a89c11e1f629dcff2cbf322 marc-nixos/postfix - use null instead of for some options which means don't set option at all to make it clearer that the option is unset rather than set to which means postfix defaults apply - use default configuration /etc/postfix/main.cf So that sendmail and postfix flush just works and postconf prints correct configuration location and that its no longer necessary to pass configuration location - remove all the impure ln stuff creating untracked files in the conf directory. Instead create .db files in store (TOOD: !take care about passwords!) - replace options extraAliases, postmaster etc by assertions forcing you to think about creating alias table - assemble command dir adding links to sgid wrapped applications correctly TODO: merge with upstream changes If so I'll try to clean up and submit a PR. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Pulseaudio broken in 14.12: Daemon already running
As Benno said this means that most likely something is wrong with your session and you don’t get access to audio devices. What’s strange is that 14.12 uses xorg-server-1.16-* and this should run as user by default and as a result should crash with insufficient permissions to access video devices unless you do something special to start it as root. Do you use a desktop manager or start your X session manually? The important thing is to make sure that your X server is running on _the same virtual terminal_ your logind session was opened on, otherwise you won’t get permissions to access hardware. Desktop managers take care of this and recent versions of `startx` (starting from xinit-1.3.4 IIRC) also do. `loginctl show-session session-id -p VTNr` tells you what logind thinks is your session’s terminal. I believe that the default of X is still to choose the first available terminal, so you have to explicitly pass it `vtyour-session-terminal-number` (`startx` does exactly this). On Mon Jan 26 2015 at 9:32:29 AM Benno Fünfstück benno.fuenfstu...@gmail.com wrote: PulseAudio should get its permissions from systemd logind. You can use loginctl to view of you're properly assigned a seat. Regards, Benno Peter Jones mlists mli...@pmade.com@ mli...@pmade.compmade.com mli...@pmade.com schrieb am So., 25. Jan. 2015 19:40: ___ 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] Can recursive attribute sets refer to quoted attributes?
Hi,
On 26/01/15 10:55, Peter Simons wrote:
consider the following recursive attribute set:
rec
{
foo.bar = test;
}
Is there any way to refer to foo.bar within that set?
No, except by giving the entire set a name, e.g.
let attrs = rec { foo.bar = ...; x = attrs.foo.bar; }; in attrs
--
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
Re: [Nix-dev] Announcing New Ruby Support
Ideally (for me as user) would be to be able to nix-env -iA pkgs.rubyGems.insert arbitrary gem I have some ideas, but I first need to get some patches into Bundler and Rubygems.org. I've opened https://github.com/NixOS/nixpkgs/issues/5985 to address documentation regarding this change. PS: we should also migrate redmine to the new infrastructure: https://github.com/NixOS/nixpkgs/issues/5984 I'll add those to my list. Can't give a time estimate at the moment, I'm afraid. On Mon, Jan 26, 2015 at 5:03 AM, Domen Kožar do...@dev.si wrote: I've opened https://github.com/NixOS/nixpkgs/issues/5985 to address documentation regarding this change. PS: we should also migrate redmine to the new infrastructure: https://github.com/NixOS/nixpkgs/issues/5984 On Thu, Jan 22, 2015 at 9:03 AM, Matthias Beyer m...@beyermatthias.de wrote: Hi, On 21-01-2015 23:29:55, Charles Strahan wrote: Hello all, I'm pleased to announce that the Pleasant Ruby PR has landed on master. this is awesome news! The new feature - bundlerEnv - allows one to package Ruby applications with Bundler. To use the new system, first create (or copy over) a Gemfile describing the required gems. Next, create a Gemfile.lock by running `bundler package --no-install` in the containing directory (this also creates two folders - vendor and .bundle - which you'll want to delete before committing). Now, you'll need to dump the lockfile as a Nix expression. To do so, use Bundix in the target directory: A $(nix-build 'nixpkgs' -A bundix)/bin/bundix That will drop a gemset.nix file in your current directory, which describes the sources for all of the gems and their respective SHAs. Finally, you'll need to use bundlerEnv to build the gems. The following example is how we package the sup mail reader: [...] Is there a way to even automat these steps? Ideally (for me as user) would be to be able to nix-env -iA pkgs.rubyGems.insert arbitrary gem and nix figures out everything, including dependencies and so on. I don't know whether this is possible or not, but I guess it would be really cool and also beneficial in manner of packaging/maintaining effort. Anyways, nice to hear that Ruby support gets better! -- 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
