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

libfm: use finalAttrs pattern and remove with lib; #371519

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

stepbrobd
Copy link
Member

@stepbrobd stepbrobd commented Jan 6, 2025

Original:

Address #368590 (comment)

Edit:

I did some digging and figured the lxde/libfm@fbcd183 patch does not apply to the source distributed on sourceforge, only this vendored patch addresses the gcc 14 incompatible-pointer-types error, thus I'm changing this to a minor refactor

Diff between

github and sourceforge

$ diff -r github/ sourceforge/
Only in github: .gitignore
Only in github: .hgignore
Only in sourceforge: Makefile.in
Only in sourceforge: aclocal.m4
Only in sourceforge: ar-lib
Only in github: autogen.sh
Only in github: checks
Only in sourceforge: compile
Only in sourceforge: config.guess
Only in sourceforge: config.h.in
Only in sourceforge: config.sub
Only in sourceforge: configure
Only in sourceforge/data: Makefile.in
Only in sourceforge/data: libfm-pref-apps.1
Only in sourceforge/data: libfm-pref-apps.desktop
Only in sourceforge/data: lxshortcut.1
Only in sourceforge/data: lxshortcut.desktop
Only in sourceforge/data/ui: Makefile.in
Only in sourceforge/data/ui: app-chooser.ui
Only in sourceforge/data/ui: ask-rename.ui
Only in sourceforge/data/ui: exec-file.ui
Only in sourceforge/data/ui: file-prop.ui
Only in sourceforge/data/ui: filesearch.ui
Only in sourceforge/data/ui: preferred-apps.ui
Only in sourceforge/data/ui: progress.ui
Only in sourceforge: depcomp
Only in sourceforge/docs: Makefile.in
Only in sourceforge/docs/reference: Makefile.in
Only in sourceforge/docs/reference/libfm: Makefile.in
Only in sourceforge: gtk-doc.make
Only in sourceforge: install-sh
Only in sourceforge: ltmain.sh
Only in github/m4: .gitignore
Only in sourceforge/m4: gtk-doc.m4
Only in sourceforge/m4: intltool.m4
Only in sourceforge/m4: libtool.m4
Only in sourceforge/m4: ltoptions.m4
Only in sourceforge/m4: ltsugar.m4
Only in sourceforge/m4: ltversion.m4
Only in sourceforge/m4: lt~obsolete.m4
Only in sourceforge: missing
Only in sourceforge/po: LINGUAS
Only in sourceforge/po: Makefile.in.in
Only in sourceforge/src: Makefile.in
Only in sourceforge/src/actions: Makefile.in
Only in sourceforge/src/actions: action.c
Only in sourceforge/src/actions: condition.c
Only in sourceforge/src/actions: fm-actions.h
Only in sourceforge/src/actions: libfmactions_la_vala.stamp
Only in sourceforge/src/actions: parameters.c
Only in sourceforge/src/actions: profile.c
Only in sourceforge/src/actions: utils.c
Only in sourceforge/src/base: fm-marshal.c
Only in sourceforge/src/base: fm-marshal.h
Only in sourceforge/src: fm-version.h
Only in github/src/gtk/exo: test.c
Only in sourceforge/src/gtk: fm-gtk-marshal.c
Only in sourceforge/src/gtk: fm-gtk-marshal.h
Only in sourceforge/src/modules: Makefile.in
Only in sourceforge/src/tests: Makefile.in

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • 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/)
  • 25.05 Release Notes (or backporting 24.11 and 25.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.

Add a 👍 reaction to pull requests you find important.

@emilazy
Copy link
Member

emilazy commented Jan 6, 2025

FWIW as the person who did the GCC bump, I pretty strongly disagree with @jtojnar about this – I much prefer patching to disabling warning flags. Patches ideally become obsolete and get removed when they fail to apply, but disabling these errors both hides real problems in code and pretty much ensures that nobody will check whether they’ve become unnecessary for a long time. Those kinds of workarounds usually cause more pain down the line.

fetchpatch is nicer than vendoring if we have stable URLs, though. Applying the upstream fix from lxde/libfm@fbcd183 would be ideal.

@stepbrobd
Copy link
Member Author

There are quite a few cases (62 as of now) where incompatible-pointer-types are disabled instead of patching: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs%20env%20NIX_CFLAGS_COMPILE%20%3D%20%22-Wno-error%3Dincompatible-pointer-types%22&type=code, what should we do about those?

@emilazy
Copy link
Member

emilazy commented Jan 6, 2025

Create a bunch of clones of me so that I can catch every PR doing it and look for upstream and distro patches to avoid it :)

