GNU bug report logs -
#71659
[PATCH] gnu: Add fastfetch.
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 325 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.