Re: [RFC]: Skipping rust crate tests by default

2023-10-15 Thread Josselin Poiret
Hi Felix, Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > In summary, I believe that #:test? should be turned off for all build > systems. Guix should instead test installed versions like Debian's > autopkgtest. Let me just chime in and say that I agree: t

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

2023-10-15 Thread Kjartan Óli Águstsson
Tao Hansen writes: > Hello, I hope it's ok I'm replying to this email as a follow-up to > decreasing the cognitive overhead for new users. I'm also brand new to > the Guix community and ecosystem. I wanted to share a perspective from a > user on a Lemmy instance who wrote why the Guix ecosystem

Re: Fw: Question regarding qmk firmware

2023-10-15 Thread Fredrik Salomonsson
John Kehayias writes: > Hello, > > On Sun, Oct 08, 2023 at 10:34 AM, Ekaitz Zarraga wrote: > >> Hi >> >> I want to forward this message to guix-devel because it is a clear >> case of some (actually good) technical decision affecting users in >> unexpected ways. >> >> Now, after the change, a user

Re: Proposal: Differentiate products more clearly (Cycle 01)

2023-10-15 Thread Luis Felipe
Hi Wilko, El 13/10/23 a las 9:41, Wilko Meyer escribió: Hi Luis, Luis Felipe writes: This is a proposal to help differentiate Guix, the package manager, from Guix System. This sounds like a good plan. Background: As far as I understand, Guix was supposed to be GNU's package manager, and G

Re: Need people to help with kernel updates

2023-10-15 Thread Wilko Meyer
Hi Leo, Leo Famulari writes: > I pushed your patches as 06acda9715711c406f30b3a314387002244d8792 Thank you for this! > Overall, the fact that qa.guix.gnu.org is successfully building across > so many architectures means that we have a strong foundation for the > future of building kernel pack

Re: Golang mudules to follow common grouping

2023-10-15 Thread Wilko Meyer
Hi, Sharlatan Hellseher writes: > I think it's time to split (gnu packages golang) into some logical groups, see > Python, Lisp for example. > > Thoughts? IMHO this sounds like a good idea as it would improve the maintainability of golang packages in the long run. We have 487 package definiti