GNOME updates 2023-07-04

[jtojnar]

Description of changes

Changelogs and build system diffs look okay.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[bobby285271]

https://gitlab.gnome.org/GNOME/gcab/-/compare/1.5...1.6

Sounds like the update script generates wrong url 😆

tracker-miners: 3.5.0 → 3.5.2

Do we still wish to patch #228639?

[fabianhjr]

changes lgtm, built and booted into NixOS x86-64

[jtojnar]

gitlab.gnome.org/GNOME/gcab/-/compare/1.5...1.6

Sounds like the update script generates wrong url 😆

Ugh, I must have fixed it in the wrong branch. Still need to come up with a sensible way to do it automatically. Pushed the new commit message.

Do we still wish to patch #228639?

Ugh, I forgot about that. Skipping that for now. Will need to get in touch with upstream and hash it out.

[jtojnar]

Added some more GNOME dependencies and apps. Checked their changelogs as well and made sure the apps (+GIMP and Inkscape) run.

[bobby285271]

Also tested simple trashing, simple deja-dup backup & restore and geary mail receive.

• I never heard of MS-RL license before, thanks debian for telling me it is free 💦
• Specifically checked duplicity 0.8.23 supports "incremental" as subcommand

I just called ofborg to build stuff and looks like there are some surprising failures 🙃

• I can see umfpack_dl_solve in suitesparse 5.13.0 but not sure why darwin fails on the change
• The flaky test_headset_hotplug upower test failure is hopefully fixed in this commit so we probably need 1.90.2
• Haven't looked at the lib2geom thing yet

[jtojnar]

I can see umfpack_dl_solve in suitesparse 5.13.0 but not sure why darwin fails on the change

Good catch. I must have missed the change. It looks like the symbol is in a different header:

$ rg umfpack_dl_solve result-dev
result-dev/include/umfpack_solve.h

But the result-dev/include/umfpack.h includes umfpack_solve.h without any extra conditionals so I would expect it to just work.

git diff --no-index $(nix-build -A suitesparse.dev) $(nix-build --system aarch64-darwin -A suitesparse.dev) does not report any changes other than store path.

So it is weird that we get the following on Linux:

Header "umfpack.h" has symbol "umfpack_dl_solve" : YES 
Header "suitesparse/umfpack.h" has symbol "umfpack_dl_solve" : NO 

While the following on Nix darwin:

Header "umfpack.h" has symbol "umfpack_dl_solve" : NO
Header "suitesparse/umfpack.h" has symbol "umfpack_dl_solve" : NO

Would be nice to get hands on /build/gegl-0.4.46/build/meson-logs/meson-log.txt.

[jtojnar]

• The flaky test_headset_hotplug upower test failure is hopefully fixed in this commit so we probably need 1.90.2

That version requires newer libgudev #241939, dropped upower bump for now.

• Haven't looked at the lib2geom thing yet

Dropped for now.

Edit: Reported the test failng on aarch64-linux in https://gitlab.com/inkscape/lib2geom/-/issues/63 and the build failure with Clang in https://gitlab.com/inkscape/lib2geom/-/issues/62

[jtojnar]

So it is weird that we get the following on Linux:

Header "umfpack.h" has symbol "umfpack_dl_solve" : YES 
Header "suitesparse/umfpack.h" has symbol "umfpack_dl_solve" : NO 

I can reproduce this on Linux with clangStdenv.

[jtojnar]

Looks like it is downfall from us passing -lm to NIX_CFLAGS_COMPILE:

Running compile:
Working directory:  /build/gegl-0.4.46/build/meson-private/tmpruwqel_w
Command line:  clang /build/gegl-0.4.46/build/meson-private/tmpruwqel_w/testfile.c -o /build/gegl-0.4.46/build/meson-private/tmpruwqel_w/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -Werror=implicit-function-declaration -Werror=unknown-warning-option -Werror=unused-command-line-argument -Werror=ignored-optimization-argument -std=gnu11 

Code:
 
        #include <umfpack.h>
        int main(void) {
            /* If it's not defined as a macro, try to use as a symbol */
            #ifndef umfpack_dl_solve
                umfpack_dl_solve;
            #endif
            return 0;
        }
Compiler stdout:
 
Compiler stderr:
 clang-11: error: -lm: 'linker' input unused [-Werror,-Wunused-command-line-argument]

Header "umfpack.h" has symbol "umfpack_dl_solve" : NO 

[jtojnar]

I opened an upstream fix for the GEGL issue and moved the update to #242333 until we get a response from upstream.

[jtojnar]

Update GNOME Shell as well. Booted into GNOME VM, did not notice any issues. nixosTests.gnome-xorg and nixosTests.gnome pass.