Re: [Nix-dev] Understanding the Binary Cache

[Herwig Hochleitner]

2016-03-06 2:50 GMT+01:00 Roger Qiu :

>
>

Oops, I replied off-list by accident. Maybe somebody can detail on the
follow-up.


> So if the upstream URLs are failing, does that mean building from source
> is impossible, or is building from source is still possible, but I didn't
> enable it? (You mentioned building from source is by default false).
>

That's what --fallback is for

Do you have links to issues/mailing list discussions about the transition
> between binary caches and binary manifests?
>
>
On 5/03/2016 2:57 AM, Herwig Hochleitner wrote:
>
> 2016-03-03 8:56 GMT+01:00 Roger Qiu :
>
>>
>> I am just trying to understand this. If this is true, then why is it
>> that when I sometimes try to install packages, the installation process
>> fails because the upstream URL is not responding. This has happened
>> several times on 15.09 with different kinds of packages like Sage,
>> packages from Freedesktop.org... etc.
>>
>
> It tries to find the package in the binary cache anyway. This behavior is
> governed by multiple flags (man 5 nix.conf), amongs other:
>
> build-use-substitutes (default true) => try to use binaries
> build-fallback or --fallback (default false) => build from source, if
> binaries exist but fails (e.g flaky connection)
> [binary- / extra-binary- / trusted-binary- ] caches => set binary caches
> to be used
>
> I understand that there are certain packages that always need to be
>> built from source like the nvidia binary blob. But those above packages
>> shouldn't have problem right?
>>
>
> That should happen on demand.
>
> Anyway I'm looking for a way to find what binaries are actually
>> available in the binary cache ahead of time, and compare them between
>> the main channels and the small versions. I've looked around and I can't
>> find anything that actually states the binaries available in small
>> channels versus the main channels.
>>
>
> This area is currently in transition: binary-caches are being obsoleted in
> favor of binary manifests:
> 
> https://nixos.org/releases/nixos/unstable/nixos-16.03pre77568.40c586b/MANIFEST
> Those are pretty greppable and you can use them directly from command
> line, I forget how ...
>
> BTW, you can run a git checkout and still enjoy the benefit of prebuilt
> binaries, by sticking close to the most recent channel commit:
> https://github.com/NixOS/nixpkgs-channels/tree/nixos-unstable
>
>
> --
> Founder of Matrix AIhttps://matrix.ai/+61420925975
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fwd: Re: Displaying package parameters

[Fabian Schmitthenner]

On 03/05/2016 07:13 PM, jeaye wrote:
> On Mon, Feb 29, 2016 at 11:24:32AM +0100, Jonn Mostovoy wrote:
>> Wow, very nice!
>> Maybe people reporting that it doesn't work weren't patient enough to wait
>> for it to load the entirety of packages ;)
> If I load the page, wait 5 minutes (should be long enough...), and type
> 'firefox', I can select the 'firefox-44.0.2' option and still see:
>
> error some error happened
>
> This clearly isn't a matter of being impatient.
Yes, you're right. This doesn't work for derivations that don't use
lib.makeOverridable (which callPackage implicitly uses) and currently
this (misleading) error message is shown in this case which I'll change
to something more descriptive.

I investigated this particular case (firefox) and we don't use
makeOverridable at the moment (because wrapFirefox doesn't use it). When
we change wrapFirefox to also use makeOverridable then this should work,
too. Currently, firefox also has no .override attribute (because it
doesn't use makeOverridable) and I believe this to be a bug.

But we already use lib.makeOverridable (by callPackage) for
'wrapFirefox' itself, so maybe we can also add some more functor logic
to makeOverridable to do this. We really have two layers of parameters.
But I have to think about that a little more.

Fabian
>
>> I just wanted to share that I tried displaying package parameters on the
>> nixos homepage and the current result can be seen here:
>> http://schmitthenner.eu/nixos-homepage/nixos/packages.html.
> This is superb. As mentioned, there are still some errors with common
> packages, but this is already very useful. Thanks for the work and for
> providing the source.

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

Re: [Nix-dev] Fwd: Re: Displaying package parameters

[jeaye]

On Mon, Feb 29, 2016 at 11:24:32AM +0100, Jonn Mostovoy wrote:
> Wow, very nice!
> Maybe people reporting that it doesn't work weren't patient enough to wait
> for it to load the entirety of packages ;)

If I load the page, wait 5 minutes (should be long enough...), and type
'firefox', I can select the 'firefox-44.0.2' option and still see:

error some error happened

This clearly isn't a matter of being impatient.

> I just wanted to share that I tried displaying package parameters on the
> nixos homepage and the current result can be seen here:
> http://schmitthenner.eu/nixos-homepage/nixos/packages.html.

This is superb. As mentioned, there are still some errors with common
packages, but this is already very useful. Thanks for the work and for
providing the source.


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

[Nix-dev] JAVA_HOME and other environment variables

[Svein Ove Aas]

Context: https://github.com/NixOS/nixpkgs/issues/13653

There are a few packages which can't be considered properly installed (and
usable) without setting environment variables, this example being the Java
development kit.

