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

[Fabian Schmitthenner]

huh? what's the problem?

To be clear, when clicking on a package, some parameters will be shown,
e. g. asciidoc, qtbase.base have quite some parameters.
For some packages, "error" "some error happened" is displayed, that
means that the parameters couldn't be determined because callPackage
wasn't used in the normal way. Also, currently packages that don't
succeed are currently shown and the error is displayed in the long
description.

On 02/29/2016 04:14 AM, Roger Qiu wrote:
> Demo doesn't seem to be working atm.
> 
> On 29/02/2016 2:59 PM, 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.
>>
>> 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

[Nix-dev] Displaying package parameters

[Fabian Schmitthenner]

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] new tool: nixos-typecheck

[Thomas Strobel]

Hi!

There is the new tool "nixos-typecheck" available in NixOS (currently in 
master only) that is meant help us to keep the options of our nixos 
module system well defined. In particular, "nixos-typecheck" can check 
whether a type attribute is defined for the options of the module 
system, and whether the default and example attributes are extended by 
defaultText and literalExample where appropriate.

Defining the type attribute and defaultText and literalExample is 
especially important for automatically generating a well specified 
documentation of the nixos modules system, and to build enhanced tools 
like NixUI. So I think it would be great if we could get all the options 
that "nixos-typecheck" currently reports as "unspecified" typed for our 
next release 16.09.

What do you think?

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

Re: [Nix-dev] NixOS 16.03 branch-off time in 10 days

[Domen Kožar]

Done: https://github.com/NixOS/nixpkgs/tree/release-16.03

Please. for any major version bumps or changes breaking, open a PR and tag
@domenkozar for review.

On Sat, Feb 27, 2016 at 10:12 AM, Domen Kožar  wrote:

> Tomorrow is the branch off day, time to merge last sneaky changes.
>
> On Thu, 18 Feb 2016, 19:25 Domen Kožar  wrote:
>
>> Hi all,
>>
>> it's that time of the year when it's time to talk about new NixOS
>> release. According to our somewhat-documented release process at
>> https://github.com/NixOS/nixpkgs/issues/4442, I'd like to branch off
>> 16.03 on 28.2. (Sunday).
>>
>> When the branch is made, everyone is encouraged to test and bugfix the
>> release. No major bumps or other backwards-incompatible changes should be
>> made.
>>
>> Let me know if you think something is blocking the branch-off. The way I
>> see it, closure-size (https://github.com/NixOS/nixpkgs/pull/7701) won't
>> make it into this release and I wouldn't risk merging it a month before the
>> release. Big +1 from me for merging it after the branch off.
>>
>> Domen
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixON initiative

[zimbatm]

Interesting how much traffic this thread has. If we have importJSON I
suppose that we could then output JSON from all of our tooling. It should
also make it easier to get the output from any modern language.

In that case I will make some changes so that nix-prefetch-git outputs JSON
by default and propose importJSON to be added to the stdlib.

On Sun, 28 Feb 2016 at 17:48 Moritz Ulrich  wrote:

>
> zimbatm  writes:
> > ```
> > $ nix-prefetch-git git://github.com/direnv/direnv.git 2>/dev/null | tee
> > repo.nix
> > {
> >   url = "git://github.com/direnv/direnv.git";
> >   rev = "9283a67646349bfef002a7242db47a6b8ef75305";
> >   sha256 = "15kbzxwl03f0awnf5n6mw7hcz2dr7p6rpvhfyq3kxn1nk8jxcipx";
> > }
> > ```
>
> Any reason why we can't use JSON here? That would make everything *much*
> easier to generate from tools.
>
> I totally agree with other people in this thread: as much as I like Nix
> the language, I don't think we should create another JSON-like data
> format.
>
> Also, The only thange would be putting the attrs in "" and replacing the
> ; with ,. I don't think that would make it less readable.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixON initiative

[Moritz Ulrich]

zimbatm  writes:
> ```
> $ nix-prefetch-git git://github.com/direnv/direnv.git 2>/dev/null | tee
> repo.nix
> {
>   url = "git://github.com/direnv/direnv.git";
>   rev = "9283a67646349bfef002a7242db47a6b8ef75305";
>   sha256 = "15kbzxwl03f0awnf5n6mw7hcz2dr7p6rpvhfyq3kxn1nk8jxcipx";
> }
> ```

Any reason why we can't use JSON here? That would make everything *much*
easier to generate from tools. 

I totally agree with other people in this thread: as much as I like Nix
the language, I don't think we should create another JSON-like data
format.

Also, The only thange would be putting the attrs in "" and replacing the
; with ,. I don't think that would make it less readable.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixON initiative

[zimbatm]

So something like that ? https://github.com/NixOS/nixpkgs/pull/13552
And then we would convert all of our tooling to output JSON ?

On Sun, 28 Feb 2016 at 16:43 Anand Patil 
wrote:

> You could interpret {path: "/a/b/c"} as a path literal.
>
> On Sun, Feb 28, 2016, 11:06 AM zimbatm  wrote:
>
>> But we wouldn’t have the path type in JSON anymore ! Hmm maybe that’s a
>> good thing actually :p
>>
>> importJSON = path: builtins.fromJSON (builtins.readFile path);
>>
>> ​
>>
>> On Sun, 28 Feb 2016 at 15:37 jeaye  wrote:
>>
>>> On Sun, Feb 28, 2016 at 03:11:15PM +, Anand Patil wrote:
>>> > What about using some kind of JSON notation for this? There are some
>>> > mismatches between JSON and Nix primitives; but on the other hand JSON
>>> is
>>> > easy to parse and generate from every language, and many people are
>>> > familiar with it.
>>>
>>> I wholeheartedly concur; please don't make another JSON-like format.
>>> JSON is so well supported in so many languages and, I believe, it does
>>> everything we'd need.
>>>
>> ___
>>> 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] NixON initiative

