Re: [Nix-dev] i686 Builds?

[Tomasz Kontusz]

I'm on x86_64 and use some of those for running games (mostly what the steam 
package already pulls in, plus a few more that were needed for specific games).

The idea to only build them after x86_64 sounds pretty good. Actually, are all 
packages build together with the tests or only after they pass?

Shea Levy  napisał:
>Hi all,
>
>Do we still have users running 32-bit machines? It would reduce the
>load on 
>hydra significantly if we could drop support for i686, though of course
>if 
>people are still relying on it we shouldn't make the change yet.
>
>~Shea
>___
>nix-dev mailing list
>nix-dev@lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
Wysłane za pomocą K-9 Mail.___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Force nix

[phreedom]

On Tuesday, May 12, 2015 05:09:17 Arseniy Seroka wrote:
> Is there a way to force nix re-download cache (or sources) of derivation
> and it's dependencies?
nix-store --repair-path? it doesn't touch dependencies though
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Force nix

[Arseniy Seroka]

Is there a way to force nix re-download cache (or sources) of derivation
and it's dependencies?

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

Re: [Nix-dev] i686 Builds?

[Ambrus Kaposi]

I'm relying on these builds on my home laptop.

On Mon, May 11, 2015 at 11:36 PM, Shea Levy  wrote:
> Hi all,
>
> Do we still have users running 32-bit machines? It would reduce the load on
> hydra significantly if we could drop support for i686, though of course if
> people are still relying on it we shouldn't make the change yet.
>
> ~Shea
> ___
> 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] i686 Builds?

[Daniel Peebles]

Is there a way to get stats on which binary cache hashes are being
retrieved? Would be interesting to see what percentage is i686 and scale
build shares accordingly.

On Mon, May 11, 2015 at 6:36 PM, Shea Levy  wrote:

> Hi all,
>
> Do we still have users running 32-bit machines? It would reduce the load on
> hydra significantly if we could drop support for i686, though of course if
> people are still relying on it we shouldn't make the change yet.
>
> ~Shea
> ___
> 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] i686 Builds?

[William Kennington]

Maybe it would make more sense to only build the i686 builds if our tested
set of x86_64 binaries build correctly. We would still release with both
but it would cut down on a lot of redundant failures.

On Mon, May 11, 2015 at 3:39 PM Ryan Trinkle  wrote:

> I encountered an i686 user just the other day!  I don't use it personally,
> but having solid support in Nix was fantastic, especially because older,
> 32-bit machines tend to be slower, which makes Nix's binary caching
> functionality even more important.
>
> On Mon, May 11, 2015 at 6:36 PM, Shea Levy  wrote:
>
>> Hi all,
>>
>> Do we still have users running 32-bit machines? It would reduce the load
>> on
>> hydra significantly if we could drop support for i686, though of course if
>> people are still relying on it we shouldn't make the change yet.
>>
>> ~Shea
>> ___
>> 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] i686 Builds?

[Ryan Trinkle]

I encountered an i686 user just the other day!  I don't use it personally,
but having solid support in Nix was fantastic, especially because older,
32-bit machines tend to be slower, which makes Nix's binary caching
functionality even more important.

On Mon, May 11, 2015 at 6:36 PM, Shea Levy  wrote:

> Hi all,
>
> Do we still have users running 32-bit machines? It would reduce the load on
> hydra significantly if we could drop support for i686, though of course if
> people are still relying on it we shouldn't make the change yet.
>
> ~Shea
> ___
> 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] i686 Builds?

[Shea Levy]

Hi all,

Do we still have users running 32-bit machines? It would reduce the load on 
hydra significantly if we could drop support for i686, though of course if 
people are still relying on it we shouldn't make the change yet.

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

Re: [Nix-dev] sbcl image executables and patch-elf

[Eike]

Hi Thomas,

thanks for your reply; somehow I missed your response as yet. I just
found out that this is the strip utility from binutils and I'm wondering
how it can do such a harm…

Thanks again
Eike

Tomas Hlavaty  writes:

> Hi Eike,
>
>> I'm making a program in common lisp using sbcl. I then create a
>> executable image which results in quite a big file since the whole
>> lisp is packaged up. When I use nix to build this app, the file that
>> ends up in nix-store is tiny and not working. It seems to me that the
>> patch-elf process is stripping things off, but that's just a guess.
>
> try:
>
>dontStrip = true;
>
> in your build expression.
>
> Cheers,
>
> Tomas

--
gpg: AD7AC35E
finger print: 137F BB0B 1639 D25F DC5D  E59C B412 C5F5 AD7A C35E
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] sbcl image executables corrupted

[Eike]

I just tried putting the executable file inside a different directory
than 'bin' and this is working. It is not stripped/whatever -- only when
installed in the bin/ directory. Sorry about the confusion with
patchelf, I shouldn't put a wild guess in the title. It probably hasn't
anything to do with this problem. But I find these to lines in the
output of nix-build suspicious:

patching ELF executables and libraries in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
stripping (with flags -S) in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1/bin

and one of it starts with "patching ELF...". I don't know what's going
on here. Any hints are much appreciated.

Thanks and regards
Eike

Eike  writes:

> Hi there,
>
> I'm making a program in common lisp using sbcl. I then create a
> executable image which results in quite a big file since the whole lisp
> is packaged up. When I use nix to build this app, the file that ends up
> in nix-store is tiny and not working. It seems to me that the patch-elf
> process is stripping things off, but that's just a guess.
>
> Here is a mini example. Install sbcl and do this
>
> $ echo '(defun main () (format t "Hello World!~%"))' > hello.lisp
> $ sbcl --load hello.lisp --eval '(sb-ext:save-lisp-and-die "hello" :toplevel 
> (lambda() (main) 0) :executable t)'
>
> then there is a 'hello' executable with about 50mb. Running it prints
> the message to stdout.
>
> The same process in a 'hello/default.nix' like this:
>
> { pkgs ? import  {} }:
> pkgs.stdenv.mkDerivation {
>   name = "hello-0.0.1";
>   src = ./.;
>   buildPhase = ''
> echo '(defun main () (format t "Hello World!~%"))' > hello.lisp
> ${pkgs.sbcl}/bin/sbcl --load hello.lisp --eval 
> '(sb-ext:save-lisp-and-die "hello" :toplevel (lambda() (main) 0) :executable 
> t)'
> ls -lha *
>   '';
>   installPhase = ''
> mkdir -p $out/bin
> cp hello $out/bin
>   '';
> }
>
> Building it with 'nix-build hello' produces this:
>
> these derivations will be built:
>   /nix/store/7f6dp34myppgf3r0nfkdcxkinwp81g16-hello-0.0.1.drv
> building path(s) ‘/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1’
> building /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
> unpacking sources
> unpacking source archive /nix/store/dxk9zf3zd78j63g8ysbfsnmwwsf1gb02-hello
> source root is hello
> patching sources
> configuring
> no configure script, doing nothing
> building
> This is SBCL 1.2.5.nixos, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> [undoing binding stack and other enclosing state... done]
> [saving current Lisp image into hello:
> writing 5680 bytes from the read-only space at 0x2000
> writing 3120 bytes from the static space at 0x2010
> writing 50462720 bytes from the dynamic space at 0x10
> done]
> -rw-r--r-- 1 nixbld1 nixbld 410 May 11 08:11 default.nix
> -rwxr-xr-x 1 nixbld1 nixbld 49M May 11 08:11 hello
> -rw-r--r-- 1 nixbld1 nixbld  44 May 11 08:11 hello.lisp
> installing
> post-installation fixup
> patching ELF executables and libraries in 
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1/bin/hello
> gzipping man pages in 
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
> stripping (with flags -S) in 
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1/bin
> patching script interpreter paths in 
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
> /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
>
> The hello executable was 49M after building it. But the one in nix-store
> is this:
>
> l -lha result/bin 
>   
> ~
> insgesamt 272K
> dr-xr-xr-x 2 root nixbld 4,0K  1. Jan 1970  .
> dr-xr-xr-x 3 root nixbld 4,0K  1. Jan 1970  ..
> -r-xr-xr-x 6 root root   262K  1. Jan 1970  hello
>
> What' wrong here?
>
> Thanks in advance!
> Eike
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