Some Java-based tools need to know where to find the JDK. The way they do
this is by looking at the JAVA_HOME environment variable. That is...
currently, it isn't set at all, unless you use nix-shell or an equivalent
mechanism.

I've thought of a couple of solutions, but would welcome other suggestions.
In no particular order...

(The problem is not restricted to just JAVA_HOME.)

- Wrapping the the JDK binaries with makeWrapper.
  This is a non-starter, as it's common to use JAVA_HOME in scripts.

- JAVA_HOME is set in the JDK's setup-hook. We can source that file on
shell startup.
  This works well for nix-shell, and is the approach I've chosen to take
globally for a temporary fix. Unfortunately, it is in a sense even worse
than the status quo. Since this produces a pointer into /nix/store, the
value of JAVA_HOME in a running shell can become invalid because the JDK in
question is GC'd (!), or superseded by a newer one *without* being deleted
(!!).

- Adding another directory under /run, containing symlinks that we can
mutate.
  Has the obvious problem of impurity, but we're talking about system (or
user) profiles; they're already impure, in the same sense. I don't see any
technical issues here, but that doesn't mean there aren't any. I'm not sure
how to implement it, or even whether I should.
  We'd have "JAVA_HOME=/run/env/JAVA_HOME", or so.

One further concern...

- Right now, the only way to install Java system-wide is to put it in
environment.systemPackages. Or using nix-env. Either way, JAVA_HOME
wouldn't get set; this is true even with that PR. I've been trying to think
of ways to fix this, but I have no idea how. Send help!
  As a result, even if I add programs.java to NixOS, it doesn't help anyone
who's got the problem right now.



I'd like to implement a general solution for all such situations, ideally
one that would get merged. Rant over, though. Thoughts?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Displaying package parameters

[Matthias Beyer]

On 29-02-2016 03:59:58, Fabian Schmitthenner wrote:
> Hi!
> 
> I just wanted to share that I tried displaying package parameters on the
> nixos homepage and the current result can be seen here:
> http://schmitthenner.eu/nixos-homepage/nixos/packages.html.
> 

+1! I love it.

It even shows opitonal package parameters! AWESOME!

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


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] Displaying package parameters

[Patrick Callahan]

I think it's great! I bookmarked your copy because I plan on using it while
I look forward to its integration on nixos.org. :-)

On Sun, Feb 28, 2016 at 9:00 PM Fabian Schmitthenner <
nix-...@schmitthenner.eu> wrote:

> Hi!
>
> I just wanted to share that I tried displaying package parameters on the
> nixos homepage and the current result can be seen here:
> http://schmitthenner.eu/nixos-homepage/nixos/packages.html.
>
> When you click on a package, you hopefully see its parameter. This uses
> a heruristic to try to figure out which parameters are packages (and
> thus not displayed) and which are not (and thus displayed) that goes
> roughly as follows:
>
> - If the parameter is instantiated - either implicitly or explicitly -
> by callPackage, we look at the value and if it's a derivation, or a list
> or attrset set of derivations, or a function it's not displayed
> - Otherwise, it's displayed
>
> I think there was a discussion about this a short while ago, but I
> couldn't find it.
>
> Please let me know what you think and if we might want a (more elaborate
> version, e. g. also displaying the value of default arguments that
> aren't changed by callPackage, which requires an other change to nix
> because this info is currently not available, we only know if the
> argument is optional or not afaik) of this on our official website.
>
> Source code can be found on
> https://github.com/NixOS/nixos-homepage/compare/master...fkz:master
> Technically, I patched nixpkgs customization, so we not only get the
> override... functions, but also the original parameters and the original
> function.
> Furthermore, this uses a patched version of nix which allows catching
> errors inside nix (added a primop __catch) that also seems useful more
> generally (when polished) (see https://github.com/fkz/nix/tree/catch-throw
> ).
>
> Fabian
> ___
> 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