Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: gnome3: Update all gnome3. packages #98216

Closed
wants to merge 5 commits into from

Conversation

@doronbehar
Copy link
Contributor

@doronbehar doronbehar commented Sep 18, 2020

Motivation for this change

#95248

Things done

Ran nix-shell maintainers/scripts/update.nix --argstr path gnome3.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 18, 2020

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 .

@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 18, 2020

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"
   ];
@doronbehar doronbehar force-pushed the doronbehar:pkg/gnome3/updates branch from 6149d68 to b4cb712 Sep 18, 2020
@doronbehar doronbehar changed the base branch from master to staging Sep 18, 2020
@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 18, 2020

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

@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 18, 2020

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

doronbehar@d747f16 by @hedning .

@doronbehar doronbehar changed the title gnome3: Update all gnome3. packages WIP: gnome3: Update all gnome3. packages Sep 18, 2020
@jtojnar
Copy link
Contributor

@jtojnar jtojnar commented Sep 18, 2020

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.

@jtojnar
Copy link
Contributor

@jtojnar jtojnar commented Sep 18, 2020

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.

@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 18, 2020

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 .

@pbogdan
Copy link
Member

@pbogdan pbogdan commented Sep 18, 2020

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.

@hedning
Copy link
Contributor

@hedning hedning commented Sep 18, 2020

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).

@worldofpeace
Copy link
Member

@worldofpeace worldofpeace commented Sep 18, 2020

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.

@pbogdan
Copy link
Member

@pbogdan pbogdan commented Sep 18, 2020

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
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 19, 2020

@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.
@pbogdan
Copy link
Member

@pbogdan pbogdan commented Sep 19, 2020

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.

@worldofpeace
Copy link
Member

@worldofpeace worldofpeace commented Sep 19, 2020

@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

@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 19, 2020

Screenshot from 2020-09-19 19-56-01

@worldofpeace
Copy link
Member

@worldofpeace worldofpeace commented Sep 19, 2020

Screenshot from 2020-09-19 19-56-01

... 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.

@doronbehar
Copy link
Contributor Author

@doronbehar doronbehar commented Sep 19, 2020

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?

@doronbehar doronbehar closed this Sep 19, 2020
@pbogdan
Copy link
Member

@pbogdan pbogdan commented Sep 19, 2020

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

@worldofpeace
Copy link
Member

@worldofpeace worldofpeace commented Sep 19, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.