Re: [Nix-dev] How to override/replace part of a service definition?
Hi Michael,
On Sun, Feb 22, 2015 at 2:45 PM, Michael Alan Dorman mdor...@jaunder.io wrote:
All the documentation I can find about overriding things seems focuses
on packages, but what I'm interested in overriding is the systemd
pre-start-script. I tried what seemed obvious:
{ config, ... }:
let
cfg = config.services.couchdb;
in {
systemd.services.couchdb.preStart =
''
[…]
'';
}
But that appears to have had an *additive* effect---that is, a copy of
the modified text appears *after* the existing, non-working, definition.
First, you can double check the content of this option without
building a system, with
$ nixos-option systemd.services.couchdb.preStart
The *additive* effect is a feature, which is used in many cases, such
as defining fileSystems, systemd.services, and many more. This
gives the ability to have a module system where multiple modules can
register them-self concurrently in other modules.
You can override other modules definitions, almost as you expected, by
using mkOverride int value, which has a convenient short-cut
named mkForce value, with the force int-priority.
This way, you mention that one definition override all the others, as
thus ignore all the definitions with a default priority. These
properties are briefly described in the Manual [1], and in the Wiki
[2].
[1]
https://nixos.org/nixos/manual/sec-writing-modules.html#sec-option-definitions
[2] https://nixos.org/wiki/NixOS:Modules
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
Could we agree than that using throw with a custom message is better than marking the build as broken? Also, I've seen that throw does propagate. The package is disabled if it depends on another package. The TODO would be for hydra to filter out some error messages. On Tue, Feb 24, 2015 at 8:45 PM, Vladimír Čunát vcu...@gmail.com wrote: On 02/24/2015 04:44 PM, Vladimír Čunát wrote: On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. Oh, I've let you mislead me (and my memory just returned): meta.broken is implemented via throw run as an assertion in stdenv.mkDerivation evaluation. See nixpkgs/pkgs/stdenv/generic/default.nix for the implementation. Therefore, it certainly should get propagated whenever anything from the derivation is used (even just name or meta stuff). If we need another semantically distinct option, like meta.disabled, it will be easy to implement in the same way. However, for any throw-based solutions, Hydra just outputs the error thrown, so we that's a point where it should get more clever. Perhaps we could be having some tags at the start of the string, such as Broken: or Disabled:, so Hydra or anyone could easily filter the throws and keep only the ones interesting in the particular use case. Vladimir ___ 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] Automatic download option for requireFile
On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát vcu...@gmail.com wrote: On 02/24/2015 12:02 PM, Harald van Dijk wrote: If you just want to _use_ the software, not modify it, not re-distribute it, then for a whole lot of packages, you do not have to accept the license. I meant that in any case you're required to conform to the license terms (whether that means some act of accepting it or not). Which raise a good point, what does allowUnfree = true; means. Does that mean that you read the licenses of all software, and that you do *agree with all* of them? Should we do something like allowLicenses = [ pkgs.licenses.adobeEULA ]; instead? -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On 02/24/2015 04:44 PM, Vladimír Čunát wrote: On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. Oh, I've let you mislead me (and my memory just returned): meta.broken is implemented via throw run as an assertion in stdenv.mkDerivation evaluation. See nixpkgs/pkgs/stdenv/generic/default.nix for the implementation. Therefore, it certainly should get propagated whenever anything from the derivation is used (even just name or meta stuff). If we need another semantically distinct option, like meta.disabled, it will be easy to implement in the same way. However, for any throw-based solutions, Hydra just outputs the error thrown, so we that's a point where it should get more clever. Perhaps we could be having some tags at the start of the string, such as Broken: or Disabled:, so Hydra or anyone could easily filter the throws and keep only the ones interesting in the particular use case. 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] Automatic download option for requireFile
On 02/23/2015 05:40 PM, Thomas Strobel wrote: So, how should we deal with software that can be downloaded freely, but where the user has to accept a certain license? Is the nixpkgs option config.allowUnfree = true; meant exactly for that cases? Well, you *always* have to accept the license for any package. Free ones are accepted automatically, and for others you have allowUnfree and friends (even general allowUnfreePredicate). FWIW, I'm fairly strongly against inclusion of any package that cannot be installed automatically, i.e., anything that uses requireFile. The reason being that if a package shows up in nix-env -qa, then nix-env -i package should Just Work. I personally do try to avoid unfree packages (or worse, non-redistributable/requireFile ones). They bring less benefit in nixpkgs than free ones, but note that in default installation they will *not* be shown by nix-env -qa (unless the user sets allowUnfree*). 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] Permission error when installing mpd
On 02/19/2015 11:00 PM, joach...@fastmail.fm wrote:
systemd.services.mpd.serviceConfig = { PermissionsStartOnly =
true; };
That is neat! Thank your for it :-)
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] Automatic download option for requireFile
On 02/24/2015 12:02 PM, Harald van Dijk wrote: If you just want to _use_ the software, not modify it, not re-distribute it, then for a whole lot of packages, you do not have to accept the license. I'm no lawyer - it's probably an imprecise formulation on my side: I meant that in any case you're required to conform to the license terms (whether that means some act of accepting it or not). It will typically not restrict the user in any way - in case of free licenses, there's the ideal state that using the SW via nix can't violate the licensing AFAIK, and that might be so even for many unfree redistributable stuff. 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] Alwyas remove icon-them.cache?
Pushed to staging. On Mon, Feb 23, 2015 at 9:21 PM, Bjørn Forsman bjorn.fors...@gmail.com wrote: On 23 February 2015 at 21:18, Luca Bruno lethalma...@gmail.com wrote: Yes we can commit that stuff separately, but must go to staging because it's a big rebuild of many apps. Agreed. -- NixOS Linux http://nixos.org ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [haskell NG] Override package
Hello,
I've done successfully using method 1) .
Thanks.
~~~
~/hdevtools $ cabal2nix . default.nix
~/ $ cat ~/.nixpkgs/config.nix
{
allowUnfree = true;
haskellPackageOverrides = self: super: {
hdevtools = self.callPackage ../hdevtools {};
};
}
~/cis194 $ cat shell.nix
with (import nixpkgs {}).pkgs;
let pkg = haskellngPackages.callPackage
({ mkDerivation, base, MissingH, QuickCheck, stdenv, tasty
, tasty-hunit, tasty-quickcheck, tasty-rerun, tasty-th
}:
mkDerivation {
pname = cis194;
version = 0.1.0.0;
src = ./.;
isLibrary = false;
isExecutable = true;
buildDepends = [
base MissingH QuickCheck tasty tasty-hunit tasty-quickcheck
tasty-rerun tasty-th
];
buildTools = [
haskellngPackages.hdevtools
haskellngPackages.cabal-install
];
license = stdenv.lib.licenses.unfree;
}) {};
in
pkg.env
~~~
On Wed, Feb 18, 2015 at 8:18 AM, Daniel Bergey ber...@teallabs.org wrote:
On 2015-02-16 at 08:42, YCH dontdie...@gmail.com wrote:
I've read quite many document. Wiki, nix pills, ... . But I'm confused about
so many different ways doing similar things. And I'm worried about haskell-ng
specific things. There is already 'haskellngPackages.hdevtools'. So I should
override using ~/hdevtools. I'll attach my current setup information.
Nix certainly has an overwhelming number of options for similar things.
Here are two options for your situation:
1. Override hdevtools for all your builds, editing
~/.nixpkgs/config.nix, following the explanation in [1]. This is
probably the right thing; I expect you always want the patched
hdevtools. A complete config.nix:
2. Override hdevtools in your shell.nix, just for this build. This is
useful when you need a patched version of some Haskell library, rather
than a build tool. In this case, add to the let definitions (before
pkg)
hdevtools = haskellngPackages.callPackage ~/hdevtools {};
I think you'll need to replace the ~ with your homedir; ISTR Nix doesn't
interpret ~. Then change your buildTools line to refer to hdevtools,
not haskellngPackages.hdevtools.
cheers,
bergey
Footnotes:
[1] http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015601.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
Hi guys,
many Python packages specify an attribute that disables build attempts
in certain packages sets, like this:
beaker = buildPythonPackage rec {
name = Beaker-1.6.4;
disabled = isPy3k;
[...]
};
Unfortunately, that information does not propagate to other packages
that use them. The package almir, for instance, depends on beaker
but *allows* Python 3.x builds. The result is an evaluation error on
Hydra:
in job ‘python33Packages.almir.x86_64-linux’:
Package ‘python3.3-Beaker-1.6.4’ in
‘/nix/store/vr71jj15vk57p0mb85annpszswhhf7f4-git-export/pkgs/development/python-modules/generic/default.nix:57’
is marked as broken, refusing to evaluate.
As of now, we have dozens of those errors in [1]. I have tried to make
some headway getting rid of those errors, but manually fixing all those
under-specified disabled attributes is a bit of fools errand, because
without a doubt those specifications will become inconsistent again over
time!
Now, we should really try to have Zero evalutation errors on Hydra,
because those false messages drown out real errors, which would need
fixing. I'm not particularly involved in the maintenance of the Python
package set, so I'd like to bring this issue to the attention of those
who know more about Python and work more with Python in Nixpkgs than I
do. Can we solve this issue somehow in a way that doesn't require human
beings to fix everything manually?
Best regards,
Peter
[1] http://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-errors
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
Hi Luca, Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. yes, that is true. I guess the problems shows up with Python more than other packages because Python has many different active environments: Py2k, Py3k, PyPy. The Haskell package set used to have the same problem, but the NG effort remedied that by generating the entire package set programmatically to be consistent. python-packages.nix is maintained manually, though, so it's easier for those packages to have inconsistent specifications. 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] Underspecified 'disabled' attributes in python-packages.nix
On 24/02/2015 16:29, Peter Simons wrote:
Hi guys,
many Python packages specify an attribute that disables build attempts
in certain packages sets, like this:
beaker = buildPythonPackage rec {
name = Beaker-1.6.4;
disabled = isPy3k;
[...]
};
Unfortunately, that information does not propagate to other packages
that use them. The package almir, for instance, depends on beaker
but *allows* Python 3.x builds. The result is an evaluation error on
Hydra:
in job ‘python33Packages.almir.x86_64-linux’:
Package ‘python3.3-Beaker-1.6.4’ in
‘/nix/store/vr71jj15vk57p0mb85annpszswhhf7f4-git-export/pkgs/development/python-modules/generic/default.nix:57’
is marked as broken, refusing to evaluate.
As of now, we have dozens of those errors in [1]. I have tried to make
some headway getting rid of those errors, but manually fixing all those
under-specified disabled attributes is a bit of fools errand, because
without a doubt those specifications will become inconsistent again over
time!
Now, we should really try to have Zero evalutation errors on Hydra,
because those false messages drown out real errors, which would need
fixing. I'm not particularly involved in the maintenance of the Python
package set, so I'd like to bring this issue to the attention of those
who know more about Python and work more with Python in Nixpkgs than I
do. Can we solve this issue somehow in a way that doesn't require human
beings to fix everything manually?
Best regards,
Peter
Afaik it's not only a python disabled problem. It also happens for
meta.broken that doesn't get propagated.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Underspecified 'disabled' attributes in python-packages.nix
On 02/24/2015 04:33 PM, Luca Bruno wrote: Afaik it's not only a python disabled problem. It also happens for meta.broken that doesn't get propagated. Yes, one great advantage of throw is how it propagates nicely. Is there a reason not to use that, except for errors in Hydra evals? We might just tweak/customize error-logging from the current throw instead of doing anything complex. 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] status of mingw support
hi, Quoting Anders Papitto (2015-02-20 20:42:36) Hello, I am currently looking into building some software using the mingw cross compiler (specifically, the brood war api as per http://www.broodwarai.com/forums/viewtopic.php?f=7t=984). However, after some time googling and grepping through the nixpkgs repository for references to mingw, it looks like there used to be support, but it was abandoned some time ago. Could someone summarize the current status of using mingw from nixos? Is it possible to get it working with some effort, or are there fundamental incompatibilities? there has been work on getting cygwin support back. some cleanup of the #6101 is needed but major parts have been done by @chaoflow and @durko. its still on my todo list to test #6101 in full but this got pushed to next week, due to current workload. https://github.com/NixOS/nixpkgs/pull/6101 i guess you could use cygwin environment to bootstrap build environment on windows and continue to get closer to mingw support. hope that helps. -- Rok Garbas - http://www.garbas.si signature.asc Description: signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] HaskellNG and taffybar
Nixpkgs contains a patched ghc-paths package that allows you to specify the path to ghc at runtime using the NIX_GHC environment variable. Luke Clifton ltclif...@gmail.com schrieb am Di., 24. Feb. 2015 03:12: This is also a problem with the Yi editor which also uses Dyre. On 24 February 2015 at 04:18, Kirill Elagin kirela...@gmail.com wrote: Well, the author of the issue I pointed out is correct in saying that they use Dyre which in turn uses ghc-paths. I checked ghc-paths and I believe what they do is store the path to GHC _they were compiled with_. So errr... Looks like we are stuck in a loop. I guess your best bet is to patch Dyre not to use ghc-paths. On Mon Feb 23 2015 at 23:59:51 Arseniy Seroka ars.ser...@gmail.com wrote: 2015-02-23 22:55 GMT+03:00 Kirill Elagin kirela...@gmail.com: Does XMonad work in your case? Can you import `System.Taffybar` in `ghci`? Yes, xmonad works and I can import `System.Taffybar` in ghci. Might it be that, unlike XMonad, they do something more complicated to invoke GHC? I didn’t check the source, but looks like they do. Are you running this on a non-NixOS distro? In that case, the issue https://github.com/simonmar/ghc-paths/issues/4 probably explains what’s going I'm using Nixos. That's what they are doing. [1] [1] https://github.com/travitch/taffybar/blob/master/src/ System/Taffybar.hs#L204 -- Sincerely, Arseniy Seroka ___ 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] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
On 02/25/2015 03:01 AM, Anthony Cowley wrote: This almost certainly isn't ready for release, but I'd like to avoid duplicating efforts if other people want to work on it... Here is cabbage https://github.com/acowley/cabbage It is a tool for doing the obvious thing: use the cabal solver to find a build plan, then build the specific version of each package, and then link them into the sandbox in the current directory. As I said, this script has every warning tape and flashing light imaginable attached to it. I've used it to install ghc-mod, pandoc, hakyll, a bunch of web things like amazonka, and my Frames package with all its demos (involving Chart, diagrams, JuicyPixels, and who knows what else). There are missing pieces outlined in the Tasks list at the end of the Org file that is the source code for the script. I would more than welcome contributions as this is how I would like to use Nix with Cabal, and getting help from like-minded folks would be a big boost! Anthony While interesting, I feel it is doing too much and using the wrong tooling at least for me. I have the power of nix-shell, I don't want to be using ‘cabal sandbox’ on top of it, that very much goes against all the benefits of using nix-shell to begin with. I don't call ‘cabal’ manually pretty much ever unless it's ‘cabal update’ though I know of cases where you still might prefer cabal repl over ghci, something I hopefully won't have to deal with. I think a simpler solution from the user experience perspective is if we can do something like ‘hackage2nix myproject.cabal’ which runs through the cabal solver and then spits out hackage-packages.nix with only the stuff that is needed with versions that are needed. We can now happily use this package set in our shell.nix or whatever just like we do today with manually written package sets. If it can do that then everything else works just like it does today already which is a good thing ;). If I want to do this today then I nix-build a package, see what version in complains about, add the package to the project's set and repeat until physically ill. On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 02/22/2015 12:04 PM, Peter Simons wrote: Hi Cody, haskellngPackages doesn't seem to have all versions of all dependencies... I'm not sure what you mean by all versions of all dependencies. Dependencies of what exactly? The way I understand the term, dependency has meaning only as a relationship between two packages, i.e. transformers is a dependency of mtl. I'm not sure how to apply that interpretation to your question? If you're asking why hackage-packages.nix doesn't contain every single version of every package registered on Hackage, then the answer is because that would be a database containing well over 50,000 packages, the vast majority of which no-one will ever care about (nor will they ever compile). So it seems pointless to distribute all that stuff as part of Nixpkgs. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev A related question: is there a way to generate a package list containing exactly the versions of dependencies we require? Say we have a package with cabal file A == 1.0 B 2.0 C 0.5 but the latest Hackage has versions lower and higher c and that's what is in nixpkgs. I found myself wishing that there was an easy to just say ‘give me a set of packages that's valid from cabal's point of view’ rather than what we currently tend to do which is ‘include latest versions of everything, jailbreak and hope it works’ which is fine for nixpkgs but subpar if we just want that one project working but it requires specific versions of dependencies. -- Mateusz K. ___ 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 -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
On 02/22/2015 12:04 PM, Peter Simons wrote: Hi Cody, haskellngPackages doesn't seem to have all versions of all dependencies... I'm not sure what you mean by all versions of all dependencies. Dependencies of what exactly? The way I understand the term, dependency has meaning only as a relationship between two packages, i.e. transformers is a dependency of mtl. I'm not sure how to apply that interpretation to your question? If you're asking why hackage-packages.nix doesn't contain every single version of every package registered on Hackage, then the answer is because that would be a database containing well over 50,000 packages, the vast majority of which no-one will ever care about (nor will they ever compile). So it seems pointless to distribute all that stuff as part of Nixpkgs. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev A related question: is there a way to generate a package list containing exactly the versions of dependencies we require? Say we have a package with cabal file A == 1.0 B 2.0 C 0.5 but the latest Hackage has versions lower and higher c and that's what is in nixpkgs. I found myself wishing that there was an easy to just say ‘give me a set of packages that's valid from cabal's point of view’ rather than what we currently tend to do which is ‘include latest versions of everything, jailbreak and hope it works’ which is fine for nixpkgs but subpar if we just want that one project working but it requires specific versions of dependencies. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
This almost certainly isn't ready for release, but I'd like to avoid duplicating efforts if other people want to work on it... Here is cabbage https://github.com/acowley/cabbage It is a tool for doing the obvious thing: use the cabal solver to find a build plan, then build the specific version of each package, and then link them into the sandbox in the current directory. As I said, this script has every warning tape and flashing light imaginable attached to it. I've used it to install ghc-mod, pandoc, hakyll, a bunch of web things like amazonka, and my Frames package with all its demos (involving Chart, diagrams, JuicyPixels, and who knows what else). There are missing pieces outlined in the Tasks list at the end of the Org file that is the source code for the script. I would more than welcome contributions as this is how I would like to use Nix with Cabal, and getting help from like-minded folks would be a big boost! Anthony On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 02/22/2015 12:04 PM, Peter Simons wrote: Hi Cody, haskellngPackages doesn't seem to have all versions of all dependencies... I'm not sure what you mean by all versions of all dependencies. Dependencies of what exactly? The way I understand the term, dependency has meaning only as a relationship between two packages, i.e. transformers is a dependency of mtl. I'm not sure how to apply that interpretation to your question? If you're asking why hackage-packages.nix doesn't contain every single version of every package registered on Hackage, then the answer is because that would be a database containing well over 50,000 packages, the vast majority of which no-one will ever care about (nor will they ever compile). So it seems pointless to distribute all that stuff as part of Nixpkgs. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev A related question: is there a way to generate a package list containing exactly the versions of dependencies we require? Say we have a package with cabal file A == 1.0 B 2.0 C 0.5 but the latest Hackage has versions lower and higher c and that's what is in nixpkgs. I found myself wishing that there was an easy to just say ‘give me a set of packages that's valid from cabal's point of view’ rather than what we currently tend to do which is ‘include latest versions of everything, jailbreak and hope it works’ which is fine for nixpkgs but subpar if we just want that one project working but it requires specific versions of dependencies. -- Mateusz K. ___ 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] Help packaging BLAST?
Hi! The existing BLAST package (https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/biology/ncbi-tools/default.nix) isn't working for me. Probably because it's broken on x64. So I'm trying to package the standalone executables from http://www.ncbi.nlm.nih.gov/books/NBK52640/ instead. I've created a package (https://github.com/jefdaj/nixpkgs/blob/master/pkgs/applications/science/biology/ncbi-blast/default.nix) but can't run the resulting programs. They all say something like: $ blastn bash: /run/current-system/sw/bin/blastn: No such file or directory Based on https://www.biostars.org/p/12298/ I think I have the right architecture: $ uname -a Linux acro 3.14.29 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux $ file blastn blastn: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped The dynamically linked part worries me though. Do I need to add build inputs referencing a specific gcc or something? Also including the suggested readelf command for completeness: $ readelf -a blastn | head -n20 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Ident Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: AMD x86-64 Version: 1 (current) Entry point address: 0xc95f20 Start of program headers: 64 (bytes into file) Start of section headers: 32499288 (bytes into file) Flags: Size of this header: 64 (bytes) Size of program header entries:56 (bytes) Number of program headers entries: 9 Size of section header entries:64 (bytes) Number of section headers entries: 32 Section header string table index: 31 If this is a dead end, I could also try porting the Debian package right? How hard is that? Thanks Jeff ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Automatic download option for requireFile
Hi, On 02/24/2015 10:37 PM, Nicolas Pierron wrote: On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát vcu...@gmail.com wrote: On 02/24/2015 12:02 PM, Harald van Dijk wrote: If you just want to _use_ the software, not modify it, not re-distribute it, then for a whole lot of packages, you do not have to accept the license. I meant that in any case you're required to conform to the license terms (whether that means some act of accepting it or not). Which raise a good point, what does allowUnfree = true; means. Does that mean that you read the licenses of all software, and that you do *agree with all* of them? Should we do something like allowLicenses = [ pkgs.licenses.adobeEULA ]; instead? Just to follow up part of the cause of the discussion, Oracle JDKs 7/8 download with fetchurl now, [1]. [1] https://github.com/NixOS/nixpkgs/pull/6557 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