[Anand Patil]

You could interpret {path: "/a/b/c"} as a path literal.

On Sun, Feb 28, 2016, 11:06 AM zimbatm  wrote:

> But we wouldn’t have the path type in JSON anymore ! Hmm maybe that’s a
> good thing actually :p
>
> importJSON = path: builtins.fromJSON (builtins.readFile path);
>
> ​
>
> On Sun, 28 Feb 2016 at 15:37 jeaye  wrote:
>
>> On Sun, Feb 28, 2016 at 03:11:15PM +, Anand Patil wrote:
>> > What about using some kind of JSON notation for this? There are some
>> > mismatches between JSON and Nix primitives; but on the other hand JSON
>> is
>> > easy to parse and generate from every language, and many people are
>> > familiar with it.
>>
>> I wholeheartedly concur; please don't make another JSON-like format.
>> JSON is so well supported in so many languages and, I believe, it does
>> everything we'd need.
>>
> ___
>> 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] NixON initiative

[Daniel Peebles]

You mean you don't like naming it after everyone's favorite US president? :)

> On Feb 28, 2016, at 09:54, deCube.net | Danny Wilson  wrote:
> 
> How about NEON
> 
> Nix Expression Object Notation
> 
>> On 28 feb. 2016, at 15:49, stewart mackenzie  wrote:
>> 
>> Excellent idea, this removes quite a lot of manual steps.
>> 
>> Recently wrote some dirty python scripts to automate the checking and 
>> replacing of sha256s, this approach would make it trivial, reducing check 
>> times from about an hour and growing to mere seconds.
>> 
>> Though, I do have a reservation about the name. An unbubbled search for 
>> NixOS almost always returns a 'did you mean Nixon?' It's infuriating. 
>> Clojure's equivalent is Edn.
>> 
>> Might I encourage a wilder more adventures ... unambiguous name?
>> 
>> /sjm
>> 
>> ___
>> 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] NixON initiative

[yacine.hmito]

That would work with some kind of importJSON function, that will automatically 
convert a JSON into a valid Nix expression with literals.

 Original message 
