Re: [RFC]: Skipping rust crate tests by default
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: tests should not be a part of a build. This would: 1) avoid time bombs in tests breaking builds; 2) gain a lot of time when iterating package definitions; 3) let us control the testing environment more precisely, use containers, mock stuff more precisely, etc. However, this would require refactoring *all* guix package definitions, after first coming up with a satisfying testing strategy and system. I don't think this will ever happen unfortunately. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")
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 was not > friendly enough to meet them where they were, a person in their early > twenties. I'd like to suggest approach their criticism with compassion > and open-mindedness. As a person in my early twenties, who has contributed a few (small) patches to Guix and Emacs, I want to offer another datapoint/perspective on this issue. > @velox_vulnus writes at https://lemmy.ml/comment/4625080 > >> I don’t like the vibe of ageism against young people that is >> associated with GNU. I'll be honest, I don't understand this point. I've never felt any vibe of ageism from any interaction with the GNU project. Is this just about using mailing lists instead of some forge and other similar complaints of 'outdated' systems/processes? >> What is also frustrating is their reluctance to improve their >> infrastructure. Purely personal anecdote here, but I've never seen a reluctance to improve infrastructure. I've seen a reluctance to make changes which could negatively affect existing workflows, but I wouldn't characterise that as refusal to improve. >> They could choose to remove non-Libre JS from GitLab, Sourcehut or >> Gitea, or at least come with a new source hosting platform, but they >> choose not to. > > I also have a hard time with the insistence on the "Old Ways" as somehow > more pure, more legitimate than the new. There's some sense of the > expression, "You kids get off my lawn!" Having made contributions to projects using both methods. I massively prefer the mailing list + patch workflow of GNU to GitHub's Pull Request model. > And the decentralized nature of sending Git patches by email, which I > still have not ventured to try, makes it hard to *discover* Guix > development in a single place. A user needs to go to any one of the > mailing lists, pull the Git repo or browse Savannah or the issue > frontend for bugs and new features they might be interested in, and > generally have an idea of what they want to be looking for to find > it. Discovery by serendipity is missing. Where does 'Discovery by serendipity occur on GitHub or the other forges? Personally I've never experienced more such discoveries than by reading threads on the development mailing list of a project. > We have the FOSS technology to tackle a lot of these critiques and bring > in a whole new wave of contributors. We have fully open Git forges and > modern messaging protocols to make a brand new developer-friendly Guix a > reality. How friendly are these Git forges and messaging protocols to the continued use of existing email based workflows? -- Kjartan Oli Agustsson GPG Key fingerprint: 4801 0D71 49C0 1DD6 E5FD 6AC9 D757 2FE3 605E E6B0 signature.asc Description: PGP signature
Re: Fw: Question regarding qmk firmware
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 might run `guix search avr-toolchain` >> and find nothing. Same for ARM. >> > > In this case would it have helped to deprecate the package? Or can we > (ab)use this as a way to notify a user that either something has > changed (use a procedure now) or that a package you might expect at > this name is available some other way? > >> This is a shame, because we have toolchains for those architectures >> but converting them to a function that returns the package leave many >> users that are not used to read guix's code thinking those packages >> are gone. >> >> Maybe we should create some kind of fake packages that show up in >> `guix show` and `guix search` that have a short tutorial on how to use >> packages that come from a function like these. >> This way providing the same interface for every package regardless >> where they are coming from. >> > > At the very least this should be documented, perhaps adding to > information about the kernel in the manual and generally > customizing/building your own. > > I like the idea in general of making sure people can find things and > if they are not where you'd expect not having a hard time to find > them. Some tips in a package description about how to use or where to > look in the manual for information would be good, but I don't think > we'd want to get too verbose here, adding another maintenance point > that should be proper documentation (or cookbook). > > As an example, we don't need to always say how to add udev rules from > a package, but letting users know (if it is not obvious from the name) > that rules are included and should be added to a system configuration > for something to work (pointing to the manual about udev service) I > think can be helpful. I don't know though, I guess the package's > documentation itself needs to tell a user how to use it, and then one > looks in the Guix manual how to add udev rules. > > Anyway, perhaps I run on a tangent here. > > John > >> I leave it as food for thought. >> >> Thanks, >> >> Ekaitz >> >> Adding my two cents here as a user. It would be great to have some sort of documentation about this. Just a tiny snippet on how to use them will be sufficient. And a guix pull --news that notified you about the packages changed to procedures. It was not obvious to me when avr-toolchain disappeared how to proceed. I had to look in the commit log to figure out what happened to it (the issue tracker would probably also have worked). Even then it wasn't super obvious how I would use them as my mind was fixed on the `guix shell PACKAGE0 PACKAGE1 …` workflow. I never really use manifests as I have guix home to handle all my packages, and guix.scm for package development. -- s/Fred[re]+i[ck]+/Fredrik/g
Re: Proposal: Differentiate products more clearly (Cycle 01)
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 GNU was supposed to be the operating system: two products with two different websites. Unfortunatelly, that didn't happen and the Guix website became the home for two products: Guix, the package manager, and Guix System, a distribution of the GNU operating system. Since then, both products have been presented almost as a single one in the website. Probably as a result of this some people call both products by the same name (Guix), Splitting up the website in a "guix for package management" and "guix as a operating system" part sounds reasonable. I've reread the landing page and to me, one of the biggest issues it currently has is, that it vaguely describes attributes, but doesn't work well as a Guix primer for either Guix as a package manager or Guix System as an OS. and some other people don't understand what «Guix» is by skimming through the home page. This seems directly related to the landing page not being too great as a brief introduction for Guix. If I'd be a first time visitor of the landing page, I'd probably have questions along the realms of: - what is Guix? - why should I use it? what can it do for me/in my field? - do I want to use guix as a package management/or Guix System as a OS? On that note, I really appreciate and like how Guiles[0] landing page works in this regard. As it is written in a pretty clear language and answers pretty straight forward: - What Guile is. - What it has to offer/what potential common use cases are. - Usage examples on how to get started. reading it provides yet enough information to get a grasp of what Guile is and how to use it/how to get started and what to look up next. While writing this mail I also had a look at the mockups of potential solutions you provided; and they do address these points in a pretty good way, especially as it uses a clear and straight-forward language! Thanks for taking the time to review the proposal. I'm glad to hear you'd find the changes useful. Cheers, OpenPGP_0x0AB0D067012F08C3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Need people to help with kernel updates
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 packages in Guix. This sounds good; good to see how many builds were actually succesful on guixes QA! > Thanks you for taking the initiative to write the patches and manage QA > for this latest round of updates! > > I'm curious, now that we've done a round, do you have any thoughts about > the work so far? Thanks to the scripts you've provided and the initial explaination you've given it was fairly easy to pick up the work of bumping the minor kernel versions so far. I already followed new kernel releases closely before, so figuring out when actions are required (as in when new minor versions were available) wasn't too much of an issue. With 6.6 around the corner soonish, I wonder how making a new kernel config for that major release will go/what there'll be to learn in that regards. Until now the whole process seems to be quite easy to pick up, but does require constant recurring attention around each new minor release. There's been a 6.1.58 stable release a few hours ago[0], with changing mostly affecting the NFS subsystem (changes being almost exclusively reverts of commits). I created a patch[1] for this, if you'd have a minute to spare (or anyone else with appropriate rights to apply it on the kernel-updates branch; as I can't do it myself), we could see if it builds/merge it to master later on if it looks good. [0]: https://lore.kernel.org/lkml/2023101518-subscript-entity-be71@gregkh/ [1]: https://issues.guix.gnu.org/66568 -- Kind regards, Wilko Meyer w...@wmeyer.eu
Re: Golang mudules to follow common grouping
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 definitions right now: (~/devel/guix-devel/gnu/packages) λ rg -c 'define-public' golang.scm 487 which already seems quite laborous to split into logical groups (while getting the copyright information right as well and maintaining the gitlog history etc.); so it probably classifies as a task that should be tackled sooner than later as it'll cause more work over time the more golang packages exist. -- Kind regards, Wilko Meyer w...@wmeyer.eu