--
gpg: AD7AC35E
finger print: 137F BB0B 1639 D25F DC5D  E59C B412 C5F5 AD7A C35E
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Possible bug in ssh key module

[Anand Patil]

Hi Bas, yep, it was just that. Sorry for the false alarm.

Thanks,
Anand

On Mon, May 11, 2015 at 12:52 AM, Bas van Dijk  wrote:
> On 11 May 2015 at 04:45, Anand Patil  wrote:
>> Hi everyone,
>>
>>
>> Just wanted to point out a small possible bug in NixOS version
>> 15.05pre61966.75ebc3c (Dingo). I noticed that when I add an
>> authorizedKeys option to my user like so:
>>
>> openssh.authorizedKeys.keys = [ "ssh-rsa stuff" ];
>>
>> the contents of /etc/ssh/authorized_keys.d/anand look like
>>
>> ssh-rsa
>> stuff
>>
>> with a newline after the "ssh-rsa",
>
> Hi Anand,
>
> The implementation looks correct. It only adds newlines between the keys:
>
> https://github.com/NixOS/nixpkgs/blob/75ebc3cf1dc1365be5a05018fc8e5409c66025cb/nixos/modules/services/networking/ssh/sshd.nix#L55
>
> Are you sure your string doesn't contain a newline? Maybe your text
> editor added a newline when it wrapped the string.
>
> Bas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Possible breaking changes from staging

[stewart mackenzie]

Well done Luca! Great work!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Possible breaking changes from staging

[Luca Bruno]

So guys all the stuff quoted below happened, it's all in master. Hopefully
NM 1.0 won't break your desktop too much. In case it does, please report an
issue to nixpkgs. Thanks all for the hard work.

Best regards,

On Wed, Apr 22, 2015 at 11:05 AM, Luca Bruno  wrote:

> In this period I'm working on GNOME 3.16 and NetworkManager 1.0 [1]. In
> addition to that, glib has been bumped.
> I'm currently compiling the PR for staging and then merge it if
> everything works.
>
> Below the possible breakages you must be aware of. These updates are
> necessary to forward our software, we'll fix eventual bugs with the time.
>
> * glib 2.42 -> 2.44
>
> This update is minor yet not entirely trivial. It's probable that
> software using gdbus may break because of bugs fixed in 2.44.
>
> * NM 0.9.8.10 -> 1.0
>
> It's big but shouldn't be breaking anything. In particular, you'll see a
> vboxnet0 interface in nm-applet if you enabled the virtualbox nixos
> service, I hope that will go away with further upstream updates.
>
> We haven't upgraded it until now because previously it showed tons of
> vboxnet interfaces, making the applet unusable.
>
> * GNOME 3.12 -> 3.16
>
> I did my best to keep both 3.12 and 3.16 in our repository, but I won't
> guarantee that 3.12 will keep working as well as before, I won't
> maintain it anymore.
>
> In case you switch to GNOME 3.16, running GTK 3.12 apps will be ugly
> because they broke some css stuff. Therefore I suggest you to add in
> packageOverrides a gnome3 = gnome3_16; and forget about GNOME 3.12, it
> will be dropped as soon as possible.
>
> [1] https://github.com/NixOS/nixpkgs/pull/7357
>
>


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

[Nix-dev] Ctrl-pnfb

[stewart mackenzie]

So after using a mac at work I miss one thing i'd like to do on nix. That
is everywhere (input boxes, browsers, tex editors, IDEs) I can navigate my
cursor using:

-f :forward
-b :backward
-n :next line
-p : previous line

is this possible within nixos? If so, how so?

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

Re: [Nix-dev] haskell dev environment, ghc non-determinism and binary cache interaction

