[Nix-dev] GNU Guix & GuixSD 0.13.0 released

[Ludovic Courtès]

   3  Andy Patterson
 4  Andy Wingo
51  Arun Isaac
 1  Bake Timmons
 5  Ben Sturmfels
57  Ben Woodcroft
 2  Björn Höfling
 1  Boskovits, Gábor
 1  Brandon Ludwig
 3  Brendan Tildesley
17  Carlo Zancanaro
 5  Carlos Sánchez de La Lama
 1  Carolili
 3  Catonano
13  Chris Marusich
12  Christopher Allan Webber
19  Christopher Baines
38  Clément Lassieur
 2  Corentin Bocquillon
 1  Daniel Pimentel
96  Danny Milosavljevic
47  David Craven
10  David Thompson
   209  Efraim Flashner
33  Eric Bavier
 6  Ethan R. Jones
 6  Federico Beffa
 8  Feng Shu
 1  George Clemmer
 1  Gábor Boskovits
22  Hartmut Goebel
 4  Huang Ying
 2  Jan Nieuwenhuizen
 2  Jelle Licht
38  John Darrington
11  José Miguel Sánchez García
   134  Julien Lepiller
59  Kei Kebreau
     4  Kyle Meyer
   393  Leo Famulari
   466  Ludovic Courtès
11  Manolis Ragkousis
   524  Marius Bakke
   184  Mark H Weaver
 2  Mark Meyer
 5  Mathieu Lirzin
 3  Mathieu OTHACEHE
59  Mathieu Othacehe
 9  Maxim Cournoyer
 7  Mekeor Melire
13  Muriithi Frederick Muriuki
13  Nicolas Goaziou
 4  Paul Garlick
 4  Peter Mikkelsen
 5  Petter
 5  Pjotr Prins
46  Raoul Jean Pierre Bonnal
 9  Rene Saavedra
   450  Ricardo Wurmus
 3  Rodger Fox
90  Roel Janssen
12  Sergei Trofimovich
21  Sou Bunnbu (宋文武)
 3  Stefan Reichör
 2  Taylan Ulrich Bayırlı/Kammer
 4  Theodoros Foradis
53  Thomas Danckaert
   295  Tobias Geerinckx-Rice
 4  Troy Sankey
21  Vasile Dumitrascu
 1  Ying Huang
 9  humanitiesNerd
 2  nee
   136  ng0
 2  rsiddharth

Ludovic, on behalf of the Guix team.


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

Re: [Nix-dev] Typing nix − funding campaign

[Ludovic Courtès]

Hello,

Théophane Hufschmitt  skribis:

> Wed 29 Mar 17 − 17:25, Mateusz Kowalczyk(fuuze...@fuuzetsu.co.uk) a écrit:
>> I'm sure you've answered this ad nauseum before but I wonder how you're
>> going to type sets? They are bread-and-butter in nixpkgs. Presumably
>> they will be typed on their fields with the standard subtyping, like
>> anonymous records.
>
> I didn't talk about records, because they are a quite difficult topic,
> and I don't exactly know what their typing will look like in the end.

The problem is that attribute sets are often used like records, but they
are not records at all.  Rather, they’re roughly hash tables where the
key is a string/symbol.

In Guix we use actual records where needed so that we can verify basic
properties at compilation time, such as field names.  Record types are
disjoint from one another, which allows at least for run-time type
checking.

Ludo’.

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

Re: [Nix-dev] Multiple outputs: is a first output necessary?

[Ludovic Courtès]

Hi!

Freddy Rietdijk  skribis:

> I'm using Nix and now also multiple outputs for my data analysis and
> simulations. Many scripts generate several files and instead of having them
> together in the same store path I would prefer to put them in separate
> store paths.
>
> I'm not using any of the common outputs like $out and $bin. The multiple
> outputs feature seems to require that $out is used. Therefore I now just
> put a single file in $out. What is the reason this is needed? I saw in the
> documentation that leftover files are typically put in $out.

Internally the “out” output is not required at all, except for
fixed-output derivations.

The only difference compared to other output names is that it gets
special treatment when computing its store file name (see
‘makeOutputPath’ in store-api.cc.)

Ludo’.

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