From: jeaye  
Date: 28/02/2016  16:37  (GMT+01:00) 
To: Anand Patil  
Cc: nix-dev  
Subject: Re: [Nix-dev] NixON initiative 

On Sun, Feb 28, 2016 at 03:11:15PM +, Anand Patil wrote:
> What about using some kind of JSON notation for this? There are some
> mismatches between JSON and Nix primitives; but on the other hand JSON is
> easy to parse and generate from every language, and many people are
> familiar with it.

I wholeheartedly concur; please don't make another JSON-like format.
JSON is so well supported in so many languages and, I believe, it does
everything we'd need.
___
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] NixON initiative

[jeaye]

On Sun, Feb 28, 2016 at 03:11:15PM +, Anand Patil wrote:
> What about using some kind of JSON notation for this? There are some
> mismatches between JSON and Nix primitives; but on the other hand JSON is
> easy to parse and generate from every language, and many people are
> familiar with it.

I wholeheartedly concur; please don't make another JSON-like format.
JSON is so well supported in so many languages and, I believe, it does
everything we'd need.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixON initiative

[Graham Christensen]

> It should, most emphatically, that's the whole point!
>
> Stripping the Turing completeness with no remorse will open up a vast array
> of options for data processing in the toolchain.
>

Yes, and what I meant is it would be very easy to start calling it NixON 
and start importing like zimbatm's example demonstrates:

 src = fetchFromGit (import ./repo.nix);

where it doesn't actually have a reduced set of language features. I'm 
sorry if that wasn't clear, or if it wasn't helpful to bring up.

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

Re: [Nix-dev] NixON initiative

[Anand Patil]

What about using some kind of JSON notation for this? There are some
mismatches between JSON and Nix primitives; but on the other hand JSON is
easy to parse and generate from every language, and many people are
familiar with it.

On Sun, Feb 28, 2016, 9:54 AM deCube.net | Danny Wilson 
wrote:

> How about NEON
>
> Nix Expression Object Notation
>
> On 28 feb. 2016, at 15:49, stewart mackenzie  wrote:
>
> Excellent idea, this removes quite a lot of manual steps.
>
> Recently wrote some dirty python scripts to automate the checking and
> replacing of sha256s, this approach would make it trivial, reducing check
> times from about an hour and growing to mere seconds.
>
> Though, I do have a reservation about the name. An unbubbled search for
> NixOS almost always returns a 'did you mean Nixon?' It's infuriating.
> Clojure's equivalent is Edn.
>
> Might I encourage a wilder more adventures ... unambiguous name?
>
> /sjm
> ___
> 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] NixON initiative

[Graham Christensen]

I think it is a great idea for these functions to return valid nix 
expressions, and to be able to directly write them to a file. I also 
really like the idea of creating a named subset only containing literal 
values.


However... I disagree about calling it something special other than just 
a plain nix expression until the parser actually limits on what can be 
in the file. As it is now, it would be just yet another term to know about.


I worry that without restrictions it makes the distinction meaningless, 
and worse, creates files which are so-called "nixon" but may not 
actually be. This could make it much more difficult later on to add 
restrictions.


Best,
Graham

On 02/28/2016 08:54 AM, deCube.net | Danny Wilson wrote:

How about NEON

Nix Expression Object Notation

On 28 feb. 2016, at 15:49, stewart mackenzie > wrote:



Excellent idea, this removes quite a lot of manual steps.

Recently wrote some dirty python scripts to automate the checking and 
replacing of sha256s, this approach would make it trivial, reducing 
check times from about an hour and growing to mere seconds.


Though, I do have a reservation about the name. An unbubbled search 
for NixOS almost always returns a 'did you mean Nixon?' It's 
infuriating. Clojure's equivalent is Edn.


Might I encourage a wilder more adventures ... unambiguous name?

/sjm

___
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] NixON initiative

[deCube.net | Danny Wilson]

How about NEON

Nix Expression Object Notation

On 28 feb. 2016, at 15:49, stewart mackenzie  wrote:

