| Message ID | 701288d1295a939ec9a8a1ba06d6cf3dd7b89bb3.1718850780.git.richard@freakingpenguin.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#71659] gnu: Add fastfetch. | expand |
Hi Richard, Thanks for the patch. I've also been working on a package for fastfetch after I got the guix package detection into the upstream package but got a bit sidetracked by other things. Here is what I have in addition: - Removing the src/3rdparty dir with an origin snippet. This requires an extra package for yyjson which is very straightforward. - A lot more configure-flags similiar to the (waiting in newqueue) debian package: "-DBUILD_TESTS=ON" "-DINSTALL_LICENSE=OFF" "-DENABLE_SYSTEM_YYJSON=YES" "-DENABLE_PROPRIETARY_GPU_DRIVER_API=OFF" (string-append "-DCUSTOM_PCI_IDS_PATH=" #$(this-package-input "hwdata") "/share/hwdatay/pci.ids") (string-append "-DCUSTOM_AMDGPU_IDS_PATH=" #$(this-package-input "libdrm") "/share/libdrm/amdgpu.ids") - Enable the built tests - For LM detection with logind "/var/run/systemd/sessions/" is used, however on (my) guix system that directory does not exist but is at "/run/systemd/sessions/" instead. Currently i have an extra substitute* to fix this in src/detection/lm/lm_linux.c but this might worth reporting to upstream. I havent got around to do this yet. - Python as native input (to minify help.json) - Enabling more of the optional dependencies - The optional dependencies are dlopened at runtime. In order for fastfetch to find these I had to wrap fastfetch/flashfetch with LD_LIBRARY_PATH of the inputs. What do you think? Have a nice day, Dariqq
Hi Dariqq, Dariqq <dariqq@posteo.net> writes: > - For LM detection with logind "/var/run/systemd/sessions/" is used, > however on (my) guix system that directory does not exist but is at > "/run/systemd/sessions/" instead. Currently i have an extra > substitute* to fix this in src/detection/lm/lm_linux.c but this > might worth reporting to upstream. I havent got around to do this > yet. As implemented would this hurt fastfetch's login manager detection on foreign distros? If so I think reporting to upstream would be ideal. > Thoughts? Sounds like yours is a lot more complete. I think it is best to merge your version. What else is left to do? Is there anything I can help with?
Hi Richard, On 20.06.24 17:59, Richard Sent wrote: > Hi Dariqq, > > Dariqq <dariqq@posteo.net> writes: > >> - For LM detection with logind "/var/run/systemd/sessions/" is used, >> however on (my) guix system that directory does not exist but is at >> "/run/systemd/sessions/" instead. Currently i have an extra >> substitute* to fix this in src/detection/lm/lm_linux.c but this >> might worth reporting to upstream. I havent got around to do this >> yet. > > As implemented would this hurt fastfetch's login manager detection on > foreign distros? If so I think reporting to upstream would be ideal. > On my fedora and debian systems /run is symlinked to /var/run. Not sure on other systems. Sounds like this should be moved upstream. >> Thoughts? > > Sounds like yours is a lot more complete. I think it is best to merge > your version. What else is left to do? > I would not really like hijacking the patch like this from you. But i'll happily share what I have so far: my yyjson package: I am not sure where to put this? just c.scm? or somewhere else? In the debian package they also build html docs. Tried that but they were not automatically installed with the standard phases and i am not sure if they are worth it. (maybe in a seperate output?) #+begin_src scheme (define-public yyjson (package (name "yyjson") (version "0.9.0") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/ibireme/yyjson") (commit version))) (file-name (git-file-name name version)) (sha256 (base32 "169rqh7mh01g5j4qkqjgfmgnyqjf9r8qxiywf4jkgcb7ln4j64w9")))) (arguments (list #:configure-flags #~(list "-DBUILD_SHARED_LIBS=ON" "-DYYJSON_BUILD_TESTS=ON"))) (build-system cmake-build-system) (home-page "https://github.com/ibireme/yyjson") (synopsis "A high performance JSON library written in ANSI C.") (description "A high performance JSON library written in ANSI C. Some features iclude @itemize @item Fast: can read or write gigabytes per second JSON data on modern CPUs. @item Portable: complies with ANSI C (C89) for cross-platform compatibility. @item Strict: complies with RFC 8259 JSON standard, ensuring strict number format and UTF-8 validation. @item Extendable: offers options to allow comments, trailing commas, NaN/Inf, and custom memory allocator. @item Accuracy: can accurately read and write int64, uint64, and double numbers. @item Flexible: supports unlimited JSON nesting levels, \u0000 characters, and non null-terminated strings. @item Manipulation: supports querying and modifying using JSON Pointer, JSON Patch and JSON Merge Patch. @item Developer-Friendly: easy integration with only one .h and one .c file. @end itemize") (license license:expat))) #+end_src my fastfetch package: For fastfetch i am following the nixos package to enable everything but mesa and directx. Also these are a lot of them and with the wrapper guix install fastfetch would need to also download all of the other libraries. It would be great to create more modular packages for something like this as enabling everything like this will e.g now always pull in xfconf (only needed when using xfce), the x11/wayland libraries even if one is on a headless server, etc. I guess that is a beneift for dlopen but does not really work well on guix system. Feel free to steal some things. #+begin_src scheme (define-public fastfetch (package (name "fastfetch") (version "2.16.0") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/fastfetch-cli/fastfetch") (commit version))) (file-name (git-file-name name version)) (sha256 (base32 "112dvfx7gvp6n20i1lkd0jbh897jf7bxjxq96bj4099j3x313y3m")) (modules '((guix build utils))) (snippet '(begin (delete-file-recursively "src/3rdparty"))))) (arguments (list #:configure-flags #~(list "-DBUILD_TESTS=ON" "-DINSTALL_LICENSE=OFF" "-DENABLE_SYSTEM_YYJSON=YES" "-DENABLE_PROPRIETARY_GPU_DRIVER_API=OFF" "-DENABLE_DIRECTX_HEADERS=false" "-DENABLE_OSMESA=false" (string-append "-DCUSTOM_PCI_IDS_PATH=" #$(this-package-input "hwdata") "/share/hwdatay/pci.ids") (string-append "-DCUSTOM_AMDGPU_IDS_PATH=" #$(this-package-input "libdrm") "/share/libdrm/amdgpu.ids")) #:phases #~(modify-phases %standard-phases (add-after 'unpack 'fix-logind-session-path (lambda* _ (substitute* "src/detection/lm/lm_linux.c" (("/var/run/systemd/sessions/") "/run/systemd/sessions/")))) (add-after 'install 'wrap-programs (lambda* _ (let ((ld-libs '#$(map (lambda (label) (file-append (this-package-input label) "/lib")) '("chafa" "dbus" "dconf" "ddcutil" "glib" "imagemagick" "libdrm" "libglvnd" "libx11" "libxcb" "libxrandr" "network-manager" "ocl-icd" "opencl-headers" "pulseaudio" "rpm" "sqlite" "vulkan-loader" "wayland" "xfconf" "zlib")))) (for-each (lambda (prog) (wrap-program (string-append #$output "/bin/" prog) `("LD_LIBRARY_PATH" prefix ,ld-libs))) '("fastfetch" "flashfetch")))))))) (native-inputs (list pkg-config python)) (inputs (list bash-minimal ;; for wrap-program chafa dbus dconf ddcutil glib hwdata imagemagick libdrm libglvnd libx11 libxcb libxrandr network-manager ocl-icd opencl-headers pulseaudio rpm sqlite vulkan-loader wayland xfconf yyjson zlib)) (build-system cmake-build-system) (home-page "https://github.com/fastfetch-cli/fastfetch") (synopsis "Fast neofetch-like system information tool") (description "Fast neofetch-like system information tool.") (license license:expat))) #+end_src > Is there anything I can help with? I have built with "-DBINARY_LINK_TYPE=dynamic" to dynamically link the dependencies instead. There was an error due to fastfetch wanting a newer version of ddcutil. Havent looked into how complicated that is to update yet. On a related note dynamically linking would avoid the (kind of awkward) wrapper. Are there benefits/downsides to using that instead? I hope the formating turned out ok for the code blocks
Hi Dariqq >> Sounds like yours is a lot more complete. I think it is best to merge >> your version. What else is left to do? >> > > I would not really like hijacking the patch like this from you. But i'll > happily share what I have so far: Gotcha. I'll try to spend some more time on this in the next couple weeks, but feel free to claim it for yourself! After all, to me it feels a lot more like I hijacked your patch than the other way around 🙂. No hard feelings. > my yyjson package: > > I am not sure where to put this? just c.scm? or somewhere else? > In the debian package they also build html docs. Tried that but they > were not automatically installed with the standard phases and i am not > sure if they are worth it. (maybe in a seperate output?) c.scm sounds like the right place to me. I'll keep the documentation thing in mind. > For fastfetch i am following the nixos package to enable everything but > mesa and directx. Also these are a lot of them and with the wrapper > guix install fastfetch would need to also download all of the other > libraries. It would be great to create more modular packages for > something like this as enabling everything like this will e.g now always > pull in xfconf (only needed when using xfce), the x11/wayland libraries > even if one is on a headless server, etc. I guess that is a beneift for > dlopen but does not really work well on guix system. I agree, I think this package would benefit from a -minimal version or some similar structure with variants. > network-manager I wonder if adding the network-manager plugin can cause issues on systems that don't use it. (e.g. connman). I'd be a little worried they'd start fighting. >> Is there anything I can help with? > > I have built with "-DBINARY_LINK_TYPE=dynamic" to dynamically link the > dependencies instead. There was an error due to fastfetch wanting a > newer version of ddcutil. Havent looked into how complicated that is to > update yet. > > On a related note dynamically linking would avoid the (kind of awkward) > wrapper. Are there benefits/downsides to using that instead? I'm no expert but dynamic linking sounds like a better solution to me than a wrapper + dlopen. Disabling runtime linking seems to be a semi-common thing in packages. Maybe we'll get lucky and ddcutil can be updated without any breakages. > I hope the formating turned out ok for the code blocks Looks great.
Hi Richard, I have just reported the LM detection issue upstream. So hopefully it will be fixed soon and we can ignore it in the guix package. On 20.06.24 20:34, Richard Sent wrote: > > I agree, I think this package would benefit from a -minimal version or > some similar structure with variants. > A minimal version sounds like a great idea and would be easy to customize by just adding the relevant packages. The question then becomes which features to include in a minimal build. Afaik apart from hwdata and libdrm (for specifying the custom paths) none are really required. The upstream wiki has some infos what is used for what. Apart from libdrm is there anything is there a feature you'd think that should be included in a -minimal version? >> network-manager > > I wonder if adding the network-manager plugin can cause issues on > systems that don't use it. (e.g. connman). I'd be a little worried > they'd start fighting. > Great catch. I havent even thought about this being an issue as i have only ever been using %desktop-services. It feels like there are a lot of things that have (explicit or implicit) assumptions on the system being used. - LM : logind - Music: dbus - Wifi: networkmanager - maybe more. >>> Is there anything I can help with? >> >> I have built with "-DBINARY_LINK_TYPE=dynamic" to dynamically link the >> dependencies instead. There was an error due to fastfetch wanting a >> newer version of ddcutil. Havent looked into how complicated that is to >> update yet. >> >> On a related note dynamically linking would avoid the (kind of awkward) >> wrapper. Are there benefits/downsides to using that instead? > > I'm no expert but dynamic linking sounds like a better solution to me > than a wrapper + dlopen. Disabling runtime linking seems to be a > semi-common thing in packages. Maybe we'll get lucky and ddcutil can be > updated without any breakages. > >> I hope the formating turned out ok for the code blocks > > Looks great. > Slightly related: What do you think of the current guix package detection? As it is not really comparable to package count in other distributions. My first implementation (in 2.14.0) is just counting lines in the output of "guix package -I" which only counts packages explicitly installed. As that was kind of slow I rewrote it (as of 2.15) to count unique /gnu/store/* entries in the profile manifest files (e.g. /run/current-system/profile/manifest) directly with C which also counts propagated inputs and ignores the lisy syntax of the file. The nix package detection parses the (nix equivalent) of "guix gc -R $(realpath PROFILE)" which gives counts similiar to other systems but was even slower and I haven't thought about a good way to filter out packages from the list (as there are also things like the computed info-dir , etc in there) The nix implementation sidesteps the slowness problem by caching results. I thought about using libguile directly but this is above my C and guile knowledge. Have a nice day, Dariqq
diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm index 212c2b3715..c7247b9e73 100644 --- a/gnu/packages/admin.scm +++ b/gnu/packages/admin.scm @@ -66,6 +66,7 @@ ;;; Copyright © 2023 Tomás OrtÃn Fernández <tomasortin@mailbox.org> ;;; Copyright © 2024 dan <i@dan.games> ;;; Copyright © 2024 gemmaro <gemmaro.dev@gmail.com> +;;; Copyright © 2024 Richard Sent <richard@freakingpenguin.com> ;;; ;;; This file is part of GNU Guix. ;;; @@ -4261,6 +4262,39 @@ (define-public pfetch information tool.") (license license:expat)))) +(define-public fastfetch + (package + (name "fastfetch") + (version "2.16.0") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/fastfetch-cli/fastfetch") + (commit version))) + (file-name (git-file-name name version)) + (sha256 + (base32 "112dvfx7gvp6n20i1lkd0jbh897jf7bxjxq96bj4099j3x313y3m")))) + (build-system cmake-build-system) + (inputs (list dbus + glib + imagemagick + libxcb + mesa + wayland + zlib)) ;for imagemagick and an #ifdef + (native-inputs (list pkg-config)) + (arguments + (list + #:tests? #f)) + (home-page "https://github.com/fastfetch-cli/fastfetch") + (synopsis "Display system information in a stylized manner") + (description + "Fastfetch is a tool for fetching system information and displaying it in +a stylized way. Fastfetch displays this information next to a logo of the +system distribution, akin to many similar tools.") + (license license:expat))) + (define-public nnn (package (name "nnn")