nix-build -A gnome3.glib Fails with the error at configure phase with:

docs/reference/meson.build:55:2: ERROR: Git program not found.

And trying this:

diff --git i/pkgs/development/libraries/glib/default.nix w/pkgs/development/libraries/glib/default.nix
index 797547cadd2..045560437c4 100644
--- i/pkgs/development/libraries/glib/default.nix
+++ w/pkgs/development/libraries/glib/default.nix
@@ -100,7 +100,7 @@ stdenv.mkDerivation rec {
   ]);
 
   nativeBuildInputs = [
-    meson ninja pkgconfig perl python3 gettext gtk-doc docbook_xsl docbook_xml_dtd_45
+    meson ninja pkgconfig perl python3 gettext gtk-doc docbook_xsl docbook_xml_dtd_45 buildPackages.git
   ];
 
   propagatedBuildInputs = [ zlib libffi gettext libiconv ];

I get:

error: while evaluating the attribute 'nativeBuildInputs' of the derivation 'glib-2.66.0' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'postPatch' of the derivation 'git-2.28.0' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'openssh-8.3p1' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'libfido2-1.4.0' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'hidapi-0.9.0' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'preFixup' of the derivation 'libusb-1.0.23' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating 'optionalString' at /home/doron/repos/nixpkgs/lib/strings.nix:180:5, called from /home/doron/repos/nixpkgs/pkgs/development/libraries/libusb1/default.nix:36:14:
while evaluating the attribute 'buildInputs' of the derivation 'systemd-246' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'cryptsetup-2.3.3' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'lvm2-2.03.10' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
while evaluating the attribute 'buildInputs' of the derivation 'systemd-246' at /home/doron/repos/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:192:11:
infinite recursion encountered, at undefined position

Which seems related to #97008 .

It's possible to fix this infinite recursion with this:

diff --git i/pkgs/development/libraries/glib/default.nix w/pkgs/development/libraries/glib/default.nix
index 797547cadd2..1bb6edff63f 100644
--- i/pkgs/development/libraries/glib/default.nix
+++ w/pkgs/development/libraries/glib/default.nix
@@ -100,15 +100,14 @@ stdenv.mkDerivation rec {
   ]);
 
   nativeBuildInputs = [
-    meson ninja pkgconfig perl python3 gettext gtk-doc docbook_xsl docbook_xml_dtd_45
+    meson ninja pkgconfig perl python3 gettext docbook_xsl docbook_xml_dtd_45
   ];
 
   propagatedBuildInputs = [ zlib libffi gettext libiconv ];
 
   mesonFlags = [
-    # Avoid the need for gobject introspection binaries in PATH in cross-compiling case.
-    # Instead we just copy them over from the native output.
-    "-Dgtk_doc=${if stdenv.hostPlatform == stdenv.buildPlatform then "true" else "false"}"
+    # Requiring this, requires git, which when evaluated, creates an infinite recursion
+    "-Dgtk_doc=false"
     "-Dnls=enabled"
     "-Ddevbindir=${placeholder ''dev''}/bin"
   ];

Switched target to staging, and fix glib build by disabling dev docs totally.

I think I need help with gobject introspection's shlib patches - i.e do something similar to this:

doronbehar@d747f16 by @hedning .

Please see also master...pbogdan:gnome-3.38 and master...hedning:gnome-3.38

Maybe we should start working in the gnome branch in this repo so that we do not have to keep merging stuff across repos.

#59372 is also useful for creating updates.

The issue with GLib docs is that they require gtk-doc >= 1.32.1. When that is not found, it will try to clone it with Git for some reason, instead of throwing a proper error.

The issue with GLib docs is that they require gtk-doc >= 1.32.1. When that is not found, it will try to clone it with Git for some reason, instead of throwing a proper error.

I see. I think that fix is still what's currently proper, since there is no 1.32.1 release according to: https://gitlab.gnome.org/GNOME/gtk-doc/-/tags .

Also I wonder if it makes sense to include glib update along side GNOME update itself? When I tested with 3.38 pre-release GNOME tarballs nothing needed dev version of glib, it would be surprising to me if that changed.

