Am Mittwoch, 2. Januar 2013 schrieb Ludovic Courtès:
> You mean (guix packages ...) or (packages ...)? The latter seems like a
> bad idea, because it could collide with something else, and it’s not
> sufficiently descriptive (it could be confused with Guile’s guildhall
> packaging system, for inst
Hello,
in the core-updates branch, tarballs are not downloaded automatically any
more. Here is the result of "guix-build hello" (which tries to rebuild
everything, as expected):
...
starting download of `/nix/store/c09pc1yvdai4ylb5i7x242aj66dy3f07-
glibc-2.17.tar.xz' from
`http://ftpmirror.gnu
Am Sonntag, 30. Dezember 2012 schrieb Ludovic Courtès:
> Andreas Enge skribis:
> > A tiny update to core-updates.
> It’s OK for master since it doesn’t trigger a rebuild of the core tools.
That is surprising; should automake not be an implicit input for all
packages using the gnu build system?
Hello,
when executing
guix-package --list-available | grep mit
I see two packages:
mit-krb51.11distro/packages/mit-krb5.scm:29:3
mit-krb51.11distro/packages/sasl.scm:145:3
The first one is the really available one; the second one was contained in
a file sasl.scm in an
Hi!
Andreas Enge skribis:
> Am Mittwoch, 2. Januar 2013 schrieb Ludovic Courtès:
>> You mean (guix packages ...) or (packages ...)? The latter seems like a
>> bad idea, because it could collide with something else, and it’s not
>> sufficiently descriptive (it could be confused with Guile’s guil
Hi,
Nikita Karetnikov skribis:
>>> +(define (roll-back)
>>> + "Roll back to the previous profile."
>
>> Please add a ‘profile’ parameter, as for the other functions.
>>
>> It should be possible to run:
>>
>> $ guix-package -p foo --roll-back
>
> Should I add any profile-related sanity checks
Andreas Enge skribis:
> Am Sonntag, 30. Dezember 2012 schrieb Ludovic Courtès:
>> Andreas Enge skribis:
>> > A tiny update to core-updates.
>> It’s OK for master since it doesn’t trigger a rebuild of the core tools.
>
> That is surprising; should automake not be an implicit input for all
> pack
Hi,
Andreas Enge skribis:
> when executing
>guix-package --list-available | grep mit
> I see two packages:
> mit-krb51.11distro/packages/mit-krb5.scm:29:3
> mit-krb51.11distro/packages/sasl.scm:145:3
>
> The first one is the really available one; the second one was co
Andreas Enge skribis:
> in the core-updates branch, tarballs are not downloaded automatically any
> more. Here is the result of "guix-build hello" (which tries to rebuild
> everything, as expected):
I can’t reproduce it:
--8<---cut here---start->8---
$ ./pr
Hello {N,Gu}ixers, and happy new year!
The ‘core-updates’ branch of Guix now makes it possible to build
packages in a chroot lacking /bin/sh.
It’s convenient to have /bin/sh in the chroot, because that’s basically
one of the files whose name is hardcoded in many places, from libc to
shebangs.
Ho
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> No: Autoconf/Automake/Libtool have the advantage of /not/ being
> prerequisites for building packages that use them.
You mean that the output of the autotools is independent of their version
(assuming that a recent enough version is used so
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> Most likely this is because nscd is not running, or not listening to the
> right socket:
>
> --8<---cut here---start->8---
> $ strace -o ,,s
> /nix/store/k8qmk5n2zsrndvzqs4bq7x9jyyxf5ndr-guile-bootstrap-2.
Andreas Enge skribis:
> Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
>> No: Autoconf/Automake/Libtool have the advantage of /not/ being
>> prerequisites for building packages that use them.
>
> You mean that the output of the autotools is independent of their version
> (assuming that a
Andreas Enge skribis:
> Here is what I get:
> connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1
> ENOENT (No such file or directory)
> connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1
> ENOENT (No such file or directory)
OK, this confirms my intuition
Hi Ludo,
• 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 buil
Hi Rob!
Rob Vermaas 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.
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> I suppose the file sasl.scm still exists along with the other files.
> Even if it’s not under version control, the module-listing code in
> distro.scm will stumble upon it, and thus list any packages that it
> exports.
Yes and no - it still
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> Right, it’s not independent of the autotools that were used.
> What I meant is that an autotools-generated tarball contains a build
> system whose sole requirement is a Bourne shell and a POSIX make.
Yes, you are right, sorry for my confusio
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> No, because eventually there’ll be (distro system ...) too–the
> equivalent of what NixOS is to Nixpkgs, if you see what i mean.
Okay, I see.
Andreas
Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
> It works for name lookups in general, including DNS lookups. It’s
> useful to always enable it.
So should this be checked by ./configure?
I am still not sure why this is needed; the "host" command does work and I
can surf the web, so ther
Andreas Enge skribis:
> Would it make sense to first empty $PREFIX/share/guile/site/2.0 before
> installing the files during "make install"?
I don’t think so, that’s not what usually happens upon “make install”.
Ludo’.
Andreas Enge skribis:
> Am Donnerstag, 3. Januar 2013 schrieb Ludovic Courtès:
>> It works for name lookups in general, including DNS lookups. It’s
>> useful to always enable it.
>
> So should this be checked by ./configure?
It wouldn’t be enough: nscd could be running at configure time, and no
22 matches
Mail list logo