[Peter Simons]

Hi Miguel,

 > package binary-0.7.4.0 is broken due to missing package
 >   array-0.5.0.0-470385a50d2b78598af85cfe9d988e1b,
 >   base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1,
 >   bytestring-0.10.4.0-d6f1d17d717e8652498cab8269a0acd5,
 >   ...

these errors occur sometimes, when Haskell libraries from different
sources are mixed, i.e. some libraries come from hydra.cryp.to, others
from hydra.nixos.org, and some were compiled locally. This is a design
problem in GHC. Check out [1] for further details (including how to
recover from this situation).

 > I have also tried uninstalling everything, garbage collecting and
 > installing again building from source (no binary cache flags), but
 > some package would refuse to build (haskell package she).

Right, "she" doesn't compile:

  src/Imports.lhs:15:19: Not in scope: ‘catch’

If you wouldn't have run into the problem with inconsistent binaries,
then your build would have eventually failed because of this, but you
probably never reached the point where Nix would try to install "she".


 > I wonder how the current installed packages managed to build in the
 > binary cache, but don't build on my machine.

I don't see any successful builds of "she" on hydra.

Best regards,
Peter


[1] https://github.com/NixOS/nixpkgs/issues/7792

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

Re: [Nix-dev] *buildInputs

[Arseniy Seroka]

Thank you!

2015-05-11 15:02 GMT+03:00 Domen Kožar :

> See https://github.com/NixOS/nixpkgs/issues/4855
>
> On Mon, May 11, 2015 at 1:51 PM, Arseniy Seroka 
> wrote:
>
>> What's the difference between nativeBuildInputs, buildInputs and
>> propagatedBuildInputs?
>>
>> --
>> Sincerely,
>> Arseniy Seroka
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>


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

Re: [Nix-dev] A Journey into our brand-new Haskell infrastructure: Part III

[Peter Simons]

Hi Miguel,

 > How does one add older versions of a package to hackage-packages.nix?

the list of "extra packages" is maintained in [1]. If you submit a patch or
pull request, then the additional version will show up in hackage-packages.nix.

Best regards,
Peter

[1] https://github.com/NixOS/cabal2nix/blob/master/src/hackage2nix.hs#L299-329

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

Re: [Nix-dev] *buildInputs

[Domen Kožar]

See https://github.com/NixOS/nixpkgs/issues/4855

On Mon, May 11, 2015 at 1:51 PM, Arseniy Seroka 
wrote:

> What's the difference between nativeBuildInputs, buildInputs and
> propagatedBuildInputs?
>
> --
> 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] *buildInputs

[Arseniy Seroka]

What's the difference between nativeBuildInputs, buildInputs and
propagatedBuildInputs?

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

Re: [Nix-dev] A Journey into our brand-new Haskell infrastructure: Part III

[Miguel Negrão]

Hi

Peter Simons  cryp.to> writes:
> just a quick update for your information: we now have fully automatic updates
> of "hackages-packages.nix". The process is driven by the "update-nixpkgs.sh"
> script [1], which is part of the cabal2nix Git repository [2]. Basically, that
> script re-generates hackages-packages.nix once per hour from the current state
> of Hackage (which [3] tracks in a Git repository) and pushes the result to
[4].
> >From there, Hydra [5] picks up the new version and builds everything.

I see that in hackage-packages.nix there are packages such as
"conduit_1_2_4_1". I have a situation where currently haskell-bytes-0.15
doesn't build on ghc784 and it is needed by linear which is needed by
diagrams. I suppose the way to fix this is to set bytes to 0.14.1.3 in
ghc784 (if that builds). I suppose then that bytes_0_14_1_3 should be added
to hackage-packages.nix, in similar fashion to conduit_1_2_4_1, but that
file is generated automatically. How does one add older versions of a
package to hackage-packages.nix ?

best,
Miguel




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

[Nix-dev] problems with haskell-ng/cabal-install

[Tobias Pflug]

Hi,

