Re: [Nix-dev] Help packaging BLAST?

[James Cook]

On 24 February 2015 at 21:30, Jeffrey David Johnson  wrote:
> 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

You probably have to run some patchelf command. Take a look at
networking/browsers/firefox-bin maybe (the firefox expression that
just downloads the official binary).

James
___
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?

[Mateusz Kowalczyk]

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
>  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

[Nix-dev] Help packaging BLAST?

[Jeffrey David Johnson]

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] Will Haskell-ng and hackage2nix allow building *any* versions of deps?

[Anthony Cowley]

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
 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

Re: [Nix-dev] Automatic download option for "requireFile"

[Thomas Strobel]

Hi,

On 02/24/2015 10:37 PM, Nicolas Pierron wrote:
> On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát  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

Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?

[Nikita Karetnikov]

> A related question: is there a way to generate a package list containing
> exactly the versions of dependencies we require?

I asked a similar question but about the cabal.config file some time
ago.  Here's the response:

http://article.gmane.org/gmane.linux.distributions.nixos/15885

I haven't tried it yet, though.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?

[Mateusz Kowalczyk]

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] haskell-ng: shell.nix magic to infer .env?

[Mateusz Kowalczyk]

Hi,

With old Haskell setup we'd essentially have a shell.nix that was a bit like

let
  pkgs = import  {}
  some_stuff = …;
in some_stuff.callPackage ./. {};

or some variation thereof. This allowed us to both nix-shell *and*
nix-build shell.nix out of the box. But with haskell-ng we end up with

(some_stuff.callPackage ./. {}).env;

which is all fine and dandy for when we want a shell but nix-build no
longer Just Works™. If we try to nix-build such expression in complains
that it's meant for interactive use only. Is there any way to recover
old behaviour? I imagine if we can tell if we're entering a nix-shell or
not then we can switch inside the expr and use .env when appropriate but
I don't know how to achieve this.

Thanks

-- 
Mateusz K.
___
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"

[Nicolas Pierron]

On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát  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

[Domen Kožar]

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  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 /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] Underspecified 'disabled' attributes in python-packages.nix

[Vladimír Čunát]

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 /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] How to override/replace part of a service definition?

[Nicolas Pierron]

Hi Michael,

On Sun, Feb 22, 2015 at 2:45 PM, Michael Alan Dorman  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  ", which has a convenient short-cut
named "mkForce ", 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] status of mingw support

[Rok Garbas]

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=7&t=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

[Benno Fünfstück]

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  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  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 
>> wrote:
>>
>>>
>>> 2015-02-23 22:55 GMT+03:00 Kirill Elagin :
>>>
 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
  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] Underspecified 'disabled' attributes in python-packages.nix

[Vladimír Čunát]

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] Underspecified 'disabled' attributes in python-packages.nix

[Luca Bruno]

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

[Peter Simons]

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

[Nix-dev] Underspecified 'disabled' attributes in python-packages.nix

[Peter Simons]

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] Alwyas remove icon-them.cache?

[Luca Bruno]

Pushed to staging.

On Mon, Feb 23, 2015 at 9:21 PM, Bjørn Forsman 
wrote:

> On 23 February 2015 at 21:18, Luca Bruno  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 
___
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

[Pascal Wittmann]

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"

[Vladimír Čunát]

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] Automatic download option for "requireFile"

[Harald van Dijk]

On 02/24/2015 11:30 AM, Vladimír Čunát wrote:
> 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).

No, you don't. Many licenses intentionally don't restrict anything 
copyright law would have already allowed you to do. The GPL even 
explicitly covers this:

"5. You are not required to accept this License, since you have not 
signed it. However, nothing else grants you permission to modify or 
distribute the Program or its derivative works. These actions are 
prohibited by law if you do not accept this License. Therefore, by 
modifying or distributing the Program (or any work based on the 
Program), you indicate your acceptance of this License to do so, and all 
its terms and conditions for copying, distributing or modifying the 
Program or works based on it."

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. The exact limits of what you're allowed to do without accepting 
the license of course depend on where you live.

If nixpkgs contains software that requires acceptance of the license, 
where nixpkgs indicates to the package acceptance of the license, and 
where that license restricts the user's rights, that is an huge problem.

config.allowUnfree is a setting that has to be set by the user. It does 
not get enabled by default. Covering software with restrictive EULAs so 
that they're only installable if config.allowUnfree is set is reasonable.

This is what happens with the Adobe Flash player, for instance. This is 
exactly the sort of scenario where software is freely downloadable -- 
although admittedly doing so through the website does require the user 
to indicate acceptance of the EULA. According to Adobe, even mere use of 
the software requires acceptance of the EULA. Because of this, the 
package is installable only if config.allowUnfree is set, and that's 
exactly the way it should be.

Cheers,
Harald van Dijk
___
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

[YCH]

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  {}).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  wrote:
> On 2015-02-16 at 08:42, YCH  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

Re: [Nix-dev] Automatic download option for "requireFile"

[Vladimír Čunát]

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 " 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] Make Firefox/Chrome use OpenJDK instead of Oracle JDK?

[Vladimír Čunát]

On 02/23/2015 07:02 AM, Chad Joan wrote:

It would be better if the structure of the option definitions allowed an
automated tool (or perhaps a nix expression) to walk the package
definitions and generate the documentation.


Yes, something like that seems doable in future. We would first have to 
standardize config specifications for those most common flag-like cases.


Of course, in some cases it's advantageous to allow passing much more 
complex things than just flags, so not all would be covered, but still.


Anyway, I don't feel like poking into this soon myself (not 2015); my 
ideas on this are pretty vague and I see more pressing matters to solve.


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