Re: February hybrid Guix London meetup
Hi all, Just a quick reminder for the February hybrid Guix London meetup later today. See you soon! > Hi all, > > The next Guix London meetup is scheduled for Monday 19th February, 6 pm > London time (i.e. UTC) onward. Join us in person or online. Address and > link are below. > > - In person, from 6:00 pm: 20 Farringdon Street, EC4A 4AB > - Online, from 6:10 pm: https://meet.jit.si/london-guix-meetup > > If you attend in person, please make sure you RSVP and share your full > name (or a nickname) so that we can register you at the building's > reception. > > The main part of the meetup will be a talk on how to create custom Guix > packages or package variants, by Steve George a.k.a. Futurile. If you > have any Guix or Guile related question or topic, there should be the > time to talk about that too. All welcome! Talk abstract follows. > > --8<---cut here---start->8--- > Guix Packaging: creating local package variants simply! > > Just like Gentoo or Arch Linux, every package in Guix is > source-available, and can be built by the user. In this entry level talk > we'll look at how to customise Guix packages. Guix radically simplifies > the steps to building our own packages through its declarative and > functional approach. This makes building our own package variants very > accessible—opening up the possibilities for a user to: > > - Keep applications up to the latest versions > - Try out upstream development versions > - Patch applications to add features > - Tune applications to their hardware > > In this talk, Steve will share examples and introduce how to use Guix's > programming interface for package building. We'll also contextualise > where these capabilities sit in the journey of learning to package and > contribute packages to Guix. > --8<---cut here---end--->8--- > > # About > > For any question, please get in touch via any of the following channels: > > - Arun: arunis...@systemreboot.net > - Fabio: m...@fabionatali.com and https://octodon.social/@fabionatali > - Guix Devel mailing list: https://lists.gnu.org/mailman/listinfo/guix-devel/ > > Guix London has no official ties with the Guix project. We commit to > promote the project and to always operate with the best intentions; any > mistake that we might make is due to us, Guix London, not the Guix > project. > > # Code of conduct > > We, Guix London's organisers, intend to create an open, friendly, and > safe environment where people from the most diverse backgrounds can get > together, learn about, teach, and discuss Guix and related topics in a > welcoming and constructive way. > > To this end, Guix London adheres to the Guix project's official Code of > Conduct. Please make sure you familiarise with the document and that you > share its principles before attending our events. > > Should you at any time before, during, or after one of our events want > to raise an issue or discuss any CoC-related topic, please do not > hesitate to reach out to the organisers at the contacts below. > > - Arun Isaac, arunis...@systemreboot.net > - Fabio Natali, m...@fabionatali.com > > # Get involved > > Should you be interested in becoming a Guix London organiser, please let > us know. It'd be great to have you onboard. No previous Guix knowledge > is required. If you're interested (or simply want to know more), do not > hesitate to reach out to us! > > Similarly, if you want to present on any Guix-related topic at one of > our events, that's also great. We'd love to hear from you. > > Regards, > Arun
NPM packaging questions
Hi! I'm currently delving in the subject of node packaging, I have a few ideas that I might be interested in sending patches for, but I need some input before. 1) IIRC, most build-systems (except cargo at least) will not fail if some native-inputs are not present. They will fail if they are indeed necessary to build the package, but not by construction. This is not the case currently in the node-build-system. This forces us to use the delete-dependencies function very extensively, but there are a lot of cases (linters in a broad sense) where this is not necessary. Should we do like in other build-systems and add a step that would use this delete-dependencies function for all packages that are simply not node packages in inputs / native-inputs / propagated-inputs? Or sould we rather keep this explicit declaration with a need to probably also include it and a list of linters to ignore when generating a package with a potential importer? 2) Node tests will fail if there are no "test" script present. Based on the code in node-acorn, we can define a utility function that can at least check and filter-out a script in package.json. Based on this, we could avoid the need to manually enter #:tests? #f when tests are not present. 3) Likewise, the "prepare" step in an input is run in the configure phase from packages that use this input. This is probably never correct, since the input's output is fixed in the store. Using the same utility as in (2), we could add a step that would a) warn the user that a prepare step is being removed and output the content of this step. b) filter-out this step. These, and in particular (1) should make it more easy to tackle writing node packages until we can come up with a correct importer that could handle recursive import. I don't think introducing the binary importer in guix is a good idea since typescript and gulp have been successfully imported in guixrus. -- Best regards, Nicolas Graves
Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)
Weighting in here, as small as my weight may be: - re-using 'service' is IMHO a bad idea, it is a loaded term and the expectation of a new reader is that a service is a SysV-init service: it can be started, status-ed, stopped, restarted, and that's it. It maps to a daemon running in the background. Basically a shepherd service. - The fact that systemd service maps in functionality to guix services should be a huge redflag that the name is not good. Systemd sucks for many reasons, and using confusing and incosistent language is one of them. - I agree that 'features' is a worse name, way too generic. - Descriptive linguistics would consider the broader and historical use of the term in the UNIX crowd from which guix users are drawn, instead of the in-group use, which, despite being admitedly well documented and rooted in the history of the project, is overloading a close-but-not-exactly-matching term. I can not emphasize enough how much those subtle unexpected problems make adopting guix very hard. I pushed through because I understand that the project is fundamentally sound and worthwhile, but for a few years I have made interns and colleague work with guix and saw their motivation die by a thousand cuts because of confusing stuff like this. Finding a better term would be a worthwhile endeavour, for ease of adoption. Maybe we should dedicate a session for it in the next guix days ? - At os-declaration time, ALL guix services can be added, extended, modified, and removed. Discovering this and the difficult-to-write syntax that goes along with notably the extension, led me to the syntactic sugar we were initially discussing. - At os-reconfiguration time, SOME guix services will do their thing - At os-boot time, SOME guix services will do their thing - At os-running time, SOME (the shepherd kind) guix services can be stopped, started, statused, doced, custom-actioned, and restared - Understanding these behaviours may help use find an naming ontology that would foster understanding and adoption. Note that I don't disagree that service is a good name in *isolation*, I just want to emphasize, as Attila did, that ignoring beginner's expecations (however obsolete they may seem to be) is detrimental to the project's adoption. Cheers, Edouard. Felix Lechner writes: > On Thu, Nov 30 2023, Attila Lendvai wrote: > >> the use of 'service' to describe two rather different abstractions: a >> component of an OS vs. a deamon process run by shepherd. > > Indeed, the use of 'service' in much of Guix appears to be a grand > misnomer. It probably occurred because the meaning expanded over time. > > It's like we are looking back in time at the Big Bang. Our "services" > are the microwave echoes of Guix's initial, creative spark! > > Please consider a recent, helpful reply to help-guix. [1] Carlo > mentioned the term "service" eleven times, but none of them referred to > what I believe most readers of this message would call a service in > other contexts. What's a newbie on help-guix to think? > > Should Guix services instead be called "features"? > > Those "features" are central to any operating system definition. Other > choices like "provider" may not fully capture our collective uses > throughout the code and the documentation. I am especially thinking > about 'modify-features' and '%base-features'. > > Kind regards > Felix > > [1] https://lists.gnu.org/archive/html/help-guix/2024-01/msg00213.html
Re: Feedback of the GNU Guix manual
Hi Matt, Matt writes: > The explanation of "a self-contained tarball providing binaries for Guix and > for all its dependencies" was reduced to the simpler "archived binaries." > Generally, "tarball" is imprecise, hence the need to explain what it contains > in this context. Further, it's jargon, may not be familiar to some readers, > and isn't relevant to the point of the introduction, that Guix may be > installed without needing to compile and why that might be desirable. > > Specific mention of installing Guix's dependencies was removed. Guix being > installed implies that its dependencies are also installed. I don't agree here: it's often the case in Linux-land that binary archives are provided without their dependencies included, assuming that the user already has them, often by installing them via their own package manager. Keeping the mention that it is self-contained and that the dependencies are also included might clarify the situation for some users. Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Core-updates coordination and plans
Hi again everyone, Thanks for the feedback! So in the meantime I chose to go ahead and try with 2.39 (how hard could it be?). The main visible change for us in 2.39 is the removal of the crypt library, with a replacement being the external libxcrypt. This wasn't too bad to fix in most places, you can find that work on core-updates-glibc-2.39. I am able to build up to Gnome, but trying to build the desktop.tmpl vm image, I stumbled upon a quite annoying issue: Guix recommends using Guile's (crypt ...) function, which is included only if libcrypt is available during the build. However, Guile appears very early in the dependency graph, and you can't just add libxcrypt to its dependencies without causing some cycle. Should commencement's guile-final be a minimal version of Guile without libcrypt, while guile-3.0 includes it? Do we want to be able to use (crypt ...) in g-exps? I don't really know what the answer to those questions should be, but it probably involves a world rebuild :(. Anyone have an idea/opinion about this conundrum? Other than that, I think that branch is in a pretty ok shape, I've also included a couple of patches that were requested. WDYT? -- Josselin Poiret signature.asc Description: PGP signature
Re: Feedback of the GNU Guix manual
Friendly bump. Awaiting feedback or guidance.
Re: [Cuirass] JavaScript work
Ricardo Wurmus writes: > I noticed that Cuirass bundles minified JavaScript. I’ve started a new > branch that replaces the minified JavaScript with readable source code > and minifies the files as part of the build. Yay for that. I'm wondering though what the net gain of minification is with current bandwiths. On the few sites that I use javascript on I just ship the preferred readable code. Janneke -- Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
