Re: [Nix-dev] Can't unsubscribe
You could unsubscribe with email http://www.list.org/mailman-member/node14.html 2015-08-17 1:00 GMT+03:00 Miroslav Puda : > Hi, I can't get pasword reminder nor unsubscribe myself on > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > Can someone fix it or at least unsubscribe my address manually please? I am > not receiving password reminder nor unsubscribe confirmation mail. > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mxe on NixOS
Using nix-shell -A glib is wrong if you are going to use autogen.sh,
because autogen.sh is used to build from git not from tarball. So the glib
nix expression does not have neither autoconf nor automake in the
buildInputs for this reason.
Put autoconf and automake in the buildInputs of the glib nix expression,
then it should work.
On Mon, Aug 17, 2015 at 6:45 AM, James Cook wrote:
> pkg-config is in my environment.
>
> If it means anything, I see the same error if I run ./autogen.sh
> inside nix-shell -A glib (still using my manually-cloned glib).
>
> James
>
> On 16 August 2015 at 01:41, Luca Bruno wrote:
> >
> >
> > On Sunday, August 16, 2015, James Cook wrote:
> >>
> >> To perhaps simplify the problem, does anyone know how to build glib on
> >> a NixOS system the old-fashioned way, without using nix? If I just run
> >> ./autogen.sh in a fresh glib checkout, I get a similar error to the
> >> one Andrew is getting.
> >>
> >> A parallel question: Andrew, are you familiar enough with nixpkgs to
> >> try writing an nix expression that unpacks mxe and tells it to build
> >> glib? That might be another approach, though I think it would be nice
> >> if users had the option of not doing it that way.
> >>
> >> $ ./autogen.sh
> >> You don't have gtk-doc installed, and thus won't be able to generate
> >> the documentation.
> >> autoreconf: Entering directory `.'
> >> autoreconf: configure.ac: not using Gettext
> >> autoreconf: running: aclocal --force -I m4macros ${ACLOCAL_FLAGS}
> >> autoreconf: configure.ac: tracing
> >> autoreconf: configure.ac: not using Libtool
> >> autoreconf: running:
> >> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
> >> --force
> >> configure.ac:88: error: possibly undefined macro: AC_DEFINE
> >> If this token and others are legitimate, please use
> >> m4_pattern_allow.
> >> See the Autoconf documentation.
> >> autoreconf:
> >> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
> >> failed with exit status: 1
> >
> >
> > You need pkgconfig in your env.
> >
> >
> > --
> > NixOS Linux
> >
>
--
NixOS Linux
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Announce: opam2nix
Announcing `opam2nix`, my still-early project to derive nix
expressions from OPAM ocaml packages:
https://github.com/gfxmonk/opam2nix/
It's almost entirely driven from vanilla `opam` repo data[0], aside
from a few tweaks to `findlib` to integrate its nix hooks (adding
build inputs to $OCAMLFIND_DESTDIR).
The github page has the details on how to use it, but one thing which
might differ from other similar systems is that the packages produced
aren't ready to be imported directly - they need to be given a set of
selections - equivalent to the set of all installed packages in an
`opam` env. There are a couple of reasons for this:
1) There are a lot of optional dependencies in the opam universe, and
installing _all_ of them might be a bit much (and could even create
conflicts where a more minimal set would work)
2) Having each dependency select its own preferred version of e.g.
`extlib` might mean that your dependencies each come with a different
`extlib` version, and I don't think that will work.
3) Because of (2), it also doesn't make much sense to pre-solve each
package. Maybe `libfoo` can use the latest version of `libcommon`, but
if you're _also_ using `libbar` then maybe you need to use an older
version of `libcommon` which satisfies the requirements of both
libraries.
I don't know how other tools like cabal2nix get around this issue, I'd
be interested in any advice on how to make this better / easier.
Using this tool, I've so far been able to successfully generate (and
build) all dependencies of `opam-lib`, and I'm getting quite close to
a working mirage-xen install. Which felt like a good point to publish
it and see what others think. Ideally I'd like to make it part of
nixpkgs, which might help us include more opam packages, and keep them
up to date easily. So I'd appreciate any advice from maintainers of
existing ocaml packages in nixpkgs, if you have thoughts :)
The generated selection file for `opam-lib` looks like this, if you're curious:
{ pkgs, opam2nix, opamPackages, ocaml ? pkgs.ocaml,
builder ? opamSelection: pkg: pkgs.callPackage pkg.impl {
inherit opamSelection opam2nix; },
overrideSelections ? sels: sels
}:
let
selection = overrideSelections
{
base-bigarray = true;
base-bytes = builder selection
(opamPackages.base-bytes.legacy);
base-threads = true;
base-unix = true;
camlp4 = builder selection
(opamPackages.camlp4."4.01");
cmdliner = builder selection
(opamPackages.cmdliner."0.9.7");
cudf = builder selection (opamPackages.cudf."0.7");
dose = builder selection (opamPackages.dose."3.3");
extlib = builder selection
(opamPackages.extlib."1.6.1");
jsonm = builder selection
(opamPackages.jsonm."0.9.1");
ocaml = ocaml;
ocamlfind = builder selection
(opamPackages.ocamlfind."1.5.5");
ocamlgraph = builder selection
(opamPackages.ocamlgraph."1.8.5");
opam-lib = builder selection
(opamPackages.opam-lib."1.2.2");
re = builder selection (opamPackages.re."1.4.1");
uutf = builder selection (opamPackages.uutf."0.9.4");
};
in
selection
(the pretty-printing could do with some work, though...)
[0] well, my fork at https://github.com/gfxmonk/opam-repository
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mxe on NixOS
Thanks. Adding autoconf, automake and libtool to buildInputs for glib
and running nix-shell -A glib put be in an environment where I can
successfully run autogen.sh.
Any idea why it only works in a nix-shell instance? I have autoconf,
automake, libtool installed via nix-env.
(Andrew, are you still hoping to get this working?)
James
On 17 August 2015 at 02:07, Luca Bruno wrote:
> Using nix-shell -A glib is wrong if you are going to use autogen.sh, because
> autogen.sh is used to build from git not from tarball. So the glib nix
> expression does not have neither autoconf nor automake in the buildInputs
> for this reason.
>
> Put autoconf and automake in the buildInputs of the glib nix expression,
> then it should work.
>
> On Mon, Aug 17, 2015 at 6:45 AM, James Cook wrote:
>>
>> pkg-config is in my environment.
>>
>> If it means anything, I see the same error if I run ./autogen.sh
>> inside nix-shell -A glib (still using my manually-cloned glib).
>>
>> James
>>
>> On 16 August 2015 at 01:41, Luca Bruno wrote:
>> >
>> >
>> > On Sunday, August 16, 2015, James Cook wrote:
>> >>
>> >> To perhaps simplify the problem, does anyone know how to build glib on
>> >> a NixOS system the old-fashioned way, without using nix? If I just run
>> >> ./autogen.sh in a fresh glib checkout, I get a similar error to the
>> >> one Andrew is getting.
>> >>
>> >> A parallel question: Andrew, are you familiar enough with nixpkgs to
>> >> try writing an nix expression that unpacks mxe and tells it to build
>> >> glib? That might be another approach, though I think it would be nice
>> >> if users had the option of not doing it that way.
>> >>
>> >> $ ./autogen.sh
>> >> You don't have gtk-doc installed, and thus won't be able to generate
>> >> the documentation.
>> >> autoreconf: Entering directory `.'
>> >> autoreconf: configure.ac: not using Gettext
>> >> autoreconf: running: aclocal --force -I m4macros ${ACLOCAL_FLAGS}
>> >> autoreconf: configure.ac: tracing
>> >> autoreconf: configure.ac: not using Libtool
>> >> autoreconf: running:
>> >> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
>> >> --force
>> >> configure.ac:88: error: possibly undefined macro: AC_DEFINE
>> >> If this token and others are legitimate, please use
>> >> m4_pattern_allow.
>> >> See the Autoconf documentation.
>> >> autoreconf:
>> >> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
>> >> failed with exit status: 1
>> >
>> >
>> > You need pkgconfig in your env.
>> >
>> >
>> > --
>> > NixOS Linux
>> >
>
>
>
>
> --
> NixOS Linux
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mxe on NixOS
On Mon, Aug 17, 2015 at 10:01 PM James Cook wrote:
> Thanks. Adding autoconf, automake and libtool to buildInputs for glib
> and running nix-shell -A glib put be in an environment where I can
> successfully run autogen.sh.
>
> Any idea why it only works in a nix-shell instance? I have autoconf,
> automake, libtool installed via nix-env.
>
> (Andrew, are you still hoping to get this working?)
>
Yes I am.
My current strategy is this .nix file:
with import {}; {
mxeEnv = stdenv.mkDerivation {
name = "mxe";
buildInputs = [
autoconf
automake
gnumake
bison
cmake
flex
gettext
gperf
intltool
libtool
openssl
ruby
scons
unzip
pkgconfig
python
wget
];
};
}
Then I use `nix-shell mxe.nix` and attempt to `make glib`, and I get the
issue I originally reported.
Am I understanding correctly that you are doing something slightly
different and successfully able to build glib with mxe?
>
> James
>
>
> On 17 August 2015 at 02:07, Luca Bruno wrote:
> > Using nix-shell -A glib is wrong if you are going to use autogen.sh,
> because
> > autogen.sh is used to build from git not from tarball. So the glib nix
> > expression does not have neither autoconf nor automake in the buildInputs
> > for this reason.
> >
> > Put autoconf and automake in the buildInputs of the glib nix expression,
> > then it should work.
> >
> > On Mon, Aug 17, 2015 at 6:45 AM, James Cook
> wrote:
> >>
> >> pkg-config is in my environment.
> >>
> >> If it means anything, I see the same error if I run ./autogen.sh
> >> inside nix-shell -A glib (still using my manually-cloned glib).
> >>
> >> James
> >>
> >> On 16 August 2015 at 01:41, Luca Bruno wrote:
> >> >
> >> >
> >> > On Sunday, August 16, 2015, James Cook
> wrote:
> >> >>
> >> >> To perhaps simplify the problem, does anyone know how to build glib
> on
> >> >> a NixOS system the old-fashioned way, without using nix? If I just
> run
> >> >> ./autogen.sh in a fresh glib checkout, I get a similar error to the
> >> >> one Andrew is getting.
> >> >>
> >> >> A parallel question: Andrew, are you familiar enough with nixpkgs to
> >> >> try writing an nix expression that unpacks mxe and tells it to build
> >> >> glib? That might be another approach, though I think it would be nice
> >> >> if users had the option of not doing it that way.
>
I'm not familiar enough to do so currently but I'm willing to learn. I do
agree with you that it would be nice if users had the option of not doing
it this way.
> >> >>
> >> >> $ ./autogen.sh
> >> >> You don't have gtk-doc installed, and thus won't be able to generate
> >> >> the documentation.
> >> >> autoreconf: Entering directory `.'
> >> >> autoreconf: configure.ac: not using Gettext
> >> >> autoreconf: running: aclocal --force -I m4macros ${ACLOCAL_FLAGS}
> >> >> autoreconf: configure.ac: tracing
> >> >> autoreconf: configure.ac: not using Libtool
> >> >> autoreconf: running:
> >> >>
> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
> >> >> --force
> >> >> configure.ac:88: error: possibly undefined macro: AC_DEFINE
> >> >> If this token and others are legitimate, please use
> >> >> m4_pattern_allow.
> >> >> See the Autoconf documentation.
> >> >> autoreconf:
> >> >>
> /nix/store/prmn46fajbj2ymcw43aqrdfbii1bj8bz-autoconf-2.69/bin/autoconf
> >> >> failed with exit status: 1
> >> >
> >> >
> >> > You need pkgconfig in your env.
> >> >
> >> >
> >> > --
> >> > NixOS Linux
> >> >
> >
> >
> >
> >
> > --
> > NixOS Linux
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mxe on NixOS
>> Thanks. Adding autoconf, automake and libtool to buildInputs for glib
>> and running nix-shell -A glib put be in an environment where I can
>> successfully run autogen.sh.
>>
>> Any idea why it only works in a nix-shell instance? I have autoconf,
>> automake, libtool installed via nix-env.
>>
>> (Andrew, are you still hoping to get this working?)
>
>
> Yes I am.
>
> My current strategy is this .nix file:
>
> with import {}; {
> mxeEnv = stdenv.mkDerivation {
> name = "mxe";
> buildInputs = [
> autoconf
> automake
> gnumake
> bison
> cmake
> flex
> gettext
> gperf
> intltool
> libtool
> openssl
> ruby
> scons
> unzip
> pkgconfig
> python
> wget
> ];
> };
> }
>
> Then I use `nix-shell mxe.nix` and attempt to `make glib`, and I get the
> issue I originally reported.
>
> Am I understanding correctly that you are doing something slightly different
> and successfully able to build glib with mxe?
No, I'm not using mxe at all, and I've only tried running autogen.sh.
Unless someone chimes in and points out why building glib outside
nix-shell isn't working, a couple of ideas if you haven't already
tried them:
* Try starting with the glib derivation: add autoconf, automake and
libtool to pkgs/development/libraries/glib/default.nix and use
nix-shell -A glib.
* With that method, can you build vanilla, non-mxe glib?
(https://github.com/GNOME/glib) If not, we must be doing something
different...
* If you can successfully build ordinary glib that way, but can't
build mxe glib, it might be time to take it back to the mxe people.
James
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mxe on NixOS
On Mon, Aug 17, 2015 at 10:13 PM, James Cook wrote:
> No, I'm not using mxe at all, and I've only tried running autogen.sh.
>
> Unless someone chimes in and points out why building glib outside
> nix-shell isn't working, a couple of ideas if you haven't already
> tried them:
>
> * Try starting with the glib derivation: add autoconf, automake and
> libtool to pkgs/development/libraries/glib/default.nix and use
> nix-shell -A glib.
>
I forked nixpkgs and then did this modification:
diff --git a/pkgs/development/libraries/glib/default.nix
b/pkgs/development/libraries/glib/default.nix
index fb9c361..ad2eba4 100644
--- a/pkgs/development/libraries/glib/default.nix
+++ b/pkgs/development/libraries/glib/default.nix
@@ -1,5 +1,6 @@
{ stdenv, fetchurl, pkgconfig, gettext, perl, python
, libiconv, libintlOrEmpty, zlib, libffi, pcre, libelf
+, autoconf, automake, libtool
# this is just for tests (not in closure of any regular package)
, coreutils, dbus_daemon, libxml2, tzdata, desktop_file_utils,
shared_mime_info, doCheck ? false
@@ -55,7 +56,7 @@ stdenv.mkDerivation rec {
setupHook = ./setup-hook.sh;
- buildInputs = [ libelf ]
+ buildInputs = [ libelf autoconf automake libtool ]
++ optionals doCheck [ tzdata libxml2 desktop_file_utils
shared_mime_info ];
nativeBuildInputs = [ pkgconfig gettext perl python ];
Then I tried `NIX_PATH=nixpkgs=/home/andy/dev/nixpkgs nix-shell -A glib`
but it did not need to recompile glib. Not sure what's going on with that.
Then I tried `nix-build -A glib` which as I understand uses the current
directory (which was /home/andy/dev/nixpkgs) and that did trigger a build
of glib, which succeeded.
>
> * With that method, can you build vanilla, non-mxe glib?
> (https://github.com/GNOME/glib) If not, we must be doing something
> different...
>
Do you mean building it from source using ./autogen.sh as you did earlier?
I tried that just now and it worked fine. I used this for nix-shell:
with import {}; {
glibEnv = stdenv.mkDerivation {
name = "glib";
buildInputs = [
gnome.gtk_doc
autoconf
automake
gnumake
bison
cmake
flex
gettext
gperf
intltool
libtool
pkgconfig
openssl
ruby
scons
unzip
python
wget
zlib
libffi
];
};
}
The extra packages are packages that are in the mxe nix-shell environment;
I thought I'd try to keep the environments close to see what would happen.
>
> * If you can successfully build ordinary glib that way, but can't
> build mxe glib, it might be time to take it back to the mxe people.
>
OK so it sounds like maybe this is an mxe issue after all?
>
> James
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