Re: [Nix-dev] [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

[Ludovic Courtès]

Hi!

Shea Levy  skribis:

> Your patches look good! My biggest concern is how the ld wrapper behaves
> in the presence of response files. Have you tested that?

It surely doesn’t (yet?).

However, GCC does not pass “@file” arguments when it invokes ‘ld’, and
the bug report you mentioned¹ talks about GHC invoking ‘gcc’, not ‘ld’,
so I guess it’s fine to ignore response files in the ld wrapper.

Ludo’.

¹ 
https://github.com/NixOS/nixpkgs/commit/a421e7bd4a28c69bded8b17888325e31554f61a1
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

[Ludovic Courtès]

Hi Shea,

Shea Levy skribis:

> Unlike the traditional approach of installing system libraries into one
> central location like /usr/{lib,include}, the nix package manager [1]
> installs each package into it's own prefix
> (e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,
> each package is built in its own environment determined from its
> explicitly listed dependencies, regardless of what else is installed on
> the system. Because not all package build scripts properly respect
> CFLAGS etc., we currently wrap the compiler [2] to respect custom
> environment variables like NIX_CFLAGS_COMPILE, so during the build of a
> package that depends on zlib and Xlib might have NIX_CFLAGS_COMPILE set
> to "-isystem 
> /nix/store/bl0rz2xinsm9yslghd7n5vaba86zxknh-libX11-1.6.3-dev/include -isystem 
> /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include".
>
> Unfortunately, as you can see if you click through the link or look
> through the git history, the wrapper is quite complex (frankly, hacky)

> [2]: 
> https://github.com/NixOS/nixpkgs/blob/8cbdd9d0c290e294a9d783c8868e738db05c9ce2/pkgs/build-support/cc-wrapper/cc-wrapper.sh

Guix avoids the compiler wrapper altogether like this:

  • We use C_INCLUDE_PATH, LIBRARY_PATH, and friends:
.

  • We have a simple linker wrapper aimed at adding -Wl,-rpath flags:

.
The comment in that file explains why the other options considered
were unsuitable.

  • We modify the built-in “lib” spec of GCC to add the necessary -L and
-rpath flags:
.

  • Likewise, we tell Clang where to find libc and friends:


.

This is not too intrusive and more robust than wrapping everything.

I suppose GCC and Clang could facilitate this by providing configure
options to augment the “lib” spec, specify the location of libc alone,
or something along these lines.

Thoughts?

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

[Nix-dev] GNU Guix & GuixSD 0.11.0 released

[Ludovic Courtès]

yelp-xsl-3.20.1,
  youtube-dl-2016.07.22, zenity-3.20.0, zeromq-4.0.7, znc-1.6.3, zsh-5.2,
  zynaddsubfx-2.5.4

  ** Programming interfaces

  *** New ‘with-imported-modules’ form provided by (guix gexp)

  It supersedes the #:modules parameter of ‘gexp->derivation’, ‘compute-file’,
  ‘gexp->script’, ‘program-file’, etc, as well as the ‘imported-modules’ fields
  of  and .  See “G-Expressions” in the manual.

  *** New (gnu tests) and (gnu build marionette) modules for system tests

  See <http://savannah.gnu.org/forum/forum.php?forum_id=8605> for background.

  *** New (guix zlib) module
  *** New (guix hg-download) module, for Mercurial checkouts
  *** (guix download) supports HTTP basic authentication
  *** (guix svn-download) supports authentication
  *** The ‘source’ of packages can be a ‘local-file’ or any lowerable object
  *** Part of (guix utils) moved to the new (guix combinators)
  *** GNU updater honors the ‘ftp-server’ and ‘ftp-directory’ package properties
  *** CVE linter honors the ‘cpe-name’ and ‘cpe-version’ package properties
  *** ‘add-to-store’ and ‘local-file’ have a new #:select? parameter

  ** Noteworthy bug fixes

  *** Perl no longer references GCC (<http://bugs.gnu.org/23077>)
  *** Grafting now fails upon I/O errors (<http://bugs.gnu.org/23581>)
  *** GuixSD random source is now properly seeded (<http://bugs.gnu.org/23605>)
  *** ‘call-with-container’ gracefully reports mount errors
  (<http://bugs.gnu.org/23306>)
  *** ‘herd start cow-store’ now bind-mounts the target /tmp
  *** ‘guix environment’ now honors ‘--system’ (<http://bugs.gnu.org/23682>)
  *** ‘guix publish’ properly encodes archive URIs (<http://bugs.gnu.org/21888>)
  *** ‘NIX_CONF_DIR’ is now ignored (<http://bugs.gnu.org/22459>)
  *** The shell of user ‘nobody’ is ‘nologin’ (<http://bugs.gnu.org/23971>)
  *** Source code location is more precise in error messages involving records
  (<http://bugs.gnu.org/23969>)
  *** ‘guix --version’ is correct in the presence of ‘guix pull’
  (<http://bugs.gnu.org/19278>)
  *** Git commits are now signed, for eventual authentication by ‘guix pull’
  (in preparation of a fix for <http://bugs.gnu.org/22883>)

  ** Native language support

  *** New translation: zh_CN (Simplified Chinese)
  *** Updated translations: fr


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

 1  8p8c
 2  Al McElrath
 2  Albin Söderqvist
17  Alex Griffin
77  Alex Kost
16  Alex Sassmannshausen
 2  Alex Vong
 3  Alírio Eyng
29  Andreas Enge
 4  Andy Patterson
 2  Andy Wingo
 2  Ben J Woodcroft
85  Ben Woodcroft
 1  Carlo Zancanaro
 1  Carlos Sánchez de La Lama
 7  Chris Marusich
 2  Christopher Allan Webber
 1  Christopher W. Carpenter
 1  Clément Lassieur
 2  Cyril Roelandt
 2  Daniel Pimentel
15  Danny Milosavljevic
28  David Craven
45  David Thompson
 9  Eelco Dolstra
   391  Efraim Flashner
49  Eric Bavier
 8  Eric Le Bihan
 1  Erik Edrosa
 2  Federico Beffa
 1  Francesco Frassinelli
 1  George Clemmer
10  Hartmut Goebel
16  Jan Nieuwenhuizen
 4  Jelle Licht
 1  Jochem Raat
 8  John Darrington
 1  John J Foerch
 2  John J. Foerch
 1  Jookia
32  Kei Kebreau
   157  Leo Famulari
   350  Ludovic Courtès
 6  Lukas Gradl
 6  Manolis Ragkousis
74  Mark H Weaver
14  Mathieu Lirzin
 8  Matthew Jordan
 3  McKinley Olsen
13  Nicolas Goaziou
 1  Orivej Desh
 2  Patrick Hetu
 2  Peter
 1  Pjotr Prins
 5  Raymond Nicholson
 2  Rene Saavedra
   270  Ricardo Wurmus
 1  Rob Syme
31  Roel Janssen
   222  Sou Bunnbu (宋文武)
 1  Steve Sprang
 4  Taylan Ulrich Bayırlı/Kammer
16  Tobias Geerinckx-Rice
 5  Tomáš Čech
 2  Troy Sankey
 2  Vincent Legoll
 9  humanitiesNerd
 1  myglc2
 1  nee
26  ng0

Ludovic, on behalf of the Guix team.


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] GNU Guix & GuixSD 0.10.0 released

[Ludovic Courtès]

-root-service-type’ can be extended with cross-cutting transformations
  *** ‘package-with-python2’ honors the ‘python2-variant’ package property
  (see <http://bugs.gnu.org/22437>)

  ** Noteworthy bug fixes

  *** Grafts are applied recursively (<http://bugs.gnu.org/22139>)
  *** Commands correctly handle numbers in package names
  (http://bugs.gnu.org/19219)
  *** ‘guix-daemon’ deduplication code detects corrupt items
  *** eudev now populates /dev/disk/by-{id,label}
  *** Selected locale is automatically built (<http://bugs.gnu.org/22572>)
  *** Substitutes can be downloaded over HTTPS (<http://bugs.gnu.org/22937>)
  *** umask explicitly set in /etc/profile (<http://bugs.gnu.org/22650>)
  *** ‘guix system init’ writes GC root on the target file system
  (<http://bugs.gnu.org/22802>)
  *** ‘guix system vm’ now works in the absence of KVM support
  (<http://bugs.gnu.org/22633>)
  *** GuixSD includes an Info reader by default (<http://bugs.gnu.org/22598>)
  *** MacBook keyboards are now properly detected (<http://bugs.gnu.org/20433>)
  *** GRUB searches root by label or UUID (<http://bugs.gnu.org/22281>)
  *** ‘guix package --search-paths’ honors propagated inputs
  (<http://bugs.gnu.org/22073>)
  *** GCC uses ‘C_INCLUDE_PATH’ et al. instead of ‘CPATH’
  (<http://bugs.gnu.org/22186>)
  *** ‘ld-wrapper’ computes library search path based on all ‘-L’ flags
  (<http://bugs.gnu.org/21941>)
  *** ‘guix environment --container’ gracefully handles abnormal exists
  (<http://bugs.gnu.org/21958>)

  ** Native language support

  *** Updated translations: da, de
  *** New translation: pl (Polish)


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

 2  Al McElrath
   137  Alex Kost
 3  Alex Sassmannshausen
 3  Alex Vong
 1  Alírio Eyng
 2  Amirouche Boubekki
63  Andreas Enge
79  Andy Wingo
63  Ben Woodcroft
 3  Chris Marusich
35  Christopher Allan Webber
 1  Christopher Baines
 2  Danny Milosavljevic
 3  David Hashe
56  David Thompson
 1  Dmitry Bogatov
 9  Eelco Dolstra
   360  Efraim Flashner
42  Eric Bavier
 2  Erik Edrosa
10  Fabian Harfert
28  Federico Beffa
 2  Florian Paul Schmidt
 1  George Clemmer
 9  Jan Nieuwenhuizen
 1  Jessica Tallon
 3  Jochem Raat
 1  John Darrington
 1  Jookia
 1  Justus Winter
 2  Kyle Meyer
   198  Leo Famulari
   477  Ludovic Courtès
 1  Lukas Gradl
 2  Manolis Ragkousis
 1  Mario Daniel Ruiz Saavedra
   119  Mark H Weaver
26  Mathieu Lirzin
 1  Michael Vetter
 8  Nils Gillmann
 1  Petter
 8  Pjotr Prins
 2  Raimon Grau
 6  Rene Saavedra
   342  Ricardo Wurmus
 1  Rob Syme
 1  Rodger Fox
10  Roel Janssen
89  Sou Bunnbu (宋文武)
19  Taylan Ulrich Bayırlı/Kammer
 8  Tobias Geerinckx-Rice
 1  Tomáš Čech

Ludovic, on behalf of the Guix team.


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] [PATCH] daemon: Add 'buildMode' parameter to 'buildPaths' RPC.

[Ludovic Courtès]

Shea Levy  skribis:

> Can you resend with paths appropriate to the nix repo? There is no
> nix/ directory there.

Oops, my bad.  I think Eelco solved that already.

Sorry about that!

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

[Nix-dev] [PATCH] daemon: Add 'buildMode' parameter to 'buildPaths' RPC.

[Ludovic Courtès]

* nix/libstore/worker-protocol.hh (PROTOCOL_VERSION): Bump to 0x10f.
* nix/libstore/remote-store.cc (RemoteStore::buildPaths): Send the
BUILDMODE when the daemon supports it.  Reject invalid values of
BUILDMODE for old daemons.
* nix/nix-daemon/nix-daemon.cc (performOp) : Read the
build mode when the client supports it.
---
 nix/libstore/remote-store.cc| 11 +--
 nix/libstore/worker-protocol.hh |  2 +-
 nix/nix-daemon/nix-daemon.cc| 11 ++-
 3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/nix/libstore/remote-store.cc b/nix/libstore/remote-store.cc
index 0539bbe..324ef5e 100644
--- a/nix/libstore/remote-store.cc
+++ b/nix/libstore/remote-store.cc
@@ -462,11 +462,18 @@ Paths RemoteStore::importPaths(bool requireSignature, Source & source)
 
 void RemoteStore::buildPaths(const PathSet & drvPaths, BuildMode buildMode)
 {
-if (buildMode != bmNormal) throw Error("repairing or checking is not supported when building through the Nix daemon");
 openConnection();
 writeInt(wopBuildPaths, to);
-if (GET_PROTOCOL_MINOR(daemonVersion) >= 13)
+if (GET_PROTOCOL_MINOR(daemonVersion) >= 13) {
 writeStrings(drvPaths, to);
+if (GET_PROTOCOL_MINOR(daemonVersion) >= 15) {
+writeInt(buildMode, to);
+}
+/* Old daemons did not take a 'buildMode' parameter, so we need to
+   validate it here on the client side.  */
+else if (buildMode != bmNormal) throw Error("repairing or checking \
+is not supported when building through the Nix daemon");
+}
 else {
 /* For backwards compatibility with old daemons, strip output
identifiers. */
diff --git a/nix/libstore/worker-protocol.hh b/nix/libstore/worker-protocol.hh
index d037d74..7b7be4a 100644
--- a/nix/libstore/worker-protocol.hh
+++ b/nix/libstore/worker-protocol.hh
@@ -6,7 +6,7 @@ namespace nix {
 #define WORKER_MAGIC_1 0x6e697863
 #define WORKER_MAGIC_2 0x6478696f
 
-#define PROTOCOL_VERSION 0x10e
+#define PROTOCOL_VERSION 0x10f
 #define GET_PROTOCOL_MAJOR(x) ((x) & 0xff00)
 #define GET_PROTOCOL_MINOR(x) ((x) & 0x00ff)
 
diff --git a/nix/nix-daemon/nix-daemon.cc b/nix/nix-daemon/nix-daemon.cc
index bd9eebe..c1e697b 100644
--- a/nix/nix-daemon/nix-daemon.cc
+++ b/nix/nix-daemon/nix-daemon.cc
@@ -451,8 +451,17 @@ static void performOp(bool trusted, unsigned int clientVersion,
 
 case wopBuildPaths: {
 PathSet drvs = readStorePaths(from);
+BuildMode mode = bmNormal;
+if (GET_PROTOCOL_MINOR(clientVersion) >= 15) {
+mode = (BuildMode)readInt(from);
+
+	/* Repairing is not atomic, so disallowed for "untrusted"
+	   clients.  */
+if (mode == bmRepair && !trusted)
+throw Error("repairing is not supported when building through the Nix daemon");
+}
 startWork();
-store->buildPaths(drvs);
+store->buildPaths(drvs, mode);
 stopWork();
 writeInt(1, to);
 break;
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] GNU Guix 0.9.0 released

[Ludovic Courtès]

)
  *** Use the daemon's substitute URLs by default (http://bugs.gnu.org/20217)
  *** ‘guix system --no-grub’ works correctly for ‘init’ and ‘reconfigure’
  (http://bugs.gnu.org/21068)

  ** Native language support

  *** Updated translations: da

Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

   106  Alex Kost
 1  Alex Vong
 1  Aljosha Papsch
   102  Andreas Enge
 2  Andy Patterson
17  Andy Wingo
15  Ben Woodcroft
 6  Christopher Allan Webber
41  Cyril Roelandt
 1  Cyrill Schenkel
 1  Daniel Pimentel
74  David Thompson
56  Efraim Flashner
28  Eric Bavier
19  Eric Dvorsak
15  Federico Beffa
 4  Jeff Mickey
 1  Julian Graham
 8  Leo Famulari
   343  Ludovic Courtès
 9  Manolis Ragkousis
 2  Marek Benc
   123  Mark H Weaver
25  Mathieu Lirzin
   170  Paul van der Walt
10  Pjotr Prins
   156  Ricardo Wurmus
17  Siniša Biđin
   140  Sou Bunnbu (宋文武)
 1  Stefan Reichoer
 8  Steve Sprang
 3  Taylan Ulrich Bayırlı/Kammer
21  Vicente Vera Parra
 2  xd1le

Ludovic, on behalf of the Guix team.


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] GNU Guix 0.8.3 released

[Ludovic Courtès]

, openssh-6.9p1,
  openssl-1.0.2d, parallel-20150622, pari-gp-2.7.4, pcre-8.37, perf-4.1.2,
  petsc-3.6.0, petsc-complex-3.6.0, petsc-complex-openmpi-3.6.0,
  petsc-openmpi-3.6.0, pinentry-0.9.5, pius-2.1.1, polkit-0.113,
  postgresql-9.3.8, pspp-0.8.5, pt-scotch-6.0.4, pumpa-0.9.1, python-3.4.3,
  python-dateutil-2.2, python-pillow-2.8.1, python-scikit-learn-0.16.1,
  python2-dateutil-2.2, python2-pillow-2.8.1, python2-pygobject-3.16.1,
  python2-pyqt-5.4, python2-scikit-learn-0.16.1, qemu-2.3.0,
  qemu-headless-2.3.0, qt-5.4.2, r-3.2.1, readline-6.3, ruby-2.1.6, ruby-2.2.2,
  samtools-1.2, scotch-6.0.4, screen-4.3.1, sharutils-4.15.2, sipwitch-1.9.8,
  sqlite-3.8.10.2, star-2.4.2a, swig-3.0.5, synergy-1.7.3, sysfsutils-2.1.0,
  talloc-2.1.2, texinfo-6.0, tor-0.2.6.8, ucommon-6.3.4, unrtf-0.21.9, vamp-2.6,
  webkitgtk-2.8.3, which-2.21, xorriso-1.4.0, youtube-dl-2015.06.25,
  zathura-0.3.3

  ** Programming interfaces

  *** New “package Reference” and “origin Reference” sections in the manual
  *** New ‘emacs-build-system’, which mimics what package.el does
  *** New (guix cpio) module, used to produce Linux initrds deterministically
  *** New ‘clone’, ‘setns’, and ‘pivot_root’ bindings in (guix build syscalls)
  *** New ‘dependencies’ field in file-system
  *** New #:gem-flags parameter for ‘ruby-build-system’
  *** monads: ‘foldm’, ‘mapm’, and ‘anym’ now take a list of regular values
  *** monads: Allow n-ary ‘=’ expressions

  ** Noteworthy bug fixes

  *** Binary installation tarball now has files root-owned, with zeroed mtime
  (http://bugs.gnu.org/21101)
  *** GRUB background image is always available (http://bugs.gnu.org/20591)
  *** ‘guix system’ catches references to non-existent user groups
  (http://bugs.gnu.org/20646)
  *** Ignore trailing components for ‘guix gc -d’ (http://bugs.gnu.org/19757)
  *** ‘guix lint’ warns only when all the URIs are unreachable
  *** ‘guix system init’ overwrites the items in the target store
  (http://bugs.gnu.org/20722)
  *** ‘guix-register’ performs deduplication even when --prefix is passed
  (http://bugs.gnu.org/19044)
  *** The ‘location’ of packages is no longer preserved by ‘inherit’
  *** GuixSD installation image has udev rules for device-mapper
  (http://bugs.gnu.org/20791)
  *** Daemon distinguishes between “substitutable” and “offloadable” derivations
  (http://bugs.gnu.org/18747)
  *** Avoid infinite loop in ‘guix substitute’
  *** ‘guix environment’ now returns the exit code of its command
  *** ‘file-system’ declarations can now really use UUIDs
  (http://bugs.gnu.org/19778)
  *** Daemon preserves build user groups (http://bugs.gnu.org/18994)
  *** Fix quadratic behavior when building packages with many propagated inputs
  *** Tarballs for origins with patches/snippet are now built deterministically
  *** Scalability issues in ‘guix publish’ have been fixed

  ** Native language support

  *** Updated translations: da, eo


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

33  Alex Kost
 1  Alexander Shendi
 2  Amirouche Boubekki
48  Andreas Enge
 1  Andy Patterson
 7  Ben Woodcroft
 4  Christopher Allan Webber
 4  Claes Wallin (韋嘉誠)
 7  Cyril Roelandt
 1  Cyrill Schenkel
 4  David Hashe
45  David Thompson
 6  Efraim Flashner
33  Eric Bavier
 8  Federico Beffa
 1  Jeff Mickey
   283  Ludovic Courtès
 7  Manolis Ragkousis
   175  Mark H Weaver
 7  Mathieu Lirzin
15  Paul van der Walt
 4  Pjotr Prins
91  Ricardo Wurmus
37  Sou Bunnbu (宋文武)
 4  Taylan Ulrich Bayırlı/Kammer

Ludovic, on behalf of the Guix team.


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] [PATCH] Preserve supplementary groups of build users

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

 Currently, the build environment made by the daemon does not preserve
 supplementary groups of the build users.

 Thus, even though the standalone Guix system sets /dev/kvm 660, owned by
 root:kvm, and adds the build users to the kvm group, build users are
 unable to access it.

The following patch is an attempt to address this bug (see
http://bugs.gnu.org/18994) by preserving the supplementary groups of
build users in the build environment.

In practice, I would expect that supplementary groups would contain only
one or two groups: the build users group, and possibly the “kvm” group.

WDYT?

Thanks,
Ludo’.

diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index 85a818b..4644810 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -447,6 +447,7 @@ private:
 string user;
 uid_t uid;
 gid_t gid;
+std::vectorgid_t supplementaryGIDs;
 
 public:
 UserLock();
@@ -460,6 +461,7 @@ public:
 string getUser() { return user; }
 uid_t getUID() { return uid; }
 uid_t getGID() { return gid; }
+std::vectorgid_t getSupplementaryGIDs() { return supplementaryGIDs; }
 
 bool enabled() { return uid != 0; }
 
@@ -539,6 +541,18 @@ void UserLock::acquire()
 throw Error(format(the Nix user should not be a member of `%1%')
 % settings.buildUsersGroup);
 
+	/* Get the list of supplementary groups of this build user.  This
+	   is usually either empty or contains a group such as kvm.  */
+	supplementaryGIDs.resize(10);
+	int ngroups = supplementaryGIDs.size();
+	int err = getgrouplist(pw-pw_name, pw-pw_gid,
+   supplementaryGIDs.at(0), ngroups);
+	if (err == -1)
+		throw Error(format(failed to get list of supplementary groups for `%1')
+			% pw-pw_name);
+
+	supplementaryGIDs.resize(ngroups);
+
 return;
 }
 }
@@ -2179,8 +2193,11 @@ void DerivationGoal::runChild()
 if (buildUser.enabled()) {
 printMsg(lvlChatty, format(switching to user `%1%') % buildUser.getUser());
 
-if (setgroups(0, 0) == -1)
-throw SysError(cannot clear the set of supplementary groups);
+	/* Preserve supplementary groups of the build user, to allow
+	   admins to specify groups such as kvm.  */
+if (setgroups(buildUser.getSupplementaryGIDs().size(),
+			  buildUser.getSupplementaryGIDs().at(0)) == -1)
+throw SysError(cannot set supplementary groups of build user);
 
 if (setgid(buildUser.getGID()) == -1 ||
 getgid() != buildUser.getGID() ||
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [PATCH] Distinguish between “offloadability” and “substitutability”

[Ludovic Courtès]

Hi again,

Nix commit 55586527 (June 2013) changed the semantics of
‘preferLocalBuild’ from “avoid offloading this derivation” to “avoid
offloading *or substituting* this derivation” (see
http://bugs.gnu.org/18747.)

This patch introduces a new special key, ‘substitution’, to specify
whether a derivation should be substituted.  ‘preferLocalBuild’ is kept,
but its initial semantics is restored.

As a consequence, existing uses of ‘preferLocalBuild’ must be audited to
check what exactly is intended.

WDYT?

Thanks,
Ludo’.

diff --git a/nix/libstore/misc.cc b/nix/libstore/misc.cc
index 6ecf878..bdb7a6d 100644
--- a/nix/libstore/misc.cc
+++ b/nix/libstore/misc.cc
@@ -67,6 +67,15 @@ Path findOutput(const Derivation  drv, string id)
 }
 
 
+/* Return true if we are allowed to substitute DRV.  This is the case, unless
+   DRV specifies 'substitution = 0' in its environment.  */
+static bool substitutionAllowed(const Derivation  drv)
+{
+auto env = drv.env;
+auto i = env.find(substitution);
+return i == env.end() || i-second != 0;
+}
+
 void queryMissing(StoreAPI  store, const PathSet  targets,
 PathSet  willBuild, PathSet  willSubstitute, PathSet  unknown,
 unsigned long long  downloadSize, unsigned long long  narSize)
@@ -120,7 +129,7 @@ void queryMissing(StoreAPI  store, const PathSet  targets,
 if (invalid.empty()) continue;
 
 todoDrv.insert(*i);
-if (settings.useSubstitutes  !willBuildLocally(drv))
+if (settings.useSubstitutes  substitutionAllowed(drv))
 query.insert(invalid.begin(), invalid.end());
 }
 
@@ -144,7 +153,7 @@ void queryMissing(StoreAPI  store, const PathSet  targets,
 
 PathSet outputs;
 bool mustBuild = false;
-if (settings.useSubstitutes  !willBuildLocally(drv)) {
+if (settings.useSubstitutes  substitutionAllowed(drv)) {
 foreach (DerivationOutputs::iterator, j, drv.outputs) {
 if (!wantOutput(j-first, i2.second)) continue;
 if (!store.isValidPath(j-second.path)) {
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [PATCH] Preserve supplementary groups of build users

[Ludovic Courtès]

Hi Eelco,

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 01/07/15 11:12, Ludovic Courtès wrote:

 Currently, the build environment made by the daemon does not preserve
 supplementary groups of the build users.

 Thus, even though the standalone Guix system sets /dev/kvm 660, owned by
 root:kvm, and adds the build users to the kvm group, build users are
 unable to access it.
 
 The following patch is an attempt to address this bug (see
 http://bugs.gnu.org/18994) by preserving the supplementary groups of
 build users in the build environment.
 
 In practice, I would expect that supplementary groups would contain only
 one or two groups: the build users group, and possibly the “kvm” group.

 Applied, thanks!

Excellent, thank you!

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

Re: [Nix-dev] [PATCH] Distinguish between “offloadability” and “substitutability”

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 01/07/15 17:21, Ludovic Courtès wrote:

 Nix commit 55586527 (June 2013) changed the semantics of
 ‘preferLocalBuild’ from “avoid offloading this derivation” to “avoid
 offloading *or substituting* this derivation” (see
 http://bugs.gnu.org/18747.)
 
 This patch introduces a new special key, ‘substitution’, to specify
 whether a derivation should be substituted.  ‘preferLocalBuild’ is kept,
 but its initial semantics is restored.

 Have you seen
 https://github.com/NixOS/nix/commit/b64988bb3585478676585a0f0aecbcf4e11d4432,
 which essentially does the same thing?

I hadn’t, but that’s perfect–we’re on the same page.  ;-)

Thanks!

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

Re: [Nix-dev] [PATCH] Add a ‘verifyStore’ RPC

[Ludovic Courtès]

Hello!

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 01/06/15 23:20, Ludovic Courtès wrote:

 The patch below adds a ‘verifyStore’ RPC with the same signature as the
 current LocalStore::verifyStore method.

 Thanks! I've applied this with the following change to disallow repairing by
 unprivileged users (since it's a potentially dangerous operation):

 https://github.com/NixOS/nix/commit/d8ddf994e70f97994e0f1fbd382df93cd071b90f

Sounds good, although I’m unclear on how things could go wrong:
repairing can only rebuild or use approved substitutes, right?

Thank you!

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

[Nix-dev] [PATCH] Add a ‘verifyStore’ RPC

[Ludovic Courtès]

Hello!

The patch below adds a ‘verifyStore’ RPC with the same signature as the
current LocalStore::verifyStore method.

Thanks,
Ludo’.

From aef46c03ca77eb6344f4892672eb6d9d06432041 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= l...@gnu.org
Date: Mon, 1 Jun 2015 23:17:10 +0200
Subject: [PATCH] Add a 'verifyStore' remote procedure call.

---
 src/libstore/remote-store.cc| 10 ++
 src/libstore/remote-store.hh|  1 +
 src/libstore/store-api.hh   |  4 
 src/libstore/worker-protocol.hh |  3 ++-
 src/nix-daemon/nix-daemon.cc| 10 ++
 5 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/libstore/remote-store.cc b/src/libstore/remote-store.cc
index 3b2825c..ab87d9d 100644
--- a/src/libstore/remote-store.cc
+++ b/src/libstore/remote-store.cc
@@ -587,6 +587,16 @@ void RemoteStore::optimiseStore()
 readInt(from);
 }
 
+bool RemoteStore::verifyStore(bool checkContents, bool repair)
+{
+openConnection();
+writeInt(wopVerifyStore, to);
+writeInt(checkContents, to);
+writeInt(repair, to);
+processStderr();
+return readInt(from) != 0;
+}
+
 void RemoteStore::processStderr(Sink * sink, Source * source)
 {
 to.flush();
diff --git a/src/libstore/remote-store.hh b/src/libstore/remote-store.hh
index 14209cb..030120d 100644
--- a/src/libstore/remote-store.hh
+++ b/src/libstore/remote-store.hh
@@ -85,6 +85,7 @@ public:
 
 void optimiseStore();
 
+bool verifyStore(bool checkContents, bool repair);
 private:
 AutoCloseFD fdSocket;
 FdSink to;
diff --git a/src/libstore/store-api.hh b/src/libstore/store-api.hh
index 97a60a6..3764f3e 100644
--- a/src/libstore/store-api.hh
+++ b/src/libstore/store-api.hh
@@ -254,6 +254,10 @@ public:
 /* Optimise the disk space usage of the Nix store by hard-linking files
with the same contents. */
 virtual void optimiseStore() = 0;
+
+/* Check the integrity of the Nix store.  Returns true if errors
+   remain. */
+virtual bool verifyStore(bool checkContents, bool repair) = 0;
 };
 
 
diff --git a/src/libstore/worker-protocol.hh b/src/libstore/worker-protocol.hh
index 4b040b7..d037d74 100644
--- a/src/libstore/worker-protocol.hh
+++ b/src/libstore/worker-protocol.hh
@@ -42,7 +42,8 @@ typedef enum {
 wopQueryValidPaths = 31,
 wopQuerySubstitutablePaths = 32,
 wopQueryValidDerivers = 33,
-wopOptimiseStore = 34
+wopOptimiseStore = 34,
+wopVerifyStore = 35
 } WorkerOp;
 
 
diff --git a/src/nix-daemon/nix-daemon.cc b/src/nix-daemon/nix-daemon.cc
index bed7de0..b3552a9 100644
--- a/src/nix-daemon/nix-daemon.cc
+++ b/src/nix-daemon/nix-daemon.cc
@@ -519,6 +519,16 @@ static void performOp(bool trusted, unsigned int clientVersion,
 writeInt(1, to);
 break;
 
+case wopVerifyStore: {
+	bool checkContents = readInt(from) != 0;
+	bool repair = readInt(from) != 0;
+	startWork();
+	bool errors = store-verifyStore(checkContents, repair);
+	stopWork();
+	writeInt(errors, to);
+	break;
+}
+
 default:
 throw Error(format(invalid operation %1%) % op);
 }
-- 
2.2.1

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

[Nix-dev] GNU Guix 0.8.2 released

[Ludovic Courtès]

, libsigc++-2.4.1, libtasn1-4.5, libtool-2.4.6,
  libunistring-0.9.5, libuv-1.4.2, libvorbis-1.3.5, libxfce4ui-4.12.0,
  libxfce4util-4.12.1, libxfont-1.5.1, lightning-2.1.0, linux-libre-4.0.2,
  linux-libre-headers-3.14.37, llvm-3.6.0, lua-5.2.3, man-pages-3.82,
  mesa-10.5.4, mig-1.5, minetest-0.4.12, moe-1.7, mpc-1.0.3, mpd-0.19.9,
  mu-0.9.12, nano-2.4.1, ncmpcpp-0.6.2, nettle-3.1, nginx-1.8.0, node-0.12.2,
  notmuch-0.19, nspr-4.10.8, nss-3.18, ntp-4.2.8p2, ocrad-0.25, octave-3.8.2,
  openconnect-7.05, openjpeg-2.0.1, openjpeg-2.1.0, openldap-2.4.40,
  openssh-6.8p1, openssl-1.0.2a, pangomm-2.36.0, parallel-20150422,
  pari-gp-2.7.3, patch-2.7.5, perf-4.0.2, perl-libwww-6.13, perl-net-http-6.07,
  perl-net-ssleay-1.68, perl-test-simple-1.001014, perl-uri-1.67,
  pinentry-0.9.0, pius-2.0.11, podofo-0.9.3, poppler-0.32.0, postgresql-9.3.6,
  pulseaudio-6.0, python-3.4.3, python-pillow-2.7.0, python-pygobject-3.16.1,
  python-setuptools-12.1, python-wrapper-3.4.3, python2-dateutil-2.2,
  python2-pillow-2.7.0, python2-pygobject-3.16.1, python2-setuptools-12.1,
  qt-5.4.1, ruby-2.2.2, samba-3.6.25, scons-2.3.4, sdl2-2.0.3, sharutils-4.15.1,
  sipwitch-1.9.7, slock-1.2, source-highlight-3.1.8, sqlite-3.8.9,
  subversion-1.8.13, texinfo-5.2, thunar-1.6.6, thunar-volman-0.8.1,
  tor-0.2.5.12, tumbler-0.1.31, tzdata-2015c, ucommon-6.3.1, vala-0.28.0,
  valgrind-3.10.1, vlc-2.2.0, vte-0.40.0, wget-1.16.3, wine-1.7.40,
  wpa-supplicant-2.4, xboard-4.8.0, xfce4-appfinder-4.12.0, xfce4-panel-4.12.0,
  xfce4-session-4.12.0, xfce4-settings-4.12.0, xfconf-4.12.0, xfdesktop-4.12.0,
  xfwm4-4.12.0, xorg-server-1.16.4, xterm-317

  ** Programming interfaces

  *** New (guix build gremlin) to parse and validate ELF dynamic link info

  *** (guix build-system gnu) has a new ‘validate-runpath’ phase

  This phase reads the dynamic entries of ELF files and reports libraries listed
  as NEEDED that are not found in the RUNPATH.

  *** New (gnu services desktop) module and ‘%desktop-services’ variable

  *** New (guix cvs-download) module, for CVS checkouts

  *** New (guix build-system waf) module, for the Waf build system

  *** New (guix build-system haskell) module, to build Haskell packages

  *** (guix build-system gnu) now supports zip archives

  *** New convenience syntax ‘modify-phases’ added in (guix build utils)

  *** The ‘ld’ wrapper more finely determines whether to use ‘-rpath’

  *** (guix gexp) exports ‘gexp-input’ to describe input unambiguously

  *** The ‘define-gexp-compiler’ form allows (guix gexp) to be extended

  *** New ‘local-file’ constructor exported by (guix gexp)

  ** Noteworthy bug fixes

  *** Profiles created with ‘guix package -p’ as indirect GC roots

  Before that they were made permanent GC roots–i.e., uncollectable.

  *** ‘guix package’ distinguishes downgrades from upgrades

  *** Handle HTTP redirects to relative URI references
  (http://bugs.gnu.org/19840)

  *** Downloads now honor the ‘http_proxy’ environment variable
  (http://bugs.gnu.org/20402)

  *** ‘--no-*’ options are now always correctly handled
  (http://lists.gnu.org/archive/html/guix-devel/2015-02/msg00702.html)

  *** SLiM no longer leaks open file descriptors

  *** Don't compare pam-service objects with 'equal?'
  (http://bugs.gnu.org/20037)

  *** x86_64 and i686 bootstrap binaries updated (http://bugs.gnu.org/19780)

  *** ‘find-files’ no longer follows symlinks (http://bugs.gnu.org/20081)

  *** libc message catalog (‘libc.mo’) is now installed

  *** libstdc++ has appropriate RUNPATH (http://bugs.gnu.org/20358)

  *** ‘dhcp-client-service’ now correctly tracks dhclient’s PID

  ** Native language support

  *** New translations: da (Danish)

  *** Updated translations: eo

Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

11  Alex Kost
 1  Alex Sassmannshausen
 4  Alexander I.Grafov (Axel)
   134  Andreas Enge
22  Andy Wingo
 3  Christopher Allan Webber
 3  Cyril Roelandt
 5  David Hashe
41  David Thompson
   365  Eric Bavier
37  Federico Beffa
12  Jason Self
   460  Ludovic Courtès
 3  Manolis Ragkousis
   182  Mark H Weaver
 2  Mathieu Lirzin
16  Paul van der Walt
 1  Pierre-Antoine Rault
   175  Ricardo Wurmus
 1  Taylan Ulrich B
90  Taylan Ulrich Bayırlı/Kammer
28  Tomáš Čech
 1  nebuli
   146  宋文武

Ludovic, on behalf of the Guix team.


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] GNU Guix 0.8.1 released

[Ludovic Courtès]

 (French), hu (Hungarian)
  *** Updated translation: eo, vi


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

16  Alex Kost
62  Andreas Enge
 1  Cyril Roelandt
 5  David Thompson
31  Eric Bavier
47  Federico Beffa
 8  Jason Self
10  John Darrington
 1  Joshua S. Grant
 5  Julien Lepiller
   326  Ludovic Courtès
 5  Manolis Ragkousis
 1  Marek Benc
   206  Mark H Weaver
19  Ricardo Wurmus
 2  Taylan Ulrich B
 2  Taylan Ulrich Bayırlı/Kammer
 4  Tomáš Čech
 3  nebuli
 2  rekado
48  宋文武

Ludovic, on behalf of the Guix team.


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] Service composition

[Ludovic Courtès]

Ertugrul Söylemez ert...@gmx.de skribis:

 FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’
 function, for instance, returns a ‘service’ object as a monadic value
 (see
 http://www.gnu.org/software/guix/manual/guix.html#Defining-Services
 for details.)

 The way I understand the section on the store monad is that it's really
 a state monad with a view on the current store (they should really show
 the underlying types to make this easier to understand).

Yes.

 What’s unsatisfying (and thus subject to change) is that
 ‘operating-system’ objects (which are pure declarations) end up with
 monadic values in their ‘services’ field.  That makes it inconvenient
 to, say, filter items from that list, or to tweak their configuration,
 because one first needs to bind them.  That said, it’s probably not a
 problem for Nix, because every Nix function is really a function in
 what we call the “store monad”.

 You could think of it that way, if you wanted.  I prefer to think of
 what Nix does as the same magic that functional languages do with other
 resources like memory (alloc and GC).

Sure.  You realize there’s no magic when you actually implement the
store in a general-purpose language.  ;-)

 As a first approximation there would be a Service monoid, which would
 combine certain typical attributes about a service, including startup
 scripts, required bind-mounts, required system resources and if really
 necessary shutdown scripts (most programs should shutdown properly when
 the container goes down).

 Service : Mon

 Its identity idS would be the empty service, which you can think of as
 an empty group of processes with no mounts, no resources, etc.

 The Bitlbee service would be constructed through a regular function that
 takes the typical bitlbee options.  Nothing special here:

 bitlbee : BitlbeeConf - Service

OK.  I suppose ‘Service’ would specify required user accounts, PAM
services, etc., right?

 The nginx function is more interesting.  It involves a second monoid,
 the monoid of web services (identity idW):

 WebService : Mon

 Then nginx is a monoid morphism,

 nginx : WebService - Service

 that is a function with additional structure, in particular:

 nginx x ◇ nginx y ≡ nginx (x ◇ y)
 nginx idW ≡ idS

Very interesting.  I wonder what other types of services would benefit
from similar treatment.

[...]

 I hope this gives a first impression of how everything would fit
 together.

Definitely.  That gives me a fair amount of food for thought.

Thank you!

Ludo’.

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

Re: [Nix-dev] How to get rid of systemd

[Ludovic Courtès]

Ertugrul Söylemez ert...@gmx.de skribis:

 I would prefer and do propose an algebraic solution (view services as a
 toolbox from which you can pick the services you want and compose them
 together).  A services configuration then might look like this:

 services =
 bitlbee { port = 1; stateDir = /var/lib/bitlbee1; } 
 bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; } 
 nginx { httpConfig = ...; } 
 postfix { postMasterAlias = blah; }

 The big difference is that now services are first class values and form
 a monoid under composition, which brings a number of advantages:

FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’
function, for instance, returns a ‘service’ object as a monadic value
(see http://www.gnu.org/software/guix/manual/guix.html#Defining-Services
for details.)

Unlike in NixOS, the service implementation doesn’t have access to the
rest of the system configuration, which I think is a good thing, as you
note.

What’s unsatisfying (and thus subject to change) is that
‘operating-system’ objects (which are pure declarations) end up with
monadic values in their ‘services’ field.  That makes it inconvenient
to, say, filter items from that list, or to tweak their configuration,
because one first needs to bind them.  That said, it’s probably not a
problem for Nix, because every Nix function is really a function in what
we call the “store monad”.

In your example, what would ‘bitlbee’, ‘nginx’ etc. return exactly?  An
attribute set describing the service?

Anyway, I’m interested in following this discussion.

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

Re: [Nix-dev] Avoiding threads in the daemon

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 19/12/14 19:20, Eelco Dolstra wrote:

 I see a few ways to get PID namespaces back:
 
 * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) 
 (after
 which the intermediate process can exit).

 This has been implemented in bd0f362d2fad1dd5f28e762011888b5eabd21280.

OK, thank you!

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

[Nix-dev] Avoiding threads in the daemon

[Ludovic Courtès]

Nix commit 524f89 changed libstore to use fork + unshare instead of
clone(2).  The problem is that, in doing so, it also removed use of
CLONE_NEWPID and thus, (1) the build process no longer has PID 1, and
(2) build processes end up in the global PID space.

Adding CLONE_NEWPID to the unshare(2) call appears to break things (for
instance, future calls to pthread_create by that process fail with
EINVAL, other calls to clone(2) fail with ENOMEN) which may be why
CLONE_NEWPID isn’t used here.

The stated reason for this commit is this:

 commit 524f89f1399724e596f61faba2c6861b1bb7b9c5
 Author: Eelco Dolstra eelco.dols...@logicblox.com
 Date:   Thu Aug 21 14:08:09 2014 +0200

 Use unshare() instead of clone()

 It turns out that using clone() to start a child process is unsafe in
 a multithreaded program. It can cause the initialisation of a build
 child process to hang in setgroups(), as seen several times in the
 build farm:

 The reason is that Glibc thinks that the other threads of the parent
 exist in the child, so in setxid_mark_thread() it tries to get a futex
 that has been acquired by another thread just before the clone(). With
 fork(), Glibc runs pthread_atfork() handlers that take care of this
 (in particular, __reclaim_stacks()). But clone() doesn't do that.

 Fortunately, we can use fork()+unshare() instead of clone() to set up
 private namespaces.

 See also 
https://www.mail-archive.com/lxc-devel@lists.linuxcontainers.org/msg03434.html.

The more general issue is that fork should not be used in a
multi-threaded process, unless the child immediately calls exec* after
fork (POSIX clearly specifies that if a multi-threaded program forks,
the child must only call functions that are async-signal-safe.)  IOW,
the daemon should not use threads in the first place.

Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
uses std::thread just for convenience) should be reverted, along with
the subsequent commits to that file; then commit 524f89 can be reverted.

WDYT?

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

Re: [Nix-dev] Avoiding threads in the daemon

[Ludovic Courtès]

Hi,

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 18/12/14 17:32, Ludovic Courtès wrote:

 Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which
 uses std::thread just for convenience) should be reverted, along with
 the subsequent commits to that file; then commit 524f89 can be reverted.

 I really don't want to get rid of threads because they're useful and I want to
 use them more in the future (e.g. build.cc would be much simpler if it used
 threads rather than the current event-driven approach; nix-daemon could handle
 client connections with a thread rather than a process; etc.).

Hmm, I’m not convinced about the whole threads-for-convenience approach
à la Java.  (I think the ideal is a single-threaded event loop; of
course we want to avoid IoC, and this is where FRP or monads come in.)

 I see a few ways to get PID namespaces back:

 * Do a regular fork followed by clone(... | CLONE_NEWPID | CLONE_PARENT) 
 (after
 which the intermediate process can exit).

Hmm.

 * Call setuid/setgid via syscall() to bypass the locking in the Glibc 
 wrappers.
 However, there might be other problematic functions so this is not a great 
 solution.

Surely.

 * Get the Glibc folks to provide a way to run at-fork handlers with clone().

Hmm.

 Clearly the first option is the easiest.

Yeah.

I think threads are a can of worms anyway and may cause other problems
eventually.

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

Re: [Nix-dev] [PATCH Nix] Flush substituter output upon ‘\r’

[Ludovic Courtès]

Hi Eelco,

I think the patch below fell through the cracks.  ;-)
Is it OK on your side?

Thanks,
Ludo’.

l...@gnu.org (Ludovic Courtès) skribis:

 Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 17/06/14 17:50, Ludovic Courtès wrote:

 The patch below changes the store so that it flushes what it reads from
 the substituter’s stderr when it encounters either a newline or a
 carriage return.
 
 The intent is to allow substituters to provide some kind of progress
 report, where the status is updated by means of a ‘\r’.

 What kind of progress report do you mean, and why wouldn't '\n' work for 
 that?

 Progress reports:

 0%\r
 1%\r
 2%\r

 As a side effect, this patch removes the “substituter-name: ” prefix on
 the lines that are printed.  It can be reinstated if deemed appropriate.

 Please do, without it there is no indication where the error came from.

 Here it is.

 Thanks,
 Ludo’.

 diff --git a/src/libstore/local-store.cc b/src/libstore/local-store.cc
 index 1293a6e..079972c 100644
 --- a/src/libstore/local-store.cc
 +++ b/src/libstore/local-store.cc
 @@ -1141,8 +1141,10 @@ string 
 LocalStore::getLineFromSubstituter(RunningSubstituter  run)
  if (n == 0) throw EndOfFile(format(substituter `%1%' died 
 unexpectedly) % run.program);
  err.append(buf, n);
  string::size_type p;
 -while ((p = err.find('\n')) != string::npos) {
 -printMsg(lvlError, run.program + :  + string(err, 0, p));
 +while (((p = err.find('\n')) != string::npos)
 +|| ((p = err.find('\r')) != string::npos)) {
 + string thing(err, 0, p + 1);
 + writeToStderr(run.program + :  + thing);
  err = string(err, p + 1);
  }
  }
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] GNU Guix 0.8 released

[Ludovic Courtès]

  They implement “grafts”, as described under “Security Updates” in the manual.

  *** New “bag” intermediate representation for use by build systems

  “Bags” are used internally as an intermediate representation between packages
  and derivations.  See “Build Systems” in the manual.

  *** New (guix monad-repl) module, for monadic interaction at the REPL

  See “The Store Monad” in the manual.

  *** New (guix build emacs-utils) module, to facilitate building Emacs packages

  *** New (guix tests) module, with tools used by the test suite

  *** The internal ‘guix-register’ command now deduplicates files in store items

  *** Several system modules moved from (guix build …) to (gnu build …)

  Also, the (gnu build linux-boot) module has been introduced, with code
  typically used by initial RAM disks when booting on GNU/Linux-libre.

  *** (guix profiles) provides a representation of package transactions

  This factorizes code between ‘guix package’ and the Emacs user interface.

  *** Bootstrapping packages moved to (gnu packages commencement) modules

  ** Bugs fixed

  *** ‘guix-daemon’ now really deduplicates store items by default

  Deduplication means that identical files found in /gnu/store are stored only
  once, using hard links.  This feature was wrongfully disabled, and is now
  enabled by default.  The former ‘--disable-store-optimization’ option has been
  renamed to ‘--disable-deduplication’.

  *** ‘guix-daemon’ no longer uses ‘vfork’

  This could cause problems with ancient Linux kernel.

  *** Fixed compilation of ‘gccgo’ (http://bugs.gnu.org/18101)
  *** 'make clean' doesn't delete os-config.tmpl (http://bugs.gnu.org/18243)
  *** Fix handling of periods by fill-paragraph (http://bugs.gnu.org/17468)
  *** Produce a top-level Info 'dir' file (http://bugs.gnu.org/18305)
  *** guix offload ignores unreachable machines (http://bugs.gnu.org/18070)
  *** guix offload: Ignore EEXIST when registering a .drv as a GC root
  (http://bugs.gnu.org/18115)
  *** perl-tk: Build sequentially (http://bugs.gnu.org/18262)
  *** download: Use the 'SERVER NAME' TLS extension when possible
  (http://bugs.gnu.org/18526)
  *** libdaemon: Add alternate source URLs (http://bugs.gnu.org/18639)
  *** icu4c: Reinstate RUNPATH on shared libraries 
  (http://bugs.gnu.org/18695)
  *** nss-mdns: Add alternate source URLs (http://bugs.gnu.org/18704)
  *** download: Add Accept: */* to the HTTP headers
  (http://bugs.gnu.org/18768)
  *** guix-register: Do not attempt to create NIX_STORE_DIR 
  (http://bugs.gnu.org/18689)
  *** Allow Linux-libre to find our 'modprobe' command
  (http://bugs.gnu.org/18525)
  *** man-pages: Build sequentially (http://bugs.gnu.org/18701)
  *** Fix intermittent test failures involving GC (http://bugs.gnu.org/18935)
  *** guix import: pypi: Gracefully handle non-existent packages 
  (http://bugs.gnu.org/18831)
  *** Make sure the shared library has the '.so' extension
  (http://bugs.gnu.org/18521)
  *** pull: Use the build procedure provided by the newly-downloaded Guix.
  (http://bugs.gnu.org/18534)
  *** WindowMaker no longer pollutes $PATH (http://bugs.gnu.org/18698)

  ** Native language support
  *** New translation: cs (Czech)
  *** Updated translations: de, sr, vi


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

61  Alex Kost
55  Andreas Enge
11  Cyril Roelandt
 1  Cyrill Schenkel
49  David Thompson
41  Eric Bavier
 9  Federico Beffa
 1  Guy Grant
 4  Ian Denhardt
20  Jason Self
17  John Darrington
 1  Joshua Grant
 3  Kevin Lemonnier
   412  Ludovic Courtès
 4  Manolis Ragkousis
10  Marek Benc
   105  Mark H Weaver
 1  Mathieu Lirzin
 2  Pjotr Prins
 1  Sylvain Beucler
 1  Taylan Ulrich Bayirli/Kammer
 2  宋文武

Ludovic, on behalf of the Guix team.


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] [PATCH] Add an 'optimiseStore' RPC

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 Looks fine, but it doesn't apply. Can you rebase it on nix master?

Oops, sure.  Here it is.

Thanks,
Ludo’.

From 88ebc46a1216165a015a744e53319f666eb1b1cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= l...@gnu.org
Date: Mon, 1 Sep 2014 22:21:42 +0200
Subject: [PATCH] Add an 'optimiseStore' remote procedure call.

---
 src/libstore/local-store.hh |  3 +++
 src/libstore/optimise-store.cc  | 16 
 src/libstore/remote-store.cc|  7 +++
 src/libstore/remote-store.hh|  4 +++-
 src/libstore/store-api.hh   |  4 
 src/libstore/worker-protocol.hh |  1 +
 src/nix-daemon/nix-daemon.cc|  7 +++
 src/nix-store/nix-store.cc  | 20 +---
 8 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/src/libstore/local-store.hh b/src/libstore/local-store.hh
index e58e656..dccdba5 100644
--- a/src/libstore/local-store.hh
+++ b/src/libstore/local-store.hh
@@ -167,6 +167,9 @@ public:
files with the same contents. */
 void optimiseStore(OptimiseStats  stats);
 
+/* Generic variant of the above method.  */
+void optimiseStore();
+
 /* Optimise a single store path. */
 void optimisePath(const Path  path);
 
diff --git a/src/libstore/optimise-store.cc b/src/libstore/optimise-store.cc
index 208d968..dd18d66 100644
--- a/src/libstore/optimise-store.cc
+++ b/src/libstore/optimise-store.cc
@@ -225,6 +225,22 @@ void LocalStore::optimiseStore(OptimiseStats  stats)
 }
 }
 
+static string showBytes(unsigned long long bytes)
+{
+return (format(%.2f MiB) % (bytes / (1024.0 * 1024.0))).str();
+}
+
+void LocalStore::optimiseStore()
+{
+OptimiseStats stats;
+
+optimiseStore(stats);
+
+printMsg(lvlError,
+format(%1% freed by hard-linking %2% files)
+% showBytes(stats.bytesFreed)
+% stats.filesLinked);
+}
 
 void LocalStore::optimisePath(const Path  path)
 {
diff --git a/src/libstore/remote-store.cc b/src/libstore/remote-store.cc
index 8ef6737..a0e9f22 100644
--- a/src/libstore/remote-store.cc
+++ b/src/libstore/remote-store.cc
@@ -579,6 +579,13 @@ void RemoteStore::clearFailedPaths(const PathSet  paths)
 readInt(from);
 }
 
+void RemoteStore::optimiseStore()
+{
+openConnection();
+writeInt(wopOptimiseStore, to);
+processStderr();
+readInt(from);
+}
 
 void RemoteStore::processStderr(Sink * sink, Source * source)
 {
diff --git a/src/libstore/remote-store.hh b/src/libstore/remote-store.hh
index b010147..98774c1 100644
--- a/src/libstore/remote-store.hh
+++ b/src/libstore/remote-store.hh
@@ -82,7 +82,9 @@ public:
 PathSet queryFailedPaths();
 
 void clearFailedPaths(const PathSet  paths);
-
+
+void optimiseStore();
+
 private:
 AutoCloseFD fdSocket;
 FdSink to;
diff --git a/src/libstore/store-api.hh b/src/libstore/store-api.hh
index b635fee..3109f10 100644
--- a/src/libstore/store-api.hh
+++ b/src/libstore/store-api.hh
@@ -250,6 +250,10 @@ public:
`nix-store --register-validity'. */
 string makeValidityRegistration(const PathSet  paths,
 bool showDerivers, bool showHash);
+
+/* Optimise the disk space usage of the Nix store by hard-linking files
+   with the same contents. */
+virtual void optimiseStore() = 0;
 };
 
 
diff --git a/src/libstore/worker-protocol.hh b/src/libstore/worker-protocol.hh
index c7d3a72..4b040b7 100644
--- a/src/libstore/worker-protocol.hh
+++ b/src/libstore/worker-protocol.hh
@@ -42,6 +42,7 @@ typedef enum {
 wopQueryValidPaths = 31,
 wopQuerySubstitutablePaths = 32,
 wopQueryValidDerivers = 33,
+wopOptimiseStore = 34
 } WorkerOp;
 
 
diff --git a/src/nix-daemon/nix-daemon.cc b/src/nix-daemon/nix-daemon.cc
index ced356c..0f3235d 100644
--- a/src/nix-daemon/nix-daemon.cc
+++ b/src/nix-daemon/nix-daemon.cc
@@ -508,6 +508,13 @@ static void performOp(bool trusted, unsigned int clientVersion,
 break;
 }
 
+case wopOptimiseStore:
+	startWork();
+	store-optimiseStore();
+	stopWork();
+	writeInt(1, to);
+	break;
+
 default:
 throw Error(format(invalid operation %1%) % op);
 }
diff --git a/src/nix-store/nix-store.cc b/src/nix-store/nix-store.cc
index 8c37448..51839fa 100644
--- a/src/nix-store/nix-store.cc
+++ b/src/nix-store/nix-store.cc
@@ -823,16 +823,6 @@ static void opRepairPath(Strings opFlags, Strings opArgs)
 }
 }
 
-
-static void showOptimiseStats(OptimiseStats  stats)
-{
-printMsg(lvlError,
-format(%1% freed by hard-linking %2% files)
-% showBytes(stats.bytesFreed)
-% stats.filesLinked);
-}
-
-
 /* Optimise the disk space usage of the Nix store by hard-linking
files with the same contents. */
 static void opOptimise(Strings opFlags, Strings opArgs)
@@ -840,17 +830,9 @@ static void opOptimise(Strings opFlags, Strings opArgs)
 if (!opArgs.empty() || !opFlags.empty())
 throw UsageError(no arguments expected);
 
-OptimiseStats stats;
-try {

[Nix-dev] [PATCH] Add an 'optimiseStore' RPC

[Ludovic Courtès]

Hi Eelco,

The patch below adds an ‘optimiseStore’ RPC, and thus adds a mandatory
‘optimiseStore’ method in ‘StoreAPI’.

OK to commit?

Ludo’.

diff --git a/src/libstore/local-store.hh b/src/libstore/local-store.hh
index 09639e7..4404ffc 100644
--- a/src/libstore/local-store.hh
+++ b/src/libstore/local-store.hh
@@ -168,6 +168,9 @@ public:
files with the same contents. */
 void optimiseStore(OptimiseStats  stats);
 
+/* Generic variant of the above method.  */
+void optimiseStore();
+
 /* Optimise a single store path. */
 void optimisePath(const Path  path);
 
diff --git a/src/libstore/optimise-store.cc b/src/libstore/optimise-store.cc
index d833f3a..68acb6e 100644
--- a/src/libstore/optimise-store.cc
+++ b/src/libstore/optimise-store.cc
@@ -169,6 +169,24 @@ void LocalStore::optimiseStore(OptimiseStats  stats)
 }
 }
 
+static string showBytes(unsigned long long bytes)
+{
+return (format(%.2f MiB) % (bytes / (1024.0 * 1024.0))).str();
+}
+
+void LocalStore::optimiseStore()
+{
+OptimiseStats stats;
+
+optimiseStore(stats);
+
+printMsg(lvlError,
+format(%1% freed by hard-linking %2% files; there are %3% files with equal contents out of %4% files in total)
+% showBytes(stats.bytesFreed)
+% stats.filesLinked
+% stats.sameContents
+% stats.totalFiles);
+}
 
 void LocalStore::optimisePath(const Path  path)
 {
diff --git a/src/libstore/remote-store.cc b/src/libstore/remote-store.cc
index 4619206..8e1bfdb 100644
--- a/src/libstore/remote-store.cc
+++ b/src/libstore/remote-store.cc
@@ -564,6 +564,13 @@ void RemoteStore::clearFailedPaths(const PathSet  paths)
 readInt(from);
 }
 
+void RemoteStore::optimiseStore()
+{
+openConnection();
+writeInt(wopOptimiseStore, to);
+processStderr();
+readInt(from);
+}
 
 void RemoteStore::processStderr(Sink * sink, Source * source)
 {
diff --git a/src/libstore/remote-store.hh b/src/libstore/remote-store.hh
index 04b60fc..b9b7f7c 100644
--- a/src/libstore/remote-store.hh
+++ b/src/libstore/remote-store.hh
@@ -82,7 +82,9 @@ public:
 PathSet queryFailedPaths();
 
 void clearFailedPaths(const PathSet  paths);
-
+
+void optimiseStore();
+
 private:
 AutoCloseFD fdSocket;
 FdSink to;
diff --git a/src/libstore/store-api.hh b/src/libstore/store-api.hh
index b635fee..3109f10 100644
--- a/src/libstore/store-api.hh
+++ b/src/libstore/store-api.hh
@@ -250,6 +250,10 @@ public:
`nix-store --register-validity'. */
 string makeValidityRegistration(const PathSet  paths,
 bool showDerivers, bool showHash);
+
+/* Optimise the disk space usage of the Nix store by hard-linking files
+   with the same contents. */
+virtual void optimiseStore() = 0;
 };
 
 
diff --git a/src/libstore/worker-protocol.hh b/src/libstore/worker-protocol.hh
index 9317f89..9a3d83a 100644
--- a/src/libstore/worker-protocol.hh
+++ b/src/libstore/worker-protocol.hh
@@ -43,6 +43,7 @@ typedef enum {
 wopQueryValidPaths = 31,
 wopQuerySubstitutablePaths = 32,
 wopQueryValidDerivers = 33,
+wopOptimiseStore = 34
 } WorkerOp;
 
 
diff --git a/src/nix-daemon/nix-daemon.cc b/src/nix-daemon/nix-daemon.cc
index 8814fe3..413db20 100644
--- a/src/nix-daemon/nix-daemon.cc
+++ b/src/nix-daemon/nix-daemon.cc
@@ -650,6 +650,13 @@ static void performOp(bool trusted, unsigned int clientVersion,
 break;
 }
 
+case wopOptimiseStore:
+	startWork();
+	store-optimiseStore();
+	stopWork();
+	writeInt(1, to);
+	break;
+
 default:
 throw Error(format(invalid operation %1%) % op);
 }
diff --git a/src/nix-store/nix-store.cc b/src/nix-store/nix-store.cc
index 341a4f6..e13bfe9 100644
--- a/src/nix-store/nix-store.cc
+++ b/src/nix-store/nix-store.cc
@@ -798,17 +798,6 @@ static void opRepairPath(Strings opFlags, Strings opArgs)
 }
 
 
-static void showOptimiseStats(OptimiseStats  stats)
-{
-printMsg(lvlError,
-format(%1% freed by hard-linking %2% files; there are %3% files with equal contents out of %4% files in total)
-% showBytes(stats.bytesFreed)
-% stats.filesLinked
-% stats.sameContents
-% stats.totalFiles);
-}
-
-
 /* Optimise the disk space usage of the Nix store by hard-linking
files with the same contents. */
 static void opOptimise(Strings opFlags, Strings opArgs)
@@ -816,17 +805,9 @@ static void opOptimise(Strings opFlags, Strings opArgs)
 if (!opArgs.empty() || !opFlags.empty())
 throw UsageError(no arguments expected);
 
-OptimiseStats stats;
-try {
-ensureLocalStore().optimiseStore(stats);
-} catch (...) {
-showOptimiseStats(stats);
-throw;
-}
-showOptimiseStats(stats);
+store-optimiseStore();
 }
 
-
 static void opQueryFailedPaths(Strings opFlags, Strings opArgs)
 {
 if (!opArgs.empty() || !opFlags.empty())
___
nix-dev mailing list
nix-dev@lists.science.uu.nl

[Nix-dev] GNU Guix 0.7 released

[Ludovic Courtès]

, attica, babl, barcode, behave, btar, busybox, ccache, ccrtp,
  chess, clucene, cmatrix, commoncpp, conkeror, cook, cssc, datamash, diffstat,
  doxygen, dropbear, dtach, duplicity, e2fsck-static, exosip, fftw-openmpi,
  fish, gconf, gegl, gimp, gmsh, gnome-mime-data, gnome-vfs, gnumeric, goffice,
  gsegrafix, guile-opengl, guile-static-stripped, hdup, hwloc, inotify-tools,
  jrnl, kbd, kmod, lftp, libarchive, libart-lgpl, libbonobo, libbonoboui,
  libcroco, libdbusmenu-qt, libftdi, libglade, libgnome, libgnomecanvas,
  libgnomeprint, libgnomeprintui, libgnomeui, libgsf, libidl, libmcrypt,
  libmhash, librsvg, librsync, libsodium, libuv, libvpx, links, lzop, man-pages,
  maxima, mcrypt, mosh, mpg123, mplayer, mu, ncmpcpp, node, notmuch, numactl,
  offlineimap, openmpi, orbit2, osip, pangox-compat, perl-io-tty, petsc,
  petsc-complex, petsc-complex-openmpi, petsc-openmpi, pingus, podofo, protobuf,
  pt-scotch, python-enum34, python-keyring, python-lockfile, python-mock,
  python-parse, python-parse-type, python-parsedatetime, python-pycrypto,
  python-six, python-tzlocal, python2-lockfile, python2-mock, qjson, qrencode,
  rasqal, rdiff-backup, rdup, redland, rottlog, scotch, sipwitch, sshfs-fuse,
  strigi, sudo, superlu, superlu-dist, talkfilters, talloc, tcpdump, tinyproxy,
  transmission, ucommon, udev, vlc, vtk, wakelan, wireless-tools,
  wpa-supplicant, xboard, youtube-dl

  *** 87 package updates

  bitlbee-3.2.2, cursynth-1.5, ddrescue-1.18.1, dfc-3.0.4, dmd-0.2,
  docbook-xml-4.3, docbook-xml-4.4, docbook-xsl-1.78.1, dvdisaster-0.72.6,
  ffmpeg-2.3, fftw-3.3.4, fftwf-3.3.4, flac-1.3.0, gawk-4.1.1, gcc-4.7.4,
  gcc-4.8.3, gcc-4.8.3, gcc-4.9.1, gcc-cross-mips64el-linux-gnuabi64-4.8.3,
  gcc-objc++-4.8.3, gcc-objc-4.8.3, gcc-stripped-tarball-4.8.3,
  gcc-toolchain-4.8.3, gcc-toolchain-4.9.1, gccgo-4.8.3, gdb-7.7.1,
  gettext-0.19.2, gfortran-4.8.3, glib-2.40.0, global-6.3, gmp-6.0.0a,
  gnupg-1.4.18, gnupg-2.0.25, gnutls-3.2.15, gp2c-0.0.9pl1, grep-2.20,
  gst-plugins-base-1.0.10, gstreamer-0.10.36, gtk+-3.10.1, gtkmm-2.24.2,
  guile-2.0.11, guile-2.0.11, guix-0.6, guix-0.6.0ae8c15, htop-1.0.3,
  icu4c-53.1, imagemagick-6.8.9-0, json-c-0.12, libdrm-2.4.33, libgc-7.2e,
  libgcrypt-1.5.3, libgpg-error-1.13, libjpeg-8d, libmicrohttpd-0.9.37,
  libogg-1.3.2, libotr-4.0.0, libtasn1-3.6, libvorbis-1.3.4, lightning-2.0.4,
  linux-libre-3.15.6, lua-5.1.5, lua-5.2.3, mcron-1.0.8, moe-1.6, nano-2.3.6,
  neon-0.29.6, nettle-3.0, openssl-1.0.1h, parallel-20140722, pari-gp-2.7.1,
  pspp-0.8.3, python-2.7.6, python-dateutil-2.2, python2-dateutil-2.2,
  qemu-2.0.0, qemu-headless-2.0.0, qt-4.8.6, qt-5.2.1, readline-6.2,
  screen-4.2.1, soprano-2.9.4, texinfo-5.2, texlive-2014, tor-0.2.4.22,
  wdiff-1.2.2, xorriso-1.3.8, xterm-304

  ** Native language support
  *** New translations: de (German), and hu (Hungarian)
  *** Updated translations: eo, pt_BR, sr, vi
  *** Package descriptions moved from the ‘guix’ text domain to ‘guix-packages’
  ** Bugs fixed
  *** Downloads are now faster (http://bugs.gnu.org/15368)
  *** ‘guix authenticate’ properly writes signatures to stdout
  (http://bugs.gnu.org/17312)
  *** Progress report of downloads is now properly displayed
  *** Error reporting of pk-crypto errors has been improved
  *** The 'patches' field now works for origins with no extension
  *** Synchronization and GC issues fixed in the offload hook
  *** (guix ftp-client) emits USER commands suitable for all servers


Please report bugs to bug-g...@gnu.org.
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

 3  Alírio Eyng
49  Andreas Enge
 2  Cyril Roelandt
 4  Cyrill Schenkel
14  David Thompson
58  Eric Bavier
12  Jason Self
29  John Darrington
   474  Ludovic Courtès
 2  Manolis Ragkousis
11  Mark H Weaver
 1  Nikita Karetnikov
 1  Taylan Ulrich Bayirli/Kammer

Ludovic, on behalf of the Guix team.


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] rebuild impact factor

[Ludovic Courtès]

Florian Friesdorf f...@chaoflow.net skribis:

 it would be nice if github would show a rebuild impact factor?

In the old days, Nicolas Pierron wrote a script that attempted to
compute that factor, maintainers/scripts/rebuild-amount.sh.

Ludo’.

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

Re: [Nix-dev] [PATCH Nix] Flush substituter output upon ‘\r’

[Ludovic Courtès]

Hi,

Please use reply-to-all.

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 17/06/14 17:50, Ludovic Courtès wrote:

 The patch below changes the store so that it flushes what it reads from
 the substituter’s stderr when it encounters either a newline or a
 carriage return.
 
 The intent is to allow substituters to provide some kind of progress
 report, where the status is updated by means of a ‘\r’.

 What kind of progress report do you mean, and why wouldn't '\n' work for that?

Progress reports:

0%\r
1%\r
2%\r

 As a side effect, this patch removes the “substituter-name: ” prefix on
 the lines that are printed.  It can be reinstated if deemed appropriate.

 Please do, without it there is no indication where the error came from.

Here it is.

Thanks,
Ludo’.

diff --git a/src/libstore/local-store.cc b/src/libstore/local-store.cc
index 1293a6e..079972c 100644
--- a/src/libstore/local-store.cc
+++ b/src/libstore/local-store.cc
@@ -1141,8 +1141,10 @@ string LocalStore::getLineFromSubstituter(RunningSubstituter  run)
 if (n == 0) throw EndOfFile(format(substituter `%1%' died unexpectedly) % run.program);
 err.append(buf, n);
 string::size_type p;
-while ((p = err.find('\n')) != string::npos) {
-printMsg(lvlError, run.program + :  + string(err, 0, p));
+while (((p = err.find('\n')) != string::npos)
+		   || ((p = err.find('\r')) != string::npos)) {
+	string thing(err, 0, p + 1);
+	writeToStderr(run.program + :  + thing);
 err = string(err, p + 1);
 }
 }
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [PATCH Nix] Flush substituter output upon ‘\r’

[Ludovic Courtès]

The patch below changes the store so that it flushes what it reads from
the substituter’s stderr when it encounters either a newline or a
carriage return.

The intent is to allow substituters to provide some kind of progress
report, where the status is updated by means of a ‘\r’.

As a side effect, this patch removes the “substituter-name: ” prefix on
the lines that are printed.  It can be reinstated if deemed appropriate.

WDYT?

Thanks,
Ludo’.

diff --git a/src/libstore/local-store.cc b/src/libstore/local-store.cc
index 1293a6e..2819843 100644
--- a/src/libstore/local-store.cc
+++ b/src/libstore/local-store.cc
@@ -1141,8 +1141,10 @@ string LocalStore::getLineFromSubstituter(RunningSubstituter  run)
 if (n == 0) throw EndOfFile(format(substituter `%1%' died unexpectedly) % run.program);
 err.append(buf, n);
 string::size_type p;
-while ((p = err.find('\n')) != string::npos) {
-printMsg(lvlError, run.program + :  + string(err, 0, p));
+while (((p = err.find('\n')) != string::npos)
+		   || ((p = err.find('\r')) != string::npos)) {
+	string thing(err, 0, p + 1);
+	writeToStderr(thing);
 err = string(err, p + 1);
 }
 }
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Porting Nix to [Open]BSD

[Ludovic Courtès]

Manuel Pages amarr.industr...@gmail.com skribis:

 The problem I had with autotools is that autoconfigure of nix doesn't
 recognize bzip2 library on non-Linux platforms which is kinda sad
 because it's exactly what autoconfigure should do — configure the
 project to work across POSIX systems :)

(I assume you’re talking about the ‘configure’ script.)  The
‘config.log’ files should contain details about why detection of libbz2
failed.

HTH,
Ludo’.

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

Re: [Nix-dev] [PATCH] Allow roots to refer to arbitrary files in the store

[Ludovic Courtès]

Shea Levy s...@shealevy.com skribis:

 On Mon, Apr 14, 2014 at 04:59:15PM +0200, Ludovic Courtès wrote:
 l...@gnu.org (Ludovic Courtès) skribis:
 
  Shea Levy s...@shealevy.com skribis:
 
  On Mon, Apr 14, 2014 at 03:38:01PM +0200, Ludovic Courtès wrote:
  The patch below allows files such as /nix/store/foo to be protected from
  GC if a root refers to them.  This makes it easy for a build hook to use
  such files for its temporary working files.
  
  WDYT?
  
 
  It seems a bit odd to me to be using the store as a temporary file
  location. What's wrong with $TMPDIR?
 
  Well, this is useful for build hooks, because it guarantees that any
  garbage they leave there will eventually be reclaimed.
 
 It also guarantees that this thing lives on the same file system as the
 store, which means that rename(2) can be used to move it to its final
 location in the store.
 

 Hmm using the store as an auto-collected $TMPDIR seems wrong, but this
 is a decent argument. Do you have a specific use case already planned?

Yup, the build hook, as I wrote (specifically, for the temporary it uses
when restoring from a Nar.)

The other option is to use the temporary root file (that’s what
build-remote.pl does.)  That’s nice, but it requires exposing a lot of
implementation details (GC lock, GC roots directory, etc.)

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

Re: [Nix-dev] [PATCH] Allow roots to refer to arbitrary files in the store

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 14/04/14 16:59, Ludovic Courtès wrote:

 The patch below allows files such as /nix/store/foo to be protected from
 GC if a root refers to them.  This makes it easy for a build hook to use
 such files for its temporary working files.

 WDYT?

 It seems a bit odd to me to be using the store as a temporary file
 location. What's wrong with $TMPDIR?

 Well, this is useful for build hooks, because it guarantees that any
 garbage they leave there will eventually be reclaimed.
 
 It also guarantees that this thing lives on the same file system as the
 store, which means that rename(2) can be used to move it to its final
 location in the store.

 The problem with your patch is that those roots don't get cleaned up
 automatically.  A better solution is to generalize the handling of temporary
 store paths like lock files and chroot directories; check out the calls to
 isActiveTempFile() in tryToDelete() in gc.cc. Those don't get deleted while 
 the
 associated build is still running, but do get deleted afterwards.

Hmm yes, I know.

I wanted to avoid going at lengths to expose all that but OK.  That
raises the barrier for build hook implementors...

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

Re: [Nix-dev] [PATCH] Allow roots to refer to arbitrary files in the store

[Ludovic Courtès]

(Oops, forgot the Subject line; sorry!)

Shea Levy s...@shealevy.com skribis:

 On Mon, Apr 14, 2014 at 03:38:01PM +0200, Ludovic Courtès wrote:
 The patch below allows files such as /nix/store/foo to be protected from
 GC if a root refers to them.  This makes it easy for a build hook to use
 such files for its temporary working files.
 
 WDYT?
 

 It seems a bit odd to me to be using the store as a temporary file
 location. What's wrong with $TMPDIR?

Well, this is useful for build hooks, because it guarantees that any
garbage they leave there will eventually be reclaimed.

 diff --git a/src/libstore/gc.cc b/src/libstore/gc.cc
 index 96e891f..299bf5f 100644
 --- a/src/libstore/gc.cc
 +++ b/src/libstore/gc.cc
 @@ -287,10 +287,7 @@ static void foundRoot(StoreAPI  store,
  const Path  path, const Path  target, Roots  roots)
  {
  Path storePath = toStorePath(target);
 -if (store.isValidPath(storePath))

 Hm, don't we at least want to check that it's in the store at all?

‘toStorePath’ does that:

if (!isInStore(path))
throw Error(format(path `%1%' is not in the Nix store) % path);

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

Re: [Nix-dev] [PATCH] Allow roots to refer to arbitrary files in the store

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

 Shea Levy s...@shealevy.com skribis:

 On Mon, Apr 14, 2014 at 03:38:01PM +0200, Ludovic Courtès wrote:
 The patch below allows files such as /nix/store/foo to be protected from
 GC if a root refers to them.  This makes it easy for a build hook to use
 such files for its temporary working files.
 
 WDYT?
 

 It seems a bit odd to me to be using the store as a temporary file
 location. What's wrong with $TMPDIR?

 Well, this is useful for build hooks, because it guarantees that any
 garbage they leave there will eventually be reclaimed.

It also guarantees that this thing lives on the same file system as the
store, which means that rename(2) can be used to move it to its final
location in the store.

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

Re: [Nix-dev] GNU Guix 0.6 released

[Ludovic Courtès]

(Stripping Cc.)

Shea Levy s...@shealevy.com skribis:

 On Wed, Apr 09, 2014 at 08:29:25PM +0200, Ludovic Courtès wrote:

[...]

 • About
 
   GNU Guix is the functional package manager for the GNU system
   distribution.
 
   In addition to standard package management features, Guix supports
   transactional upgrades and roll-backs, unprivileged package
   management, per-user profiles, and garbage collection.  Guix uses
   low-level mechanisms from the Nix package manager, with Guile Scheme
   programming interfaces.
 
   At this stage Guix can be used on top of an i686, x86_64, or mips64el
   GNU/Linux system, or in a virtual machine.  Future versions will
   stand alone.
 

 My brain keeps parsing this as guix will run on bare metal, what does
 stand alone mean here?

It means there’ll be a standalone distro, like NixOS.  I suppose the
wording could be improved.

 • Changes since version 0.5 (excerpt from the NEWS file)
 
   ** Package management
   *** Default store directory changed to /gnu/store
 

 What was the motivation behind this change?

Marketing of course!  ;-)

For newcomers it may clarify the fact that it’s a distro different from
Nixpkgs, with different goals.

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

Re: [Nix-dev] Unfree packages in Nixpkgs

[Ludovic Courtès]

While we’re at sharing links ;-), I would instead recommend Appelbaum’s
LibrePlanet keynote on this topic:

  
https://media.libreplanet.org/u/zakkai/m/free-software-for-freedom-surveillance-and-you/

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

Re: [Nix-dev] [PATCH] Make sure /dev/pts/ptmx is world-writable

[Ludovic Courtès]

Hello!

Lluís Batlle i Rossell vi...@viric.name skribis:

 On Wed, Apr 02, 2014 at 11:41:11PM +0200, Ludovic Courtès wrote:
 Hello,
 
 While running Python 3’s test suite, we noticed that on some systems
 /dev/pts/ptmx is created with permissions 0 (that’s the case with my
 Nixpkgs-originating 3.0.43 kernel, but someone with a Debian-originating
 3.10-3 reported not having this problem.)

Actually the doc confirms that:

  https://www.kernel.org/doc/Documentation/filesystems/devpts.txt

 There’s still the problem that people without
 CONFIG_DEVPTS_MULTIPLE_INSTANCES=y are screwed (as noted in build.cc),
 but I don’t see how we could work around it.
 
 Thoughts?
 
 Ludo’.

 Usually it's handled with the devpts special mountable device. The
 ptmxmode variable handles that. Don't you want to mount that in the
 chroot?

We do want to mount /dev/pts, yes.  What’s the ‘ptmxmode variable’?

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

Re: [Nix-dev] [PATCH] Make sure /dev/pts/ptmx is world-writable

[Ludovic Courtès]

Lluís Batlle i Rossell vi...@viric.name skribis:

 Usually it's handled with the devpts special mountable device. The
 ptmxmode variable handles that. Don't you want to mount that in the
 chroot?

Ah sorry, I see the ptmxmode mount option:

  https://www.kernel.org/doc/Documentation/filesystems/devpts.txt

Well it seems both chmod and that mount option would work, but the
ptmxmode option is marked as “new” in the doc above, so maybe it’s safer
to use chmod?

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

[Nix-dev] [PATCH] Make sure /dev/pts/ptmx is world-writable

[Ludovic Courtès]

Hello,

While running Python 3’s test suite, we noticed that on some systems
/dev/pts/ptmx is created with permissions 0 (that’s the case with my
Nixpkgs-originating 3.0.43 kernel, but someone with a Debian-originating
3.10-3 reported not having this problem.)

There’s still the problem that people without
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y are screwed (as noted in build.cc),
but I don’t see how we could work around it.

Thoughts?

Ludo’.

diff --git a/src/libstore/build.cc b/src/libstore/build.cc
index e846995..53a92c1 100644
--- a/src/libstore/build.cc
+++ b/src/libstore/build.cc
@@ -2079,6 +2079,10 @@ void DerivationGoal::initChild()
 if (mount(none, (chrootRootDir + /dev/pts).c_str(), devpts, 0, newinstance,mode=0620) == -1)
 throw SysError(mounting /dev/pts);
 createSymlink(/dev/pts/ptmx, chrootRootDir + /dev/ptmx);
+
+		/* Make sure /dev/pts/ptmx is world-writable.  With some
+		   Linux versions, it is created with permissions 0.  */
+		chmod_(chrootRootDir + /dev/pts/ptmx, 0666);
 }
 
 /* Do the chroot().  Below we do a chdir() to the
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NiJS package manager

[Ludovic Courtès]

Hi Sander!

Sander van der Burg - EWI s.vanderb...@tudelft.nl skribis:

 After a year of hard work, I proudly want to present you NiJS: the
 asynchronous package manager.

 In NiJS, you can use the more popular, innovating and future proof
 JavaScript language to specify package build specifications while
 still having most of the useful goodies that Nix has.

I’m glad to see a synergy around JavaScript!

  https://lists.gnu.org/archive/html/guix-devel/2014-04/msg0.html

I imagine we can share efforts between both projects?

Ludo’.

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

[Nix-dev] ‘boost::too_few_args’ in ‘getLineFromSubstituter’

[Ludovic Courtès]

Hi,

In some cases (substituter error), I’m getting this:

  unexpected Nix daemon error: boost::too_few_args: format-string refered to 
more arguments than were passed

After replacing the ‘throw’ with ‘abort’ in format_implementation.cc, I
was able to get a backtrace:

--8---cut here---start-8---
(gdb) bt
#0  0x7fe60908d409 in raise () from 
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libc.so.6
#1  0x7fe60908e808 in abort () from 
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libc.so.6
#2  0x0047aac2 in boost::basic_format::str 
(this=this@entry=0x7a463b40) at 
nix/boost/format/format_implementation.cc:164
#3  0x0047594c in nix::printMsg_ (level=level@entry=nix::lvlError, 
f=...) at nix/libutil/util.cc:455
#4  0x00426ba4 in nix::LocalStore::getLineFromSubstituter 
(this=this@entry=0xc7f500, run=...) at nix/libstore/local-store.cc:1145
#5  0x0042ccf0 in nix::LocalStore::querySubstitutablePaths 
(this=0xc7f500, paths=...) at nix/libstore/local-store.cc:1193
#6  0x004090c5 in performOp (from=..., to=..., op=32, 
clientVersion=optimized out, trusted=false) at 
nix/nix-daemon/nix-daemon.cc:332
#7  processConnection (trusted=trusted@entry=false) at 
nix/nix-daemon/nix-daemon.cc:730
#8  0x0040dc94 in daemonLoop () at nix/nix-daemon/nix-daemon.cc:904
#9  0x0040e5b1 in run (args=...) at nix/nix-daemon/nix-daemon.cc:929
#10 0x00406dc1 in main (argc=optimized out, argv=optimized out) at 
nix/nix-daemon/guix-daemon.cc:325
(gdb) bt full
#0  0x7fe60908d409 in raise () from 
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libc.so.6
No symbol table info available.
#1  0x7fe60908e808 in abort () from 
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libc.so.6
No symbol table info available.
#2  0x0047aac2 in boost::basic_format::str 
(this=this@entry=0x7a463b40) at 
nix/boost/format/format_implementation.cc:164
sz = optimized out
i = optimized out
res = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, 
_M_p = 0xcfd308 1724: 13 [%start-stack load-stack #procedure 
9ee040 at ice-9/boot-9.scm:4041:10 ()]\n}}
__PRETTY_FUNCTION__ = std::string boost::basic_format::str() const
#3  0x0047594c in nix::printMsg_ (level=level@entry=nix::lvlError, 
f=...) at nix/libutil/util.cc:455
prefix = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, 
_M_p = 0x6ad8d8 
std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24 }}
s = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, _M_p = 0x49 error: Cannot access memory at 
address 0x49}}
#4  0x00426ba4 in nix::LocalStore::getLineFromSubstituter 
(this=this@entry=0xc7f500, run=...) at nix/libstore/local-store.cc:1145
buf = 1724: 13 [%start-stack load-stack #procedure 9ee040 at 
ice-9/boot-9.scm:4041:10 
()]\n\343ζ\270\066\231\307\376\253*\373U\360\357ZG\335\300\301\350=\032ӱ\230\250)\241b\034\342lO\317H\345,\035\031O%j[\336uc\341\301\364%E6\242\024$@(\001D\021\304\342\033\270GD?\222Jw=҂`\243\000\213\206\353\035rs\331\377\353D\365߃m\031\252u\366\344\256\fhz\240ȺZz\313\017s\365!\257K)\021\t7\005c\267...
n = optimized out
p = 85
fds = {fds_bits = {16384, 0 repeats 15 times}}
res = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, 
_M_p = 0x6ad8d8 
std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24 }}
err = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, 
_M_p = 0xcfd308 1724: 13 [%start-stack load-stack #procedure 
9ee040 at ice-9/boot-9.scm:4041:10 ()]\n}}
#5  0x0042ccf0 in nix::LocalStore::querySubstitutablePaths 
(this=0xc7f500, paths=...) at nix/libstore/local-store.cc:1193
path = {static npos = optimized out, _M_dataplus = 
{std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, 
_M_p = 0x6ad8d8 
std::string::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4+24 }}
run = @0xcead48: {program = {static npos = optimized out, _M_dataplus 
= {std::allocatorchar = {__gnu_cxx::new_allocatorchar = {No data 
fields}, No data fields}, _M_p = 0xcb8938 substitute-binary}}, 
  pid = {pid = 14286, separatePG = false, killSignal = 9}, to = {fd = 
11}, from = {fd = 12}, error = {fd = 14}, fromBuf = {nix::BufferedSource = 
{nix::Source = {
_vptr.Source = 0x492e70 vtable for nix::FdSource+16}, bufSize 
= 32768, bufPosIn = 0, bufPosOut = 0, buffer = 0xd2d620 

Re: [Nix-dev] [PATCH] Making /dev/kvm optional

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

 The daemon now creates /dev deterministically (thanks!).  However, it
 expects /dev/kvm to be present.

 The patch below restricts that requirement (1) to Linux-based systems,
 and (2) to systems where /dev/kvm already exists.

The patch is in:

  https://github.com/NixOS/nix/commit/24cb65efc3c34e24fc653779a4d42cf4f31c6737

Thanks!

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

[Nix-dev] [PATCH] Making /dev/kvm optional

[Ludovic Courtès]

Hello,

The daemon now creates /dev deterministically (thanks!).  However, it
expects /dev/kvm to be present.

The patch below restricts that requirement (1) to Linux-based systems,
and (2) to systems where /dev/kvm already exists.

I’m not sure about the way to handle (2).  We could special-case
/dev/kvm and create it (instead of bind-mounting it) in the chroot, so
it’s always available; however, it wouldn’t help much since most likely,
if /dev/kvm missing, then KVM support is missing.

Thoughts?

Thanks,
Ludo’.

diff --git a/src/libstore/build.cc b/src/libstore/build.cc
index 973e7a1..e846995 100644
--- a/src/libstore/build.cc
+++ b/src/libstore/build.cc
@@ -2020,7 +2020,10 @@ void DerivationGoal::initChild()
 createDirs(chrootRootDir + /dev/pts);
 Strings ss;
 ss.push_back(/dev/full);
-ss.push_back(/dev/kvm);
+#ifdef __linux__
+if (pathExists(/dev/kvm))
+ss.push_back(/dev/kvm);
+#endif
 ss.push_back(/dev/null);
 ss.push_back(/dev/random);
 ss.push_back(/dev/tty);
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [PATCH] Allow recovery from isValidPath RPCs with an invalid path

[Ludovic Courtès]

Hello,

Currently, clients cannot recover from an isValidPath RPC with an
invalid path parameter because the daemon closes the connection when
that happens.

More precisely:

  1. in performOp, wopIsValidPath case, ‘readStorePath’ raises an
 ‘Error’ exception;

  2. that exception is caught by the handler in ‘processConnection’;

  3. the handler determines errorAllowed == false, and thus exits after
 sending the message.

This last part is fixed by calling ‘startWork’ early on, as in the patch
below.

The same reasoning could be applied to all the RPCs that take one or
more store paths as inputs, but isValidPath is, by definition, likely to
be passed invalid paths in the first place, so it’s important for this
one to allow recovery.

WDYT?

Thanks,
Ludo’.

diff --git a/src/nix-daemon/nix-daemon.cc b/src/nix-daemon/nix-daemon.cc
index 882078c..e678c9d 100644
--- a/src/nix-daemon/nix-daemon.cc
+++ b/src/nix-daemon/nix-daemon.cc
@@ -294,8 +294,14 @@ static void performOp(bool trusted, unsigned int clientVersion,
 #endif
 
 case wopIsValidPath: {
-Path path = readStorePath(from);
+	/* 'readStorePath' could raise an error leading to the connection
+	   being closed.  To be able to recover from an invalid path error,
+	   call 'startWork' early, and do 'assertStorePath' afterwards so
+	   that the 'Error' exception handler doesn't close the
+	   connection.  */
+Path path = readString(from);
 startWork();
+	assertStorePath(path);
 bool result = store-isValidPath(path);
 stopWork();
 writeInt(result, to);
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] LLVM builds on Hydra but not locally

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 15/12/13 19:14, James Cook wrote:

 Thanks for pointing out the option, though; somehow I had assumed
 NixOS enabled that by default... is there a reason not to?

 Yes, chroot builds are slow.  https://github.com/NixOS/nix/issues/179

That reads:

--8---cut here---start-8---
with import nixpkgs {};
with lib;
let deps = map (n: runCommand depM-${toString n} {} touch $out) (range 1 
100);
in runCommand foo { x = deps; } touch $out

(i.e. a trivial build with 100 trivial dependencies) takes 4.7s to build on my 
laptop without chroot, but 39.6s
with chroot.
--8---cut here---end---8---

How representative of real life is it?

Not much I presume.  When you do have 100 derivations to build, their
body will typically take longer than ‘touch $out’.  At this point, the
overhead shouldn’t matter this much.

But it would matter when using Nix as a Make replacement.

Ludo’.

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

Re: [Nix-dev] LLVM builds on Hydra but not locally

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 16/12/13 13:56, Ludovic Courtès wrote:

 Not much I presume.  When you do have 100 derivations to build, their
 body will typically take longer than ‘touch $out’.  At this point, the
 overhead shouldn’t matter this much.

 NixOS has lots of trivial derivations to build stuff like configuration 
 files
 and systemd units.  When running nixos-rebuild it's really noticeable that 
 this
 takes a long time.

Ah right, I see.

Thanks,
Ludo’.

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

[Nix-dev] GNU Guix 0.5 released

[Ludovic Courtès]

We are pleased to announce release of GNU Guix version 0.5, representing
395 commits by 11 people over 2 months.

This release comes with an updated QEMU virtual machine image that shows
preliminary work toward building a stand-alone GNU system with Guix.
The image uses the GNU Linux-Libre kernel and the GNU dmd init system.
It is console-only, and may be used primarily to try out Guix and dmd.


• About

  GNU Guix is a functional package manager and distribution of
  the GNU system.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  Guix uses
  low-level mechanisms from the Nix package manager, with Guile Scheme
  programming interfaces.

  At this stage Guix can be used on top of an i686, x86_64, or mips64el
  GNU/Linux system, or in a virtual machine.  Future versions will
  stand alone.

  http://www.gnu.org/software/guix/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
ftp://alpha.gnu.org/gnu/guix/guix-0.5.tar.gz
ftp://alpha.gnu.org/gnu/guix/guix-0.5.tar.gz.sig

ftp://alpha.gnu.org/gnu/guix/gnu-system-demo-0.5.qcow2.xz
ftp://alpha.gnu.org/gnu/guix/gnu-system-demo-0.5.qcow2.xz.sig

  Use a mirror for higher download bandwidth:
http://www.gnu.org/order/ftp.html

  Here are the MD5 and SHA1 checksums:

  34ec4229899df46c5eb3b7c3980ebd75  guix-0.5.tar.gz
  62cfda802011d43ec0427e9269939938f69c9be8  guix-0.5.tar.gz

  745ae52a24b231f74f7efb7caa79705f  gnu-system-demo-0.5.qcow2.xz
  e950a0deb590b0386b937f86b25b211fc4fd8c29  gnu-system-demo-0.5.qcow2.xz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify guix-0.5.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.14
Makeinfo 5.2


  To use the virtual machine image, run QEMU like this:

qemu-system-x86_64 -m 256 -net nic,model=e1000 -net user \
 gnu-system-demo-0.5.qcow2

  This enables networking support, which is useful when using Guix
  inside of it.


• Changes since version 0.4 (excerpt from the NEWS file)

  ** Package management
  *** GNU package descriptions synchronized with the ‘gnumaint’ repository

  In addition to synopses, descriptions of GNU packages are now kept in sync
  with the ‘gnumaint’ repository, which is the canonical place for GNU package
  meta-data.

  ** Programming interfaces
  *** Patches are now listed as part of ‘origin’

  The ‘origin’ form supports two new fields: ‘patches’ (list of patches), and
  ‘snippet’ (code snippet to modify the source.)  These are applied when running
  ‘guix build --source’.  See “Defining Packages” in the manual.

  *** New (guix monads) monadic interface to operate on the store

  See “The Store Monad” in the manual.  The (gnu system …) modules have been
  rewritten to use this monadic interface.

  *** New (guix profiles) module

  It provides an API for dealing with profiles, as with the ‘guix package’
  command.

  *** New (gnu system) module

  This module provides a generic way to describe the system’s configuration,
  and to instantiate it, regardless of the final medium (QEMU image, etc.)
  See “System Configuration” in the manual.

  This is work in progress.  Send feedback to guix-de...@gnu.org!

  *** ‘build-expression-derivation’ uses more parameters

  Some positional parameters have been changed to keyword parameters.
  See “Derivations” in the manual.

  ** GNU distribution
  *** New port to the Loongson MIPS64 processors, n32 ABI (‘mips64el-linux’)

  Bootstrap binaries have been built for that architecture, and several
  Loongson-specific patches not yet available upstream have been applied to core
  packages.  See “GNU Distribution” and “Porting” in the manual.

  Pre-built binaries are not yet available via hydra.gnu.org, so Guix will
  build from source on this platform.

  *** 110 new packages

  acct, alive, alsa-utils, apl, at-spi2-atk, at-spi2-core, atkmm, autogen,
  automoc4, brasero, bridge-utils, cairomm, catkin, complexity, evince, ffmpeg,
  fftw, ftgl, gcc-objc, gcc-objc++, gccgo, gcl, gfortran, glibmm, glpk,
  gnome-icon-theme, gnu-pw-mgr, gp2c, gpgme, gsettings-desktop-schemas, gtkmm,
  gtksourceview, guile-ssh, guile-wm, gvpe, hicolor-icon-theme, httpd, icecat,
  icon-naming-utils, json-c, lapack, libcanberra, libcap, libgnome-keyring,
  libmikmod, libnl, libnotify, libsamplerate, libsigc++, libsndfile, libssh,
  libtheora, libxkbcommon, mercurial, mtools, netcat, pangomm, parallel,
  pavucontrol, pciutils, pem, perl-encode-locale, 

Re: [Nix-dev] Nixpkgs-Monitor service is online

[Ludovic Courtès]

Hi!

phree...@yandex.ru skribis:

 I'd like to unveil this new service, which will hopefully help us keep Nix 
 stuff fresh and 
 secure: http://vdmvtkitqc3grub6.onion.to/

Looks nice.

Could you say a bit more how it works?  From our IRC discussion, the
“Coverage” number represents the number of auto-updater tools that cover
a given package.

But then, does Monitor use these tools to derive the data that’s in the
“Outdated” page?

Curiously,
Ludo’.

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

Re: [Nix-dev] Flash broken in Firefox 22?

[Ludovic Courtès]

Hello,

I recommend using GNU Gnash, which works well for YouTube for instance,
while preserving your computing freedom.

Ludo’.

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

Re: [Nix-dev] Deterministic(bit-perfect) Builds

[Ludovic Courtès]

Many syscalls (uname, gettimeofday, etc.) and OS interfaces (/proc,
/dev, /sys, etc.) leak info.

Name spaces, personality(2), and similar help, but it looks like an
endless quest.

Ludo’.

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

Re: [Nix-dev] Error deleting a jobset or a project in hydra

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 11/06/13 16:18, Marco Maggesi wrote:

 it seems that the mechanism for deleting a jobset or a project from hydra is
 currently broken.

 I just committed a fix for this.

ISTR that Rob considered deletion “deprecated” in favor of the “hiding”
feature, no?

Ludo’.

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

Re: [Nix-dev] Using several versions of GHC at once

[Ludovic Courtès]

Hi!

Nikita Karetnikov nik...@karetnikov.org skribis:

 I'm trying to install several versions of GHC.  There are two
 problems:

 1. According to this page [1], it should be possible to use multiple
versions at once.  But 'nix-env -iA' always replaces the previous
version.  For example, if I run the following commands:

# nix-env -iA nixpkgs.haskellPackages_ghc6104.ghc
# nix-env -iA nixpkgs.haskellPackages_ghc762.ghc

my profile will only contain 'ghc-7.6.2', not both.

Yes.  I believe it’s not possible to install both at the same time,
because nix-env will only keep one thing called ‘ghc’.

[...]

/nix/store/f2rwkyd9yb6s5cdvmy7ydh9yd5bqd1hi-stdenv/setup: ./configure: 
 /bin/sh: bad interpreter: No such file or directory

[...]

build-chroot-dirs = /dev /proc /bin

Could it be that /bin/sh is a symlink whose target is not in the chroot?

Ludo’.

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

Re: [Nix-dev] getconf PATH

[Ludovic Courtès]

Peter Simons sim...@cryp.to skribis:

 the patch https://github.com/NixOS/nixpkgs/pull/586 fixes this issue
 (in stdenv-updates). Does anyone see a reason not to merge this?

Seems that the patch would work for both NixOS and non-NixOS distros, so
it looks good to me.

(Though CS_PATH seems to be fundamentally inappropriate for our purposes.)

Ludo’.

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

[Nix-dev] Authenticating binary substitutes

[Ludovic Courtès]

Hello,

Currently the “binary cache” substituter relies on DNS to authenticate
downloaded binaries: anything coming from, say, hydra.nixos.org is
considered authentic, because hydra.nixos.org is listed in the
‘trusted-binary-cache’ list.

This is obviously subject to person-in-the-middle attacks: one could
connect over Wifi to somebody else’s network, which happens to redirect
hydra.nixos.org to evil.example.com, and end up downloading evil binaries.

I was thinking of a simple extension to solve that:

  1a. The /nix-cache-info file would contain an (optional)
 ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
 OpenPGP key used to sign Nars.

  1b. In addition to, or alternatively, a /nix-signing-key file would be
  served, containing the OpenPGP key used to sign Nars.

  2.  In addition to serving, say,
  /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
  also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
  OpenPGP binary signature of the uncompressed Nar.

WDYT?  Could this be implemented in Hydra?

Ludo’.


pgpe_OAwSzYiH.pgp
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] Authenticating binary substitutes

[Ludovic Courtès]

(Re-adding bug-guix@.)

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 22/05/13 11:12, Ludovic Courtès wrote:

 Currently the “binary cache” substituter relies on DNS to authenticate
 downloaded binaries: anything coming from, say, hydra.nixos.org is
 considered authentic, because hydra.nixos.org is listed in the
 ‘trusted-binary-cache’ list.
 
 This is obviously subject to person-in-the-middle attacks: one could
 connect over Wifi to somebody else’s network, which happens to redirect
 hydra.nixos.org to evil.example.com, and end up downloading evil binaries.

 There is an issue about this:

 https://github.com/NixOS/nix/issues/75

Ah, good.

 I was thinking of a simple extension to solve that:
 
   1a. The /nix-cache-info file would contain an (optional)
  ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
  OpenPGP key used to sign Nars.
 
   1b. In addition to, or alternatively, a /nix-signing-key file would be
   served, containing the OpenPGP key used to sign Nars.
 
   2.  In addition to serving, say,
   /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
   also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
   OpenPGP binary signature of the uncompressed Nar.

 How about: rather than relying on nix-cache-info, nix.conf should specify a 
 list
 of fingerprints of trusted OpenPGP signing keys.

Yes (I was focusing on the protocol, to start with.)

 Then when we fetch a .narinfo, we check whether it is signed by a
 trusted key.  This way you don't have the problem Lluís described.

I think it’s enough to sign nars.  What do you think it would add to
sign narinfos as well?

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

Re: [Nix-dev] Authenticating binary substitutes

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 22/05/13 16:16, Ludovic Courtès wrote:

 I think it’s enough to sign nars.  What do you think it would add to
 sign narinfos as well?

 I think it's enough to sign the narinfo, since it contains the hash of the NAR
 (which Nix already verifies).

Right.

 Also, rather than having a separate .sig file, the signature could be stored 
 in
 the narinfo file itself.  That would halve the number of HTTP requests.

Well, the .sig only needs to be downloaded when the user actually
substitutes something; this is not a situation where it would really
make a difference.

Also, how would the signature be formatted, then?

 On 22/05/13 15:19, Lluís Batlle i Rossell wrote:

 How about: rather than relying on nix-cache-info, nix.conf should specify a 
 list
 of fingerprints of trusted OpenPGP signing keys.  Then when we fetch a 
 .narinfo,
 we check whether it is signed by a trusted key.  This way you don't have the
 problem Lluís described.
 
 Well, if we use gpg, gpg has its own system of trust, too. Or it's about not
 using gpg?

 Now that you mention it, it would probably be better to use OpenSSL than 
 GnuPG,
 given that we already have a (optional) dependency on OpenSSL, while GnuPG 
 would
 be a fairly big new dependency.

I was mentioning OpenPGP (the spec), not GnuPG (an implementation).

What format and model do you have in mind?

The ideal may be SPKI/SDSI here, but OpenPGP is what people are used to,
and it’s readily available.

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

[Nix-dev] Guix paper at the European Lisp Symposium

[Ludovic Courtès]

Hello!

FYI a paper presenting the design of Guix’s Scheme API and packaging
EDSL has been accepted for the 2013 European Lisp Symposium (ELS), which
will take place in Madrid on June 3–4:

  http://arxiv.org/abs/1305.4584

Ludo’.

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

[Nix-dev] GNU Guix 0.2 released

[Ludovic Courtès]

We are pleased to announce GNU Guix version 0.2, the second alpha
release, representing 580 commits by 5 people over 4 months.


• About

  GNU Guix is a functional package manager and distribution of
  the GNU system.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  Guix uses
  mechanisms from the Nix package management tool, with a Guile Scheme
  programming interface.

  http://www.gnu.org/software/guix/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz
ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz.sig

  Use a mirror for higher download bandwidth:
http://www.gnu.org/order/ftp.html

  Here are the MD5 and SHA1 checksums:

  4bdbbd736d0bbcb6cd7e28220c4ea1fe  guix-0.2.tar.gz
  051a65d1d7aa9a0ea69fe97d6d9a8b93fe09cca0  guix-0.2.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

gpg --verify guix-0.2.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.13.1
Makeinfo 5.1


• Changes since version 0.1 (excerpt from the NEWS file)

  ** Package management

  *** Guix commands are now sub-commands of the “guix” program

  Instead of typing “guix-package”, one now has to type “guix package”, and so
  on.  This has allowed us to homogenize the user interface and initial program
  setup, and to allow commands to be upgradable through “guix pull”.

  *** New “guix package --upgrade” option

  As the name implies, this option atomically upgrades all the packages
  installed in a profile or the set of packages matching a given regexp.
  See “Invoking guix package” in the manual.

  *** New “guix package --search” option

  Performs a full text search in package synopses and descriptions, and returns
  the matching packages in recutils format.  See “Invoking guix package” in the
  manual, for details.

  *** New “guix pull” command

  The command pulls the latest version of Guix–both the package management
  modules and the distribution.  See the manual for details.

  *** New binary substituter

  The “substituter” mechanism allows pre-built binaries to be transparently
  downloaded instead of performing a build locally.  Currently binaries are
  available for x86_64 Linux-based GNU systems from http://hydra.gnu.org.  The
  distribution is continuously built and binaries are made available from there.

  See http://hydra.gnu.org/jobset/gnu/master under “Job status” for the list of
  available binary packages.

  *** New “guix refresh” command

  The command is used by Guix maintainers.  It automatically updates the
  distribution to the latest upstream releases of GNU software.

  *** New “guix hash” command

  Convenience command to compute the hash of a file.  See the manual for
  details.

  *** Nix daemon code updated

  The daemon code from Nix, used by the ‘guix-daemon’ command, has been updated
  to current Nix ‘master’.

  ** Programming interfaces

  *** (guix download) now supports HTTPS, using GnuTLS

  It allows package source tarballs to be retrieved over HTTPS.

  *** New ‘native-search-path’ and ‘search-path’ package fields

  Packages can define in their ‘native-search-path’ field environment variables
  that define search paths and need to be set for proper functioning of the
  package.  For instance, GCC has ‘CPATH’ and ‘LIBRARY_PATH’ in its
  ‘native-search-path’, Perl has ‘PERL5LIB’, Python has ‘PYTHONPATH’, etc.
  These environment variables are automatically set when building a package that
  uses one of these.

  *** Package inputs can be a function of the target system type

  The ‘inputs’ field of a package can now be conditional on the value of
  (%current-system).  This is useful for packages that take system-dependent
  tarballs as inputs, such as GNU/MIT Scheme.

  *** New build systems

  The ‘perl-build-system’, ‘python-build-system’, and ‘cmake-build-system’ have
  been added.  They implement the standard build systems for Perl, Python, and
  CMake packages.

  *** Tools to build Linux initrds, QEMU images, and more

  The (gnu packages linux-initrd) module provides a procedure to build a Linux
  initrd (“initial RAM disk”).  The initrd embeds Guile, which is used to
  evaluate the given expression.  The example below returns an initrd that
  mounts the /proc file system and starts a REPL:

(expression-initrd
  '(begin
 (mkdir /proc)
 (mount none /proc proc)
 ((@ (system repl repl) start-repl

  

Re: [Nix-dev] Discussion: env vars as glue

[Ludovic Courtès]

Hi!

Lluís Batlle i Rossell vi...@viric.name skribis:

 What uses do you have for:
 ALSA_PLUGIN_DIRS
 GST_PLUGIN_PATH
 MOZ_PLUGIN_PATH
 QTWEBKIT_PLUGIN_PATH
 QT_PLUGIN_PATH
 STRIGI_PLUGIN_PATH

I think fundamentally plug-ins are about dynamic composition, whereas
Nix favors static composition.  It’s a shock of cultures.  Yet, we
probably want a bit of both.

Ludo’.

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

Re: [Nix-dev] guile 2.0.7 test suite fails without IPv6 support

[Ludovic Courtès]

Hi Peter,

The patch I originally sent had a thinko.  Can you try with the
just-released Guile 2.0.9, which contains a correct fix AFAICS?

Thanks,
Ludo’.

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

Re: [Nix-dev] guile 2.0.7 test suite fails without IPv6 support

[Ludovic Courtès]

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 OTOH, the error message suggests that the test tries to bind to a local port,
 which is inherently impure since another build might try to do the same thing 
 at
 the same time.

The test is skipped upon EADDRINUSE.

Ludo’.

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

Re: [Nix-dev] guile 2.0.7 test suite fails without IPv6 support

[Ludovic Courtès]

Peter Simons sim...@cryp.to skribis:

 the test suite for guile-2.0.7 fails on my machine, complaining:

   ERROR: socket.test: AF_INET6/SOCK_STREAM: bind - arguments: ((system-error 
 bind ~A (Cannot assign requested address) (99)))
   ERROR: socket.test: AF_INET6/SOCK_STREAM: bind/sockaddr - arguments: 
 ((system-error bind ~A (Cannot assign requested address) (99)))

Actually, can you try this patch:

diff --git a/test-suite/tests/00-socket.test b/test-suite/tests/00-socket.test
index 8079cf5..cf3ad06 100644
--- a/test-suite/tests/socket.test
+++ b/test-suite/tests/socket.test
@@ -416,7 +416,17 @@
 #t)))
 
 
-(if (defined? 'AF_INET6)
+(define %ipv6-supported?
+  (and (defined? 'AF_INET6)
+   (catch 'system-error
+ (lambda ()
+   (socket AF_INET6 SOCK_STREAM 0))
+ (lambda args
+   ;; We probably got EAFNOSUPPORT.
+   (pk 'ipv6-not-supported (strerror (system-error-errno args)))
+   #f
+
+(if %ipv6-supported?
 (with-test-prefix AF_INET6/SOCK_STREAM
 
   ;; testing `bind', `listen' and `connect' on stream-oriented sockets

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

Re: [Nix-dev] guile 2.0.7 test suite fails without IPv6 support

[Ludovic Courtès]

Hi Peter,

Peter Simons sim...@cryp.to skribis:

 the test suite for guile-2.0.7 fails on my machine, complaining:

   ERROR: socket.test: AF_INET6/SOCK_STREAM: bind - arguments: ((system-error 
 bind ~A (Cannot assign requested address) (99)))
   ERROR: socket.test: AF_INET6/SOCK_STREAM: bind/sockaddr - arguments: 
 ((system-error bind ~A (Cannot assign requested address) (99)))

 This looks to me like the build requires IPv6 support -- which my
 machine doesn't have. An obvious way to hack around this issue is to
 disable the test suite, but that's not really satisfactory. Is there
 another, less intrusive solution?

 Ludo, do you have a suggestion?

No simple suggestions.  I think these tests should be skipped when IPv6
support is missing.  I’ll try to do that for 2.0.8, which is due in a
couple of days.

Ludo’.

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

Re: [Nix-dev] Missing command suggestions

[Ludovic Courtès]

Hello!

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 NixOS now provides Ubuntu-style missing command suggestions.  I implemented 
 this
 a while ago, but now it's enabled by default as part of the NixOS channel.

Nice!  Can you say a bit about the implementation?

Ludo’.

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

Re: [Nix-dev] Nixpkgs: libchop on stdenv

[Ludovic Courtès]

Hello,

Vladimír Čunát vcu...@gmail.com skribis:

 Just a reminder in case you haven't noticed: libchop doesn't build on
 stdenv (due to using gets).
 http://hydra.nixos.org/job/nixpkgs/stdenv/libchop

Thanks for the reminder.  Commit b6452df fixes it.

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

Re: [Nix-dev] invalid mode for dlopen() (mixing master and stdenv-updates)

[Ludovic Courtès]

James Cook james.c...@utoronto.ca skribis:

 I updated $HOME/.nix-profile to a commit from the stdenv-updates
 branch (I tried commits fc82aa0 and face3a8).

 When I run commands, I get this error message:
   ls: error while loading shared libraries: __vdso_time: invalid mode
 for dlopen(): Invalid argument

 What I find particularly interesting:
   $ which ls
   /run/current-system/sw/bin/ls
 (so I'm still using ls from master).

Could it be that $HOME/.nix-profile/lib is in $LD_LIBRARY_PATH?

Presumably ‘ls’ wants glibc 2.13, whereas your profile has glibc 2.17 or so.

Ludo’.

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

[Nix-dev] [Hydra] DBIx schemas, case folding, and PostgreSQL 8.4

[Ludovic Courtès]

Hello,

I hit a case-sensitivity issue with Hydra on PostgreSQL 8.4:

  http://thread.gmane.org/gmane.comp.lang.perl.modules.dbi.general/16888

Normally case-sensitivity isn’t an issue because DBIC doesn’t quote
identifiers.  However, it does quote them when looking for a sequence,
hence the problem above.

The schemas under src/lib/Hydra were generated for an SQLite database
(see src/sql/Makefile.am), which has different case-folding rules from
PostgreSQL (PostgreSQL downcases identifiers and is case-sensitive for
quoted identifiers, whereas SQLite is case-preserving but
case-insensitive, IIUC.)

I tried regenerating the schemas with something like:

  perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:../lib -e 
'make_schema_at(Hydra::Schema, { naming = v8, relationships = 1, 
preserve_case = 1 }, [dbi:Pg:dbname=hydra;host=localhost;user=hydra])'

However, that doesn’t preserve CamelCase names.

Thus, as advised on #dbix-class, I ended up doing this:

-__PACKAGE__-table(BuildMachineSystemTypes);
+__PACKAGE__-table(lc(BuildMachineSystemTypes));

Kinda ugly, but seems to work.

What would a better fix be?

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

Re: [Nix-dev] Bundling nix-expressions with source code

[Ludovic Courtès]

Hi,

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 25/01/13 09:32, Rickard Nilsson wrote:

 I see nix is getting quite popular :-)
 The maintainer is of course welcome to maintain also the nix expression
 *within* nixpkgs, who else is a better candidate...
 
 Yes, absolutely, and that is completely OK. But you might want to keep
 an in-development default.nix in the upstream repo, too. It's actually
 very nice to use Nix during development, for handling dependencies,
 installing throw-away stuff in your profile, etc.

 Yes, I totally agree.  I have exactly that problem with packages like Hydra 
 and
 Charon, which have Nix expressions in their own trees to build them - which 
 then
 needs to be duplicated in Nixpkgs to make them available there :-(

In principle there could be just one expression in Nixpkgs, and the
package’s release.nix would just use ‘overrideDerivation’ to change the
‘src’ attribute of that expression to point to the result of the
‘tarball’ job.

WDYT?

Ludo’.

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Shea Levy s...@shealevy.com skribis:

 On 01/23/2013 06:12 PM, Ludovic Courtès wrote:
 Shea Levy s...@shealevy.com skribis:

 On 01/21/2013 05:39 AM, Ludovic Courtès wrote:
 [...]

 In theory yes, because ‘import’ in the Nix language can import .drv
 files–a little-known feature.  ;-)

 In practice, though, it can only do that if the .drv defines an
 environment variable called ‘name’
 Why do you say this?
  From ‘prim_derivationStrict’:

  if (attr == args[0]-attrs-end())
  throw EvalError(required attribute `name' missing);

 Sure, but importing .drvs doesn't go through derivationStrict. It just
 reads the outPaths and drvPath directly from the .drv file.

Right, so you can import it, but you just can’t build it.  :-)

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Shea Levy s...@shealevy.com skribis:

 On 01/21/2013 05:39 AM, Ludovic Courtès wrote:

[...]

 In theory yes, because ‘import’ in the Nix language can import .drv
 files–a little-known feature.  ;-)

 In practice, though, it can only do that if the .drv defines an
 environment variable called ‘name’

 Why do you say this?

From ‘prim_derivationStrict’:

if (attr == args[0]-attrs-end())
throw EvalError(required attribute `name' missing);

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Hi,

Florian Friesdorf f...@chaoflow.net skribis:

 Ludovic Courtès l...@gnu.org writes:
 Florian Friesdorf f...@chaoflow.net skribis:
 What are your thoughts on generating nix expressions from guix
 expressions for the purpose of package definition?

 Do you mean the opposite–generating Guix expressions from Nix?

 I actually meant guix - nix, as guix being within a full language, I
 had gut feeling this direction might be preferable, see also below.

I think conversion has the same problem in both directions: simple
meta-data is trivially converted, but anything beyond that, especially
builder-side code, can hardly be automatically converted.

 Marc Weber marco-owe...@gmx.de skribis:
   - in which way you're going to utilize the new power of scheme first
 applying to what problems?

 On the build side, it nicely replaces Bash, and also Coreutils,
 Findutils, sed, and cURL.  :-)

 Do you have ideas how these replacements could be used if generating nix
 expressions from guix expressions?

It’s going to be hard to automate anything.  For instance, something like

  (substitute* (find-files . ^Makefile$)
((/bin/sh)
 (which sh)))

would have to be converted to

  find . -name Makefile -exec sed -i {} -es|/bin/sh|`which sh`|”

Not to mention code that adds, removes, or modifies the standard build
phases

 It reuses the daemon, and thus libstore, as described in ‘README’.

 I take that nix and guix nicely cooperatively use /nix/store/ though
 it's rather unlikely that the two would actually create the same output.

Yes (I use it on top of NixOS currently.)

 Would it be feasible to depend on nixpkgs from within guix packages?

Yes, I did that in the beginning: you basically inject derivation paths
as returned by ‘nix-instantiate’ into the derivations that Guix produces.

 Would it be feasible to do it the other way round?

In theory yes, because ‘import’ in the Nix language can import .drv
files–a little-known feature.  ;-)

In practice, though, it can only do that if the .drv defines an
environment variable called ‘name’, which Guix derivations don’t
normally do.  (This is an example of how arguments to derivations are
sometimes abused as arguments to the ‘derivation’ primitive.)

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Michael Raskin 7c6f4...@mail.ru skribis:

 Do you mean the opposite–generating Guix expressions from Nix?

 I actually meant guix - nix, as guix being within a full language, I
 had gut feeling this direction might be preferable, see also below.

I think conversion has the same problem in both directions: simple
meta-data is trivially converted, but anything beyond that, especially
builder-side code, can hardly be automatically converted.

 Can't Guix launch sh with all needed variables set?

It would still need to have Nixpkgs’s stdenv/setup.sh around, and
probably more of Nixpkgs’s infrastructure (for instance, there’s no GCC
wrapper in the distro, so NIX_CFLAGS  co. won’t have any effect.)

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Hi,

Florian Friesdorf f...@chaoflow.net skribis:

 What are your thoughts on generating nix expressions from guix
 expressions for the purpose of package definition?

Do you mean the opposite–generating Guix expressions from Nix?

If so, there’s the guix-import program, which works like this:

  guix-import /path/to/nixpkgs attribute

It spits out a basic Guix package definition.  By “basic”, I mean that
only trivial things are converted; Bash snippets added in
‘configurePhase’, ‘preCheck’, etc. are just ignored.

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

Re: [Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

Hi Marc,

Marc Weber marco-owe...@gmx.de skribis:

   - why you go this way. One reason I can think of is because scheme might
 be more powerful than nix language. Are there more reasons?

Technically, I believe an EDSL has more to offer than a DSL with its own
implementation: tooling (compiler, debugger, REPL, editor support,
etc.), libraries (SRFI-1, etc.), general-purpose features (data
structures, i18n, networking, etc.), and integration with other tools 
libraries written in that language.  Scheme makes it easy to define
EDSLs, through macros.

A nice thing is that Scheme can be used both on the “host” side (as a
replacement of the Nix language), and on the build side (a nice
replacement of Bash...).

Philosophically, I’m also interested in making a free software, and a
“GNU” distro.

I’ve always been disappointed that Nixpkgs includes non-free software,
and that even proposals to just move them in a separate directory were
rejected.

   - in which way you're going to utilize the new power of scheme first
 applying to what problems?

On the build side, it nicely replaces Bash, and also Coreutils,
Findutils, sed, and cURL.  :-)

On the host side, it facilitates the implementation of new tools.  For
instance, listing the available packages, searching them, using l10n’d
package descriptions, etc. is easy and fast.  The auto-updater that’s in
the works, based on Nixpkgs’s gnupdate, is going to be both easier to
implement and faster (no need to parse several MiBs of a low-level XML
representation!).

Guix provides access to several levels of API: store RPCs, low-level
derivations, Scheme derivations, and high-level package descriptions.
That opens up a wide range of possibilities, I think.  Again, this is
the typical advantage of using a single language.

There’s also a clearer separation of concerns: for instance,
env. vars. are not abused as arguments to the ‘derivation’ primitive.

   - how exactly you reuse existing nix* software. You should describe
 this.

It reuses the daemon, and thus libstore, as described in ‘README’.

   - what would be the advantages of your system - eg will you keep the
 lazy feature? If you build 150 packages its not a big problem.

Of course it’s lazy, it doesn’t try to build every package as soon as
you fire it.  :-)

More details can be found in the manual, ‘README’, and in my GHM talk
linked from the web site.

Hope this clarifies things!

Ludo’.


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

[Nix-dev] GNU Guix 0.1 released (alpha)

[Ludovic Courtès]

;; Announcement. -*- scheme -*-

(define guix
  (package
(name guix)
(version 0.1)   ; first alpha release
(source
  (origin
(method url-fetch)
(uri ftp://alpha.gnu.org/gnu/guix/guix-0.1.tar.gz;)
(signature ftp://alpha.gnu.org/gnu/guix/guix-0.1.tar.gz.sig;)
(sha256
 350286bcf37a4035244cdddfe7bd62e79bcd08db0ed35b48e1444302dfc52005)))
(license gpl3+)
(home-page http://www.gnu.org/software/guix/;)
(synopsis Functional package management for GNU)
(description
 GNU Guix is a functional package manager and associated free
software distribution of the GNU system.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection (more details in the manual.)
Guix uses mechanisms from the Nix package management tool, with a Guile
Scheme programming interface.

Guix comes with a small (~150 packages) and growing user-land software
distribution–i.e., it’s not a bootable distribution yet, but rather one
to be installed on top of a running GNU/Linux system.  It includes
GNU libc 2.17, GCC 4.7.2, GNU Emacs 24.2, GNU Guile 2.0.7, and many more!

The distribution with this release is available on i686 and x86_64
Linux-based systems.  It features source-based deployment only;
bootstrapping the distribution requires ~5 GiB of disk space.

See the ROADMAP and TODO files for future directions.  Building the
distribution is a cooperative effort, and you are invited to join!)))

;; Ludovic, on behalf of the Guix team.


pgpaBjd3FDtLk.pgp
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] reproducable systems at a (much) later point / archive.org

[Ludovic Courtès]

Hi!

Florian Friesdorf f...@chaoflow.net skribis:

 Given that nix would support a last-resort mirror and given we could
 convince some instution (e.g. archive.org) to provide such a mirror, the
 world would be always able to exactly reproduce software installations
 and we could show our / somebody's grandchildren how we kept ourselves
 entertained.

Given a mirror of every source tarball, you’d still need a working
bootloader and kernel (or full NixOS).  In practice you also need to
take Nix, Nixpkgs, and NixOS of the same date, because they are largely
interdependent.  But yes, Nix is definitely forward for software archeology.

Ludo’.

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

Re: [Nix-dev] Down with /bin/sh!

[Ludovic Courtès]

Hi Rob!

Rob Vermaas rob.verm...@gmail.com skribis:

   • Right after unpacking a source tarball, all the source files go
 through ‘patch-shebang’, which replaces any #!/bin/sh and similar
 with the right path.


 I would not like such a change in stdenv of nixpkgs, without an option to
 disable this. For example, we use nix to build some packages that run
 outside of nix, and for those, we do not want to replace all the references
 to /bin/sh in all source files/scripts.

I’m not sure what you mean by “run outside of Nix”.

The files that are patched are source files anyway.  Nixpkgs already has
a patch-shebang phase for installed files, which is what users notice.

 I haven't thought of it much, but in general I would like an approach
 better that would *not* change the source code of packages by default,
 but only when it is really necessary.

Well yeah, it’s a bit of a sledgehammer approach.  Still, it works
like a charm, and feels just like a natural extension of all our
craziness.  :-)

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

Re: [Nix-dev] Nix 1.2 released

[Ludovic Courtès]

Hi!

Congrats on the release.  :-)

Eelco Dolstra eelco.dols...@logicblox.com skribis:

   * Store optimisation (replacing identical files in the store with hard 
 links)
 can now be done automatically every time a path is added to the store. 
 This
 is enabled by setting the configuration option auto-optimise-store to 
 true
 (disabled by default).
 Any experience about performance? Why is it disabled by default?

 I had it enabled by default initially, but then I experienced some performance
 hit on one machine so I disabled it for now.  Didn't have time to investigate 
 it
 more yet.

My experience is that ‘addToStore’ operations become quite
I/O-intensive, which can be slightly problematic on Hydra masters (there
are lots of copies back-and-forth between the master and slaves.)

OTOH, the benefits in terms of disk space seem appealing.

Thanks,
Ludo’.

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

Re: [Nix-dev] end-of-life kernels

[Ludovic Courtès]

Hi,

I think initially some of the old kernels were re-added by a colleague
of mine to allow continuous integration testing of a kernel module
against a variety of Linux versions.

It’s no longer used, but that kind of use may still make sense.

Thanks,
Ludo’.

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

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

[Ludovic Courtès]

Hi,

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 On 03/11/12 15:24, Ludovic Courtès wrote:

 A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
 distros, especially Debian derivatives, is that their /bin/sh is not
 Bash.  On Debian and derivatives, it’s a symlink to /bin/dash.
 
 When building without a chroot, things eventually fail because stdenv,
 and sometimes build systems, assume that /bin/sh is Bash.

 Where does stdenv assume that /bin/sh is Bash?

Everywhere.  Associative arrays, etc.

The main problem remains that building outside of a chroot on these
distros is likely to bring a number of errors due to impurities.

 A workaround would be to implement this feature request:
 https://github.com/NixOS/nix/issues/24.  This would allow /bin/sh to be
 redirected to whatever you want.

Yes.  What about the more flexible approaches I suggested?

Ludo’.

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

[Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

[Ludovic Courtès]

Hello!

A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
distros, especially Debian derivatives, is that their /bin/sh is not
Bash.  On Debian and derivatives, it’s a symlink to /bin/dash.

When building without a chroot, things eventually fail because stdenv,
and sometimes build systems, assume that /bin/sh is Bash.

When enabling ‘build-use-chroot’, things fail because the symlink’s
target is not included in the chroot.

For things to work, people have to set ‘build-use-chroot = false’ and
make /bin/sh a symlink to /bin/bash.  Enabling ‘build-use-chroot’ won’t
work unless /bin/sh is not a symlink *and* is statically-linked.

Is there a better way to approach that problem?

Thanks,
Ludo’.

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

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

[Ludovic Courtès]

Hi Michael,

Michael Raskin 7c6f4...@mail.ru skribis:

 I have some basic-chroot.nix, which is what basics I need to do Nix 
 builds and look at simple problems comfortably.

 It is literally:

 let nixpkgs = import nixpkgs {}; in with nixpkgs; 
   symlinkJoin chroot-system [
 nixUnstable openssl (glibcLocales.override {allLocales = true;})
 rlwrap gcc zlib patchelf coreutils stdenv bashInteractive su gnugrep
 gnused less findutils curl wget utillinuxCurses subversion openssh
 gzip vim file strace lsof 
   ]

 I build it as /var/chroot-env

 When I need to do a rebuild that includes some local work, I do

 /etc/nixos/configurations/misc/raskin/misc-scripts/special-chroot \
  /var/nix-chroot /root root usr-only /var/chroot-env

Wow, that seems a little bit too sophisticated for a first-time user.
;-)

Ideally, I’d like a solution that Just Works for anyone trying out Nix.

I was thinking that, instead of just bind-mounting /bin, we could have
at least a nix-daemon option that would allow the host code to specify
which file /bin/sh should point to.  Even better would be to have an
additional ‘derivation’ parameter.

Eelco: what do you think?

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

Re: [Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

[Ludovic Courtès]

Hi,

Michael Raskin 7c6f4...@mail.ru skribis:

[...]

I was thinking that, instead of just bind-mounting /bin, we could have
at least a nix-daemon option that would allow the host code to specify
which file /bin/sh should point to.  Even better would be to have an
additional ‘derivation’ parameter.

[...]

 So, I guess there would be a configuration option (marked as dangerous
 and/or impure) to override what is taken from external environment for 
 a normal chroot build (ideally, nothing — maybe it is possible to use
 even fake proc?).

What I had in mind was more an extension of DerivationInputs.  Instead
of having just a derivation-path/output-ids pair, it could optionally be
something like a derivation-path/output-id/file/fs-mapping.

IOW, instead of (or in addition to) /.../bash.drv + “out”, you could
have: /.../bash.drv + “out” + “bin/bash” + “/bin/sh”, which would mean
“map ${bash}/bin/bash to /bin/sh”.

This would make chroot builds compulsory, though.

So an intermediate solution would be to have a specific nix-daemon
option to say what /bin/sh should point to.

Thoughts?

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

Re: [Nix-dev] [PATCH] Add a smatch package.

[Ludovic Courtès]

Hello!

Applied with a minor tweak: the ‘fetchgit’ invocation must be passed the
expected SHA256, so we know what we expect (that makes it a fixed-output
derivation, which can actually access the network, unlike regular
derivations in chroot.)

Thanks,
Ludo’.

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

Re: [Nix-dev] Automake Question

[Ludovic Courtès]

Hi Noah!  :-)

Noah Lavine noah.b.lav...@gmail.com skribis:

 The issue is that when trying to build GNU Guile, automake needs the
 AM_GNU_GETTEXT macro. But even after installing automake and gettext
 through Nix, I still don't have that macro available.

On NixOS, the ‘ACLOCAL_PATH’ environment variable normally gets defined;
by default, its value is “$HOME/.nix-profile/share/aclocal”, meaning
that Autoconf macros are searched for in the user’s local profile.

Can you check whether that variable is defined for you?

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

[Nix-dev] Preliminary support for Guile Guix in Hydra

[Ludovic Courtès]

Hello!

The ‘guile-support’ branch in Hydra adds support for Guile, so that
users can choose whether to write their build recipes in the Nix
language or in Guile (with Guix).

It basically “works for me” in an instance running on my laptop, but I’m
interested in review and general feedback.

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

Re: [Nix-dev] [ANN] Guix, functional package management from Guile

[Ludovic Courtès]

Hi Marc,

Marc Weber marco-owe...@gmx.de skribis:

 One of the core features of nix is that its lazy - I guess that's one of
 the main reason why Eelco didn't just use python/ruby/perl ...

 So what do you think about how performance would compare?

While Scheme itself isn’t lazy, Guix itself is, similarly to Nix.
Basically, there are package declarations like this:

  (define-public hello
(package
 (name hello)
 (version 2.8)
 (source (origin
  (method http-fetch)
  (uri (string-append http://ftp.gnu.org/gnu/hello/hello-; version
  .tar.gz))
  (sha256
   (base32 
0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6
 (build-system gnu-build-system)
 (inputs `((gawk ,gawk)))
 (description GNU Hello)
 (long-description Yeah...)
 (home-page http://www.gnu.org/software/hello/;)
 (license GPLv3+)))

This declaration just creates a ‘package’ object (a record).  It then
has to be passed to the ‘package-derivation’ produce, to get the .drv
path, which in turn has to be passed to ‘build-derivations’, to actually
build/download it.

Now, Guile comes with an optimizing compiler, meaning that the whole
distro can be compiled, which could speed things up (especially
operations such as package lookup by name, as in ‘nix-env -i’.)

Thanks,
Ludo’.

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

[Nix-dev] [***SPAM***] Re: Depending on Autoconf, Automake, and Libtool

[Ludovic Courtès]

Hi,

Eelco Dolstra eelco.dols...@logicblox.com skribis:

 Maybe a better solution, given the track record of the Autotools with respect 
 to
 backwards compatibility, is that packages should depend on a particular 
 version
 of the Autotools (e.g. automake_1_11).

Agreed.

 To encourage that we should remove the automake and autoconf
 attributes from all-packages.nix.

That would be a major annoyance for the GNU stuff on Hydra, and
elsewhere too.  Furthermore, in the case of CI, we want to see things as
they break when integrating them with cutting-edge software.

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

Re: [Nix-dev] [***SPAM***] [ANN] Guix, functional package management from Guile

[Ludovic Courtès]

Hey,

Sander van der Burg - EWI s.vanderb...@tudelft.nl skribis:

 Awesome experiment Ludovic!

Thanks.  :-)

 Actually, I had some crazy ideas in the past as well. For example,
 to develop an internal DSL for Nix in Scala (no specific reason why
 it's useful, but oh well)

Yeah, I believe embedded DSLs have nice advantages.

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

[Nix-dev] [***SPAM***] Depending on Autoconf, Automake, and Libtool

[Ludovic Courtès]

Hello!

I just upgraded GNU Autoconf and Automake, which, as I saw Hydra go and
rebuild all of KDE because libmng depends on those, inspired me this rant.

Golden Rule:

  Never ever add a dependency on Autoconf, Automake, or Libtool, unless
  you’re confident that you cannot do otherwise at all.

The point of these tools is precisely that they don’t need to be present
when installing from a tarball (unlike CMake, for instance.)

When a package’s build system needs to be patched, we must try hard to
patch generated files, such as ‘Makefile.in’ or ‘configure’, to avoid
having to depend on the autotools.


Back to libmng: its tarball appears to lack ‘configure’  co., hence the
dependency.  Upstream should be taught about the tools they use, and in
particular ‘make dist’.  Updating Autoconf  co. should not entail a KDE
rebuild, ever.

/rant  :-)

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

[Nix-dev] [***SPAM***] [ANN] Guix, functional package management from Guile

[Ludovic Courtès]

Hello!

I am delighted to announce Guix, a purely functional package
management tool.

  https://gitorious.org/guix

  http://www.fdn.fr/~lcourtes/software/guix-0.0.tar.gz
  SHA1: 30d99946c67e9a015bb9817b3731765aadc533be

Guix is written in Guile Scheme.  It builds on top of the low-level
build and storage mechanisms of the Nix package manager[*], and provides
high-level APIs to describe and run arbitrary build processes, and a
declarative interface to describe and compose software packages.

Guix implements purely functional package build and composition: a build
process is a Scheme function that returns the path of its result in the
“store”–the /nix/store directory.  The store acts as a build cache,
subject to garbage collection.  Changing a bit in the build process’s
inputs (dependencies, environment variables, etc.) changes the result.

All the nifty features of Nix are inherited:

  • multiple versions or variants of packages can happily coexist;

  • the package build environment is under control, in a chroot, such
that the result of a build process cannot be influenced by the
outside world;

  • support for transactional upgrades and rollback;

  • per-user environments, non-root package installation;

  • etc.


Last but not least, Guix comes with an actual distro!

  https://gitorious.org/guix/guix/blobs/master/distro/base.scm

Granted, it has yet to grow ;-), but it showcases the main ideas:
packages are described in a high-level, hopefully intelligible way, and
their build scripts are written and customized in Scheme.  Packages may
be built with, say:

  guix-build guile

or

  guix-build -e '(@ (distro base) guile-2.0)'

The latter refers unambiguously to the variable bound to the package of
interest, whereas the former would pick the first package of that name.

The ‘guile-reader’ example in the above file shows package composition,
while the ‘lout’ example shows that even hostile build systems can be
accommodated.


Guix  Nix
~~

Nix is really two things: a package build tool, implemented by a library
and daemon, and a special-purpose programming language.  Guix relies on
the former, but uses Scheme as a replacement for the latter.

Technically, Guix makes remote procedure calls to the ‘nix-worker’
daemon to perform operations on the store.  At the lowest level, Nix
“derivations” represent promises of a build, stored in ‘.drv’ files in
the store.  Guix produces such derivations, which are then interpreted
by the daemon to perform the build.  Thus, Guix derivations can use
derivations produced by Nix (and vice versa); in Guix, the cheat code is
the ‘nixpkgs-derivation’ procedure.  :-)

With Nix and the Nixpkgs distribution, package composition happens at
the Nix language level, but builders are usually written in Bash.
Conversely, Guix encourages the use of Scheme for both package
composition and builders.

Other noteworthy points: Guix doesn’t yet have an equivalent to
‘nix-env’; it supports multiple-derivation outputs (where a build
produces several files under /nix/store); package descriptions in the
mini-distro are internationalized; the distribution being written in
Scheme, it is compiled efficiently by Guile’s compiler.


Help needed!


It seems to me like a lot more can be done with this, and it’s fun!

If you’re a Nixer, you’re welcome to give it a try (you just need a
‘nix-worker’ instance running), attempt to build/package something, and
provide feedback on the API and declarative package expressions.

If you’re a Guiler, there are interesting challenges.  One is to write
more macros/EDSLs to provide builders with operations as high-level as
typically found in shell scripts (for instance, ‘substitute*’ attempts
to provide a sed-like API.)  Another one is to investigate whether/how
the code of builders could be generated hygienically (see
‘build-expression-derivation’.)

If you’re a GNU-system-discusser, feedback is welcome!  How would it fit
in a hypothetical GNU distribution?

Happy hacking  packaging!
Ludo’.

[*] http://nixos.org/nix/


pgpOmMoqOqCD1.pgp
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] [***SPAM***] [ANN] Guix, functional package management from Guile

[Ludovic Courtès]

Hey!

(Stripping Cc:.)

Shea Levy s...@shealevy.com skribis:

 On Jul 7, 2012, at 5:55 PM, l...@gnu.org (Ludovic Courtès) wrote:

 in Guix, the cheat code is the ‘nixpkgs-derivation’ procedure.  :-)

 Does the referenced derivation need to actually be in nixpkgs?

Yes.

 I assume this works by calling nix-instantiate?

Exactly.  :-)

  it supports multiple-derivation outputs (where a build produces
 several files under /nix/store)

 Just FYI, multiple-outputs support is not complete at the nix-store
 level. In particular, if you have one output of a derivation realized
 but not all (because you gc'd the others or got the one via a
 substitutor), nix-store can't realize the non-realized ones directly
 yet.

OK, that’s what I remembered from earlier discussions.

 There may be other issues I'm not aware of too.

Heheh, Eelco?  :-)

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

Re: [Nix-dev] Anarchy

[Ludovic Courtès]

Hi Michael,

Michael Weiss w...@borasi.de skribis:

 Let's talk about names.

In fact names don’t matter with Nix.  Each package is basically a
function that returns an attribute set and derivation or store path.
This result is a first-class object in the Nix language, so it can be
assigned to any variable, named however you like, and passed around.

Thanks,
Ludo’.

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

Re: [Nix-dev] Announcing free-nix: the free Linux distribution based on the Nix package manager

[Ludovic Courtès]

Hello!

Peter Simons sim...@cryp.to skribis:

 Eelco revoked all access of all regular contributors without prior
 warning.

While I agree that this is a major annoyance (especially as someone who
administrates a Hydra instance and is currently unable to help fix
bugs), I believe it’s mostly the consequence of Eelco and the rest of us
not taking the time to agree on a workflow, rather than a desire to
“reinforce the oligarchy”, to use your terms.  ;-)

I’d personally have preferred the switch to take place once there’s
consensus on the workflow, precisely to avoid that situation.  But I’m
sure Eelco did this in good faith.  And after all, I was among those who
bothered him to switch to Git, so I definitely won’t blame him for
taking the time to take care of this!

Cheers,
Ludo’.

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

Re: [Nix-dev] Announcing free-nix: the free Linux distribution based on the Nix package manager

[Ludovic Courtès]

Hi,

Peter Simons sim...@cryp.to skribis:

 However, that is exactly the kind of decision to be taken in a vote of
 majority. If the majority of community members feels that we should not
 package non-free software (according to some definition), then that's
 how it's going to be.

If I were you, I would make that decision upfront, making it part of the
distro’s identity.

Then, those who agree with the goal would join in, while others wouldn’t.

Thanks,
Ludo’.

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

Re: [Nix-dev] github notifications

[Ludovic Courtès]

Oh, and could we get diffs in the commit notifications?  :-)

Thanks,
Ludo’.

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

[Nix-dev] [PATCH] GNU Coreutils: Allow builds with newer versions of glibc.

[Ludovic Courtès]

---
 pkgs/tools/misc/coreutils/default.nix   |   11 +++-
 pkgs/tools/misc/coreutils/gets-undeclared.patch |   71 +++
 2 files changed, 80 insertions(+), 2 deletions(-)
 create mode 100644 pkgs/tools/misc/coreutils/gets-undeclared.patch

diff --git a/pkgs/tools/misc/coreutils/default.nix 
b/pkgs/tools/misc/coreutils/default.nix
index 597ab80..9d9ea52 100644
--- a/pkgs/tools/misc/coreutils/default.nix
+++ b/pkgs/tools/misc/coreutils/default.nix
@@ -20,7 +20,7 @@ stdenv.mkDerivation rec {
 ++ stdenv.lib.optional selinuxSupport libselinux
 ++ stdenv.lib.optional selinuxSupport libsepol;
 
-  crossAttrs = {
+  crossAttrs = ({
 buildInputs = [ gmp ]
   ++ stdenv.lib.optional aclSupport acl.hostDrv
   ++ stdenv.lib.optional selinuxSupport libselinux.hostDrv
@@ -32,7 +32,14 @@ stdenv.mkDerivation rec {
 # I don't know why it is not properly detected cross building with glibc.
 configureFlags = [ fu_cv_sys_stat_statfs2_bsize=yes ];
 doCheck = false;
-  };
+  }
+
+  //
+
+  # XXX: Temporary workaround to allow GNU/Hurd builds with newer libcs.
+  (stdenv.lib.optionalAttrs (stdenv.cross.config == i586-pc-gnu) {
+patches = [ ./gets-undeclared.patch ];
+  }));
 
   # The tests are known broken on Cygwin
   # (http://thread.gmane.org/gmane.comp.gnu.core-utils.bugs/19025),
diff --git a/pkgs/tools/misc/coreutils/gets-undeclared.patch 
b/pkgs/tools/misc/coreutils/gets-undeclared.patch
new file mode 100644
index 000..b6cdc77
--- /dev/null
+++ b/pkgs/tools/misc/coreutils/gets-undeclared.patch
@@ -0,0 +1,71 @@
+This patch is needed to allow builds with newer versions of
+the GNU libc (2.16+).
+
+
+commit 66712c23388e93e5c518ebc8515140fa0c807348
+Author: Eric Blake ebl...@redhat.com
+Date:   Thu Mar 29 13:30:41 2012 -0600
+
+stdio: don't assume gets any more
+
+Gnulib intentionally does not have a gets module, and now that C11
+and glibc have dropped it, we should be more proactive about warning
+any user on a platform that still has a declaration of this dangerous
+interface.
+
+* m4/stdio_h.m4 (gl_STDIO_H, gl_STDIO_H_DEFAULTS): Drop gets
+support.
+* modules/stdio (Makefile.am): Likewise.
+* lib/stdio-read.c (gets): Likewise.
+* tests/test-stdio-c++.cc: Likewise.
+* m4/warn-on-use.m4 (gl_WARN_ON_USE_PREPARE): Fix comment.
+* lib/stdio.in.h (gets): Make warning occur in more places.
+* doc/posix-functions/gets.texi (gets): Update documentation.
+Reported by Christer Solskogen.
+
+Signed-off-by: Eric Blake ebl...@redhat.com
+
+diff --git a/lib/stdio.in.h b/lib/stdio.in.h
+index aa7b599..c377b6e 100644
+--- a/lib/stdio.in.h
 b/lib/stdio.in.h
+@@ -698,22 +698,11 @@ _GL_WARN_ON_USE (getline, getline is unportable - 
+ # endif
+ #endif
+ 
+-#if @GNULIB_GETS@
+-# if @REPLACE_STDIO_READ_FUNCS@  @GNULIB_STDIO_H_NONBLOCKING@
+-#  if !(defined __cplusplus  defined GNULIB_NAMESPACE)
+-#   undef gets
+-#   define gets rpl_gets
+-#  endif
+-_GL_FUNCDECL_RPL (gets, char *, (char *s) _GL_ARG_NONNULL ((1)));
+-_GL_CXXALIAS_RPL (gets, char *, (char *s));
+-# else
+-_GL_CXXALIAS_SYS (gets, char *, (char *s));
+-#  undef gets
+-# endif
+-_GL_CXXALIASWARN (gets);
+ /* It is very rare that the developer ever has full control of stdin,
+-   so any use of gets warrants an unconditional warning.  Assume it is
+-   always declared, since it is required by C89.  */
++   so any use of gets warrants an unconditional warning; besides, C11
++   removed it.  */
++#undef gets
++#if HAVE_RAW_DECL_GETS
+ _GL_WARN_ON_USE (gets, gets is a security hole - use fgets instead);
+ #endif
+ 
+@@ -1053,9 +1042,9 @@ _GL_WARN_ON_USE (snprintf, snprintf is unportable - 
+ # endif
+ #endif
+ 
+-/* Some people would argue that sprintf should be handled like gets
+-   (for example, OpenBSD issues a link warning for both functions),
+-   since both can cause security holes due to buffer overruns.
++/* Some people would argue that all sprintf uses should be warned about
++   (for example, OpenBSD issues a link warning for it),
++   since it can cause security holes due to buffer overruns.
+However, we believe that sprintf can be used safely, and is more
+efficient than snprintf in those safe cases; and as proof of our
+belief, we use sprintf in several gnulib modules.  So this header
-- 
1.7.10.4

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