Locally I opted out of glib, librsvg, gobject-introspection and dconf updates - they weren't needed with pre-releases and I figured that considering the impact of each one of those it might be best to update those separately. Although jtojnar would probably know best.

IIRC we've always hit something needing the newer glib, but if that's avoidable it would make local builds more pleasant and could be worth it tbh. (though I don't think we'll be able to avoid webkitgtk builds :p).

Please see also master...pbogdan:gnome-3.38 and master...hedning:gnome-3.38
Maybe we should start working in the gnome branch in this repo so that we do not have to keep merging stuff across repos.

Yeah, I personally think us as gnome maintainers should be solely responsible for creating the next gnome branch gnome-3.38 in nixpkgs. With multiple contributors that aren't a part of the gnome team trying to contribute duplicated work just makes it more difficult for us. Of course everyone is free to contributor to the PR, I would just appreciate if we can wait until one of @NixOS/gnome makes the PR as that is their realm of expertise and responsibility. The actual reason issues like #95248 are opened is so any work made can be tracked to so we don't step on each others toes. It so happens that every so often in nixpkgs we'll see duplicated work, and it's not to discredit anyone's effort, but here's a working example: NeQuissimus's work in nixpkgs is to maintain and update linux packages and often just pushes to master. You're not going to see that "documented" but often I have to close PRs to linux packages because they've already been added or updated. @doronbehar I'm inclined to close this PR as we usually prefer to have an update commit for each package etc. (which #59372 actually allows to be done automatic), and we'd have to move it to a branch into nixpkgs anyways so the hydra jobset can run.

IIRC we've always hit something needing the newer glib, but if that's avoidable it would make local builds more pleasant and could be worth it tbh. (though I don't think we'll be able to avoid webkitgtk builds :p).

Indeed, after updating things I just ran into gvfs-1.46.0 needing newer glib :-/

Anyway, will leave it up to you folks.

@doronbehar I'm inclined to close this PR as we usually prefer to have an update commit for each package etc. (which #59372 actually allows to be done automatic), and we'd have to move it to a branch into nixpkgs anyways so the hydra jobset can run.

History can be rewritten but certainly having a gnome-3.38 branch in NixOS/nixpkgs would be better. I propose this scheme:

1. Open a PR for merging a new branch NixOS/gnome-3.38 into staging.
2. Tell contributors to target their PRs to the branch gnome-3.38, or push directly to it, if permitted.
3. Declare a hydra jobset for this gnome-3.38 branch, while it's PR is open.

Re: glib, the update is annoyingly causing some regressions (caught gom, gexiv2 failing their test suites). Will back out gvfs update and see how things go.

@doronbehar I'm inclined to close this PR as we usually prefer to have an update commit for each package etc. (which #59372 actually allows to be done automatic), and we'd have to move it to a branch into nixpkgs anyways so the hydra jobset can run.

History can be rewritten but certainly having a gnome-3.38 branch in NixOS/nixpkgs would be better. I propose this scheme:

1. Open a PR for merging a new branch `NixOS/gnome-3.38` into staging.

2. Tell contributors to target their PRs to the branch `gnome-3.38`, or push directly to it, if permitted.

3. Declare a hydra jobset for this `gnome-3.38` branch, while it's PR is open.

... we already do this

... Please look at previous PRs #81626. GitHub makes it very easy to delete branches when a PR is merged. I've pushed a gnome-3.38 branch a few minutes ago (though there's no changes there yet). Will ping an infra person to update https://hydra.nixos.org/jobset/nixpkgs/gnome#tabs-configuration when it has something to do.

OK so I'm closing. Maybe the gnome-3.38 branch should start with the glib update? Then with a hydra jobset it'll be easy to detect regressions?

FWIW dropping the gvfs and glib updates is sufficient to at least build GNOME installer ISO.

@doronbehar I don't think @jtojnar or @hedning is going to get this anytime soon (I'm also busy with RM stuff and nixcon).
Feel free to push to gnome-3.38 with a commit for each package updated (and PR). #59372 should help with that. That would help get things going to push stuff etc. Feel free to PM me any questions to actually join the #nixos-gnome irc channel.