I've been facing some problems with haskell-ng and cabal-install.
I would like to use ghc 7.8.4 and cabal-install 1.20.x. I try to
install cabal-install as follows:

   $ nix-env -f ~/nixpkgs -i -A haskell-ng.packages.ghc784.cabal-install

The build fails because of missing dependencies :

[1 of 1] Compiling Main ( Setup.hs, 
/tmp/nix-build-cabal-install-1.20.0.3.drv-0/Main.o )
Linking Setup ...
configuring
configureFlags: --verbose 
--prefix=/nix/store/rzlbizs8c173gby60hvdmhzdln7n60bb-cabal-install-1.20.0.3 
--libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc 
--package-db=/tmp/nix-build-cabal-install-1.20.0.3.drv-0/package.conf.d 
--ghc-option=-optl=-Wl,-rpath=/nix/store/rzlbizs8c173gby60hvdmhzdln7n60bb-cabal-install-1.20.0.3/lib/ghc-7.8.4/cabal-install-1.20.0.3
 
--ghc-option=-j4 --enable-split-objs --disable-library-profiling 
--enable-shared --enable-library-vanilla --enable-executable-dynamic 
--disable-tests
Configuring cabal-install-1.20.0.3...
Setup: At least the following dependencies are missing:
Cabal >=1.20.0 && <1.21, network >=2.0 && <2.6, random >=1 && <1.1
builder for 
‘/nix/store/bjpwinfa70cw6yxvbzxj8qv1zk18iyid-cabal-install-1.20.0.3.drv’ 
failed with exit code 1
error: build of 
‘/nix/store/bjpwinfa70cw6yxvbzxj8qv1zk18iyid-cabal-install-1.20.0.3.drv’ 
failed

What am I doing wrong ? How can I get this to work ?

thanks,
Tobi

PS: I'm running nix on Ubuntu. Tracking nixpkgs via
NixOS/nixpkgs-channels
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Update stable?

[stewart mackenzie]

Thanks Domen for your time, much appreciated!
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Update stable?

[Domen Kožar]

release-14.12 was updated 3 days ago: http://howoldis.herokuapp.com/

I bumped the aborted test in latest kernel update commits, so those should
propagate soonish.

PS: I've been seeing quite some aborted builds lately in all jobsets.

On Mon, May 11, 2015 at 12:44 PM, stewart mackenzie 
wrote:

> When was the last time stable was updated?
> I think things might be getting a tad stale in there.
>
> /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] Update stable?

[stewart mackenzie]

When was the last time stable was updated?
I think things might be getting a tad stale in there.

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

Re: [Nix-dev] sbcl image executables and patch-elf

[Tomas Hlavaty]

Hi Eike,

> I'm making a program in common lisp using sbcl. I then create a
> executable image which results in quite a big file since the whole
> lisp is packaged up. When I use nix to build this app, the file that
> ends up in nix-store is tiny and not working. It seems to me that the
> patch-elf process is stripping things off, but that's just a guess.

try:

   dontStrip = true;

in your build expression.

Cheers,

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

[Nix-dev] sbcl image executables and patch-elf

[Eike]

Hi there,

I'm making a program in common lisp using sbcl. I then create a
executable image which results in quite a big file since the whole lisp
is packaged up. When I use nix to build this app, the file that ends up
in nix-store is tiny and not working. It seems to me that the patch-elf
process is stripping things off, but that's just a guess.

Here is a mini example. Install sbcl and do this

$ echo '(defun main () (format t "Hello World!~%"))' > hello.lisp
$ sbcl --load hello.lisp --eval '(sb-ext:save-lisp-and-die "hello" :toplevel 
(lambda() (main) 0) :executable t)'

then there is a 'hello' executable with about 50mb. Running it prints
the message to stdout.

The same process in a 'hello/default.nix' like this:

{ pkgs ? import  {} }:
pkgs.stdenv.mkDerivation {
  name = "hello-0.0.1";
  src = ./.;
  buildPhase = ''
echo '(defun main () (format t "Hello World!~%"))' > hello.lisp
${pkgs.sbcl}/bin/sbcl --load hello.lisp --eval 
'(sb-ext:save-lisp-and-die "hello" :toplevel (lambda() (main) 0) :executable t)'
ls -lha *
  '';
  installPhase = ''
mkdir -p $out/bin
cp hello $out/bin
  '';
}

Building it with 'nix-build hello' produces this:

these derivations will be built:
  /nix/store/7f6dp34myppgf3r0nfkdcxkinwp81g16-hello-0.0.1.drv
building path(s) ‘/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1’
building /nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
unpacking sources
unpacking source archive /nix/store/dxk9zf3zd78j63g8ysbfsnmwwsf1gb02-hello
source root is hello
patching sources
configuring
no configure script, doing nothing
building
This is SBCL 1.2.5.nixos, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into hello:
writing 5680 bytes from the read-only space at 0x2000
writing 3120 bytes from the static space at 0x2010
writing 50462720 bytes from the dynamic space at 0x10
done]
-rw-r--r-- 1 nixbld1 nixbld 410 May 11 08:11 default.nix
-rwxr-xr-x 1 nixbld1 nixbld 49M May 11 08:11 hello
-rw-r--r-- 1 nixbld1 nixbld  44 May 11 08:11 hello.lisp
installing
post-installation fixup
patching ELF executables and libraries in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1/bin/hello
gzipping man pages in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
stripping (with flags -S) in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1/bin
patching script interpreter paths in 
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1
/nix/store/2rhdmlbiklrrsh660ix0db415xyi46wn-hello-0.0.1

The hello executable was 49M after building it. But the one in nix-store
is this:

l -lha result/bin   

~
insgesamt 272K
dr-xr-xr-x 2 root nixbld 4,0K  1. Jan 1970  .
dr-xr-xr-x 3 root nixbld 4,0K  1. Jan 1970  ..
-r-xr-xr-x 6 root root   262K  1. Jan 1970  hello

What' wrong here?

Thanks in advance!
Eike
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Staging merge will soon happen

[Domen Kožar]

Staging merged into master with --no-ff flag.

I'll stop the current staging jobset and start nixos-combined jobset.

On Mon, May 11, 2015 at 9:13 AM, Vladimír Čunát  wrote:

> On 05/10/2015 11:40 PM, Luca Bruno wrote:
> > It's ok for me except that then people won't have ready binaries for
> > master, which is what staging was meant for.
>
> At this moment I see we have binaries only for ~10k packages on master
> and ~9k packages on staging, so the difference isn't that bad.
>
> http://hydra.nixos.org/project/nixpkgs
>
> 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] Possible bug in ssh key module

[Bas van Dijk]

On 11 May 2015 at 04:45, Anand Patil  wrote:
> Hi everyone,
>
>
> Just wanted to point out a small possible bug in NixOS version
> 15.05pre61966.75ebc3c (Dingo). I noticed that when I add an
> authorizedKeys option to my user like so:
>
> openssh.authorizedKeys.keys = [ "ssh-rsa stuff" ];
>
> the contents of /etc/ssh/authorized_keys.d/anand look like
>
> ssh-rsa
> stuff
>
> with a newline after the "ssh-rsa",

Hi Anand,

The implementation looks correct. It only adds newlines between the keys:

https://github.com/NixOS/nixpkgs/blob/75ebc3cf1dc1365be5a05018fc8e5409c66025cb/nixos/modules/services/networking/ssh/sshd.nix#L55

Are you sure your string doesn't contain a newline? Maybe your text
editor added a newline when it wrapped the string.

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

Re: [Nix-dev] Staging merge will soon happen

[Vladimír Čunát]

On 05/10/2015 11:40 PM, Luca Bruno wrote:
> It's ok for me except that then people won't have ready binaries for
> master, which is what staging was meant for.

At this moment I see we have binaries only for ~10k packages on master
and ~9k packages on staging, so the difference isn't that bad.

http://hydra.nixos.org/project/nixpkgs

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