> Excellent idea, this removes quite a lot of manual steps.
> 
> Recently wrote some dirty python scripts to automate the checking and 
> replacing of sha256s, this approach would make it trivial, reducing check 
> times from about an hour and growing to mere seconds.
> 
> Though, I do have a reservation about the name. An unbubbled search for NixOS 
> almost always returns a 'did you mean Nixon?' It's infuriating. Clojure's 
> equivalent is Edn.
> 
> Might I encourage a wilder more adventures ... unambiguous name?
> 
> /sjm
> 
> ___
> 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] NixON initiative

[stewart mackenzie]

Excellent idea, this removes quite a lot of manual steps.

Recently wrote some dirty python scripts to automate the checking and
replacing of sha256s, this approach would make it trivial, reducing check
times from about an hour and growing to mere seconds.

Though, I do have a reservation about the name. An unbubbled search for
NixOS almost always returns a 'did you mean Nixon?' It's infuriating.
Clojure's equivalent is Edn.

Might I encourage a wilder more adventures ... unambiguous name?

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

Re: [Nix-dev] AppImage

[Bjørn Forsman]

On 28 February 2016 at 15:28, Bjørn Forsman  wrote:
> On 28 February 2016 at 15:07, Vladimír Čunát  wrote:
>> On 02/28/2016 02:59 PM, Bjørn Forsman wrote:
>> Fetching expressions is something else than the author wants.
>> Third-party binary packages for nix can be provided, and we have those
>> one-click installs for that. Of course one would have to have some
>> package manager on the system already (Nix in this case), which is
>> considered a large disadvantage by them.
>
> Oh, I didn't know that one-click installer packages could be made by
> third parties. I'll read the manpage now.

I looked at "man nix-install-package" and the One-click installation
section in the NixOS manual,
http://nixos.org/nix/manual/#sec-nix-install-package. Neither source
made me understand how to _create_ a .nixpkg file. The manual
described the internals of the .nixpkg file though. If one would have
to install Hydra to build .nixpkg files(?), not good.

I think it should be as simple as:

  nix create-nixpkgs myapp   # myapp is an attribute referring to a derivation

Then upload the resulting .nixpkg to a webserver.

Unfortunately, I don't have skills nor time to implement that.

BTW, nix-install-package manpage refers to "manifests". Didn't nix
deprecate manifests some time ago?

Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [***SPAM***] Re: AppImage

[Michael Raskin]

>> BTW, I tried their Chromium AppImages and without success, at least on
>> NixOS. So much for running on any Linux.
>> $ /some/path/Chromium-50.0.2644.0-x86_64.AppImage
>> -bash: /some/path/Chromium-50.0.2644.0-x86_64.AppImage: No such file or
>> directory
>
>I experienced similar thing with Pitivi "universal" package installer.
>It has everything bundled *except* the linker. (I wonder how 0install
>handles the linker.)

Interesting question. Actually, a linker is not such a big part, and it
is easy to ship the proper linker with the package (I actually did that
once and it was easy to get right).

But linker is almost always called the same, so AppImage never cared
enough to check.





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

[Nix-dev] NixON initiative

[zimbatm]

No, not the dead president :) JavaScript has JSON and Nix has NixON. A
subset of the language that only contains literal values.

Thanks to Tim Cuthbertson (@gfxmonk) nix-prefetch-git now outputs valid
NixON. Would it make sense to convert more of our tooling to using that
notation forward ?

The big advantage is that you can do something like:

```nix
{ stdenv, fetchFromGit }:
stdenv.mkDerivation {
  src = fetchFromGit (import ./repo.nix);
  ...
```

Then when upstream has an update it's very easy to write a script that
outputs that `repo.nix` file.
```
$ nix-prefetch-git git://github.com/direnv/direnv.git 2>/dev/null | tee
repo.nix
{
  url = "git://github.com/direnv/direnv.git";
  rev = "9283a67646349bfef002a7242db47a6b8ef75305";
  sha256 = "15kbzxwl03f0awnf5n6mw7hcz2dr7p6rpvhfyq3kxn1nk8jxcipx";
}
```