I do what I can, but there’s only so many hours in the day. Hopefully some of those will get removed on later updates, but probably a lot of them won’t. I try to clean that stuff up when I have to change a package for unrelated reasons, and at some point I may do a treewide sweep to try and get rid of the ones added for GCC 14 / LLVM 19.

One trick I like, when there’s no other alternative, is to guard the flags behind assert finalAttrs.version == "…"; … so that they must be checked on the next bump. In this case, however, fetchpatching the upstream fix seems easy.

@jtojnar
Copy link
Member

jtojnar commented Jan 6, 2025

Generally, I prefer patches as the way of resolving issues for the reasons Emily mentions.

However, in this case introducing four patch files for trivial casts felt to me like too much of an overhead.

She is right that flags are easily missed during updates but I did not think that was that serious here:

  • -Wno-error is just a no-op when the error is not present.
  • Since we use specific error name, I would not expect more instances to occur without updating the package.
    • This will not happen when the upstream is dead.

I have only later discovered that the Git repo is active again. This being the case, the concern about forgetting to remove the flag becomes more relevant. I agree that fetchpatching then becomes preferable solution.

@emilazy
Copy link
Member

emilazy commented Jan 6, 2025

Yeah, I think the main missing context here was that I didn’t know upstream was presumed dead; for ancient software with no prospect of update I have no objection to piling on the flags. (Personally in that case I’m more receptive to applying third‐party patch sets anyway – e.g. Debian is effectively the replacement upstream for a lot of abandoned libraries – but I can understand preferences differing there.)

@stepbrobd stepbrobd force-pushed the libfm branch 3 times, most recently from e4d98ec to bfcf770 Compare January 7, 2025 01:03
@stepbrobd stepbrobd changed the title libfm: disable incompatible-pointer-types instead of patching libfm: use finalAttrs pattern and remove with lib; Jan 7, 2025
@github-actions github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux and removed 10.rebuild-darwin: 1-10 10.rebuild-linux: 11-100 labels Jan 7, 2025
@stepbrobd
Copy link
Member Author

I somehow remembered why I didn't go with fetchpatch in the first place. The patch from lxde doesn't apply here since we are using the sourceforge distribution, I wasn't able to find an upstream patch that addresses the gcc 14 incompatible-pointer-types for the sourceforge version, so I vendored it. Since I'm at it, I'll just change this PR to a minor refactor to use finalAttrs pattern and remove with lib;

Btw thanks for the comments. If y'all think there's the need to address these right away, plz lmk and I'm happy to shepherd the changes

@stepbrobd stepbrobd marked this pull request as ready for review January 7, 2025 01:30
@jtojnar
Copy link
Member

jtojnar commented Jan 7, 2025

Only the action.c file is missing since it is generated from the Vala source. Something like the following should do it:

diff --git a/pkgs/by-name/li/libfm/package.nix b/pkgs/by-name/li/libfm/package.nix
index d762036a22d0..2663c9c67f53 100644
--- a/pkgs/by-name/li/libfm/package.nix
+++ b/pkgs/by-name/li/libfm/package.nix
@@ -2,6 +2,7 @@
   lib,
   stdenv,
   fetchurl,
+  fetchpatch,
   glib,
   intltool,
   menu-cache,
@@ -28,10 +29,11 @@ stdenv.mkDerivation rec {
   };
 
   patches = [
-    ./0001-fm-load-all-actions.patch
-    ./0002-exo-icon-view-key-press-event.patch
-    ./0003-ask-action-on-drop.patch
-    ./0004-create-icon-view.patch
+    # Add casts to fix -Werror=incompatible-pointer-types
+    (fetchpatch {
+      url = "https://github.com/lxde/libfm/commit/fbcd183335729fa3e8dd6a837c13a23ff3271000.patch";
+      hash = "sha256-RbX8jkP/5ao6NWEnv8Pgy4zwZaiDsslGlRRWdoV3enA=";
+    })
   ];
 
   nativeBuildInputs = [
@@ -52,6 +54,11 @@ stdenv.mkDerivation rec {
 
   installFlags = [ "sysconfdir=${placeholder "out"}/etc" ];
 
+  postPatch = ''
+    # Ensure the files are re-generated from Vala sources.
+    rm src/actions/*.c
+  '';
+
   # libfm-extra is pulled in by menu-cache and thus leads to a collision for libfm
   postInstall = optionalString (!extraOnly) ''
     rm $out/lib/libfm-extra.so $out/lib/libfm-extra.so.* $out/lib/libfm-extra.la $out/lib/pkgconfig/libfm-extra.pc

@github-actions github-actions bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 11-100 and removed 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Jan 8, 2025
- instead of vendoring patches, fetch from lxde

- use `finalAttrs` pattern and remove `with lib;`

Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants