Re: hint: Run `guix search ... | less' to view all the results
Robin Templeton writes: > Seconded! The current behavior seems exactly backwards compared to most > *nix tools; if I wanted *less* information from "guix search" I'd > manually pipe the output into head or recsel. Perhaps Git-style > auto-pagination (i.e. page the results when outputting to a terminal) > would be a good compromise as a default. I think this is exactly what 'guix search' does as of a few weeks ago? signature.asc Description: PGP signature
Re: Reducing Mesa closure size
Pierre Neidhardt writes: > So what the following strategy: > > - Extract the various mesa drivers to separate package, > e.g. mesa-radeon, mesa-radeonsi, mesa-nouveau, etc. I think outputs are better suited for this. > - Modify xorg-wrapper to accept an extra `drivers' > parameter. > > - Extend xorg-configuration to accept a list of mesa drivers. How will this work with Wayland? On a related note, some distributions have migrated to "libglvnd", the "vendor neutral OpenGL dispatch library". AIUI it installs a shim libE?GL.so that automatically loads the appropriate driver. Perhaps it can be useful to achieve this goal, and it might also make hardware acceleration work on foreign graphics drivers, which would be awesome. signature.asc Description: PGP signature
Re: hint: Run `guix search ... | less' to view all the results
Jan Synacek writes:
> Hello,
>
> I'm going to give honest feedback, since I still care about some things.
>
> I decided to check the new guix-1.1.0 and one of the first things that I ran
> was:
>
> $ guix package -s firefox
>
> The resulting message was infuriating to say the least. The code says:
>
> (if (and (not (getenv "INSIDE_EMACS"))
> ...
> ...
> (display-hint (format #f (G_ "Run @code{~a ... | less} \
> to view all the results.")
> command)))
>
> Seriously? Are you seriously forcing your users to either run emacs (or at
> least
> to set the env variable) or use pipes to get the entire search result?
> That's just... backwards. Also, it feels like as if the author of that code
> sort
> of assumed that whoever runs the command is stupid enough not to be able to
> deal
> with long output. I'm sure that it wasn't meant like that.
>
> Pretty please, fix this. Don't force your users into usage patterns that might
> be completely foreign to them. Don't truncate output from programs by default.
Seconded! The current behavior seems exactly backwards compared to most
*nix tools; if I wanted *less* information from "guix search" I'd
manually pipe the output into head or recsel. Perhaps Git-style
auto-pagination (i.e. page the results when outputting to a terminal)
would be a good compromise as a default.
Re: Reducing Mesa closure size
Thoughts about this? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Providing a Guix System images catalog.
Hello, >> I wonder about how this composes; if I'd want to add say a guix-daemon >> service to the bare-hurd, how would I do that? > > How about leaving the ‘operating-system’ field of to #f or some > default value, and then filling it in with the argument passed to ‘guix > system’? > > Or better: at the API level, we’d look for an “image constructor” (or > “image type”), not an image, where an image constructor is a procedure > that takes an and returns an . In practice, > you’d wrap that in with a ‘name’ field so you can still > look them up by name. Not sure to get what you mean after all. Could you maybe give a small example of what you had in mind with the image-type :) ? To give a short status on this one, * The "target" part was added as f292d4719dead6a615187f325fbc0bb0e99d10b4. * I proposed this serie https://issues.guix.gnu.org/41839, that creates a (gnu system image hurd) module for the purpose of CI. So we now have an record that contains all the required information to be built as a Guix System disk-image targeting a specific machine/architecture. I think it would make sense to be able to build images directly from the "guix system" command, but I'm not sure on how to make it composable with an operating-system file. Feedback welcome :) Thanks, Mathieu