That's it really, I just wanted to throw that idea out there. Going forward
I think that having more of our tools emit nixon could be useful because it
ties all the ecosystem together.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AppImage

[Bjørn Forsman]

On 28 February 2016 at 15:07, Vladimír Čunát  wrote:
> On 02/28/2016 02:59 PM, Bjørn Forsman wrote:
>> On 28 February 2016 at 14:19, Domen Kožar  wrote:
>>> For your reading pleasue
>>> https://github.com/probonopd/AppImageKit/wiki/Similar-projects#nix
>>
>> Seems we need to (1) package Subsurface and (2) implement recursive
>> Nix(?) so that expressions can be fetched from upstream repos
>> directly.
>
> Fetching expressions is something else than the author wants.
> Third-party binary packages for nix can be provided, and we have those
> one-click installs for that. Of course one would have to have some
> package manager on the system already (Nix in this case), which is
> considered a large disadvantage by them.

I guess we cannot please everyone.

Oh, I didn't know that one-click installer packages could be made by
third parties. I'll read the manpage now.

> BTW, I tried their Chromium AppImages and without success, at least on
> NixOS. So much for running on any Linux.
> $ /some/path/Chromium-50.0.2644.0-x86_64.AppImage
> -bash: /some/path/Chromium-50.0.2644.0-x86_64.AppImage: No such file or
> directory

I experienced similar thing with Pitivi "universal" package installer.
It has everything bundled *except* the linker. (I wonder how 0install
handles the linker.)

Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AppImage

[Vladimír Čunát]

On 02/28/2016 02:59 PM, Bjørn Forsman wrote:
> On 28 February 2016 at 14:19, Domen Kožar  wrote:
>> For your reading pleasue
>> https://github.com/probonopd/AppImageKit/wiki/Similar-projects#nix
> 
> Seems we need to (1) package Subsurface and (2) implement recursive
> Nix(?) so that expressions can be fetched from upstream repos
> directly.

Fetching expressions is something else than the author wants.
Third-party binary packages for nix can be provided, and we have those
one-click installs for that. Of course one would have to have some
package manager on the system already (Nix in this case), which is
considered a large disadvantage by them.

BTW, I tried their Chromium AppImages and without success, at least on
NixOS. So much for running on any Linux.
$ /some/path/Chromium-50.0.2644.0-x86_64.AppImage
-bash: /some/path/Chromium-50.0.2644.0-x86_64.AppImage: No such file or
directory


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

[Bjørn Forsman]

On 28 February 2016 at 14:19, Domen Kožar  wrote:
> For your reading pleasue
> https://github.com/probonopd/AppImageKit/wiki/Similar-projects#nix

Seems we need to (1) package Subsurface and (2) implement recursive
Nix(?) so that expressions can be fetched from upstream repos
directly.

IMHO, a central repository works for most but not all of packaging
needs. Leaf programs can probably better be dealt with directly with
upstream.

Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] AppImage

[Domen Kožar]

For your reading pleasue
https://github.com/probonopd/AppImageKit/wiki/Similar-projects#nix

On Sun, Feb 28, 2016 at 9:26 AM, Vladimír Čunát  wrote:

> On 02/27/2016 11:33 PM, Eelco Dolstra wrote:
> > On 27/02/16 15:28, Vladimír Čunát wrote:
> >> The aims seem significantly different. Appimage and many others
> >> evidently focus on creating bundles that "just work" everywhere. That
> >> was never among the (main) objectives of Nix, although you can make it
> >> create similar bundles.
> >
> > Actually it was. It's certainly a goal that a Nix package works on any
> Linux
> > distribution.
>
> Ah, I got a little carried away, and moreover made a claim without
> having evidence to support it.
>
> --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] --ftls-model=global-dynamic for every lib?

[stewart mackenzie]

Globin deserves a rather large amount of beers from me!

Such fantastic work globin, looking forward to this PR landing!

Thanks for the link Domen! I'll sleep like a well tonight.

/sjm

On 28 Feb 2016 18:33, "Domen Kožar"  wrote:
>
> See
https://github.com/NixOS/nixpkgs/pull/12895/files#diff-8ac87a75c3dd650a7f760fa3b2d041bfR239
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] --ftls-model=global-dynamic for every lib?

[Adrien Devresse]

Thx Domen, this is exactly what I was looking for.




Le 28/02/2016 11:33, Domen Kožar a écrit :
> See 
> https://github.com/NixOS/nixpkgs/pull/12895/files#diff-8ac87a75c3dd650a7f760fa3b2d041bfR239
>
> On Sun, Feb 28, 2016 at 10:31 AM, Adrien Devresse  > wrote:
>
> To generalize a bit on this.
>
> Most of the Linux distributions have a mandatory default set of flags
> for all libraries / binaries that are enforced through "configure /
> cmake" macros ( -fPIC is part of them ). They do this for very good
> reasons: security, protability, compatibility.
>
> It would be good to have a bit of documentation on how to handle
> this in
> NixOS.
>
>
> Adev~~
>
> Le 28/02/2016 01:31, stewart mackenzie a écrit :
> > Just to clarify the correct argument passed to gcc or clang
> should be -fpic .
> > ___
> > 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
>
>



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] --ftls-model=global-dynamic for every lib?

[Vladimír Čunát]

On 02/28/2016 11:31 AM, Adrien Devresse wrote:
> Most of the Linux distributions have a mandatory default set of flags
> for all libraries / binaries that are enforced through "configure /
> cmake" macros ( -fPIC is part of them ).

The security flags are WIP here: https://github.com/NixOS/nixpkgs/pull/12895




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] --ftls-model=global-dynamic for every lib?

[Domen Kožar]

See
https://github.com/NixOS/nixpkgs/pull/12895/files#diff-8ac87a75c3dd650a7f760fa3b2d041bfR239

On Sun, Feb 28, 2016 at 10:31 AM, Adrien Devresse  wrote:

> To generalize a bit on this.
>
> Most of the Linux distributions have a mandatory default set of flags
> for all libraries / binaries that are enforced through "configure /
> cmake" macros ( -fPIC is part of them ). They do this for very good
> reasons: security, protability, compatibility.
>
> It would be good to have a bit of documentation on how to handle this in
> NixOS.
>
>
> Adev~~
>
> Le 28/02/2016 01:31, stewart mackenzie a écrit :
> > Just to clarify the correct argument passed to gcc or clang should be
> -fpic .
> > ___
> > 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] --ftls-model=global-dynamic for every lib?

[Adrien Devresse]

To generalize a bit on this.

Most of the Linux distributions have a mandatory default set of flags
for all libraries / binaries that are enforced through "configure /
cmake" macros ( -fPIC is part of them ). They do this for very good
reasons: security, protability, compatibility.

It would be good to have a bit of documentation on how to handle this in
NixOS.


Adev~~

Le 28/02/2016 01:31, stewart mackenzie a écrit :
> Just to clarify the correct argument passed to gcc or clang should be -fpic .
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev




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

[Vladimír Čunát]

On 02/27/2016 11:33 PM, Eelco Dolstra wrote:
> On 27/02/16 15:28, Vladimír Čunát wrote:
>> The aims seem significantly different. Appimage and many others
>> evidently focus on creating bundles that "just work" everywhere. That
>> was never among the (main) objectives of Nix, although you can make it
>> create similar bundles.
> 
> Actually it was. It's certainly a goal that a Nix package works on any Linux
> distribution.

Ah, I got a little carried away, and moreover made a claim without
having evidence to support it.

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

[Nix-dev] Small Channel Binaries

[Roger Qiu]

Hi all,

If the small channels contain less binaries in the binary cache. Is 
there a way to find out which binaries are available in the small 
channel compared to the normal channel, and compare between them?

-- 
Founder of Matrix AI
https://matrix.ai/
+61420925975

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