<ardon>Hi, has anyone gotten ocaml to work on Guix with the core library? I've just started reading Real World OCaml, but the ocaml toplevel doesn't find 'topfind' in Guix. This is my ocamlinit https://bpa.st/53RQ and the packages I've installed are ocaml-4.07, ocaml4.07-core, ocaml4.07-dune, ocaml-ocp-indent, ocaml4.07-findlib, ocaml-merlin and emacs-tuareg. This is a related issue on Nix https://github.com/NixOS/nixpkgs/issues/16085
<nckx>Because both exist. See ‘guix package -A ^node$’.
<nckx>When you ‘guix install node’ Guix will choose the highest version. ‘guix install node@10’ will install the lower.
<nouun>Hey, I'm trying to create a shepherd service which starts when you start x and I can see in 'sudo herd status' that there's one called 'xorg-server' but when I try add that as a requirement it says that xorg-server isn't provided by any service.
<apteryx>building a new version of the Guix package (bumped locally): error: Server does not allow request for unadvertised object 199da75a8adf37381c32ee1e3028b08b94703584
<allana>Hi guix! Guix system services and config files. Is it in practice more appreciated for people to supply external config files or to have config files generated from scheme when configuring services?
<civodul>allana: hi! the latter, but with an option to insert raw config contents
<florhizome[m]>Can shepherd virtual services provide some kind of a template or are they just a tag that groups services with a distinct functionality?
<efraim>civodul: I don't actually have anything to do with berlin
<efraim>all I can say is assuming both the sending machine and the receiving machine are the same architecture we shouldn't run into the problem rekardo was having previously with binaries for the wrong architecture
<AwesomeAdam54321>florhizome[m]: A virtual service is just a nickname that can be used by multiple services
<AwesomeAdam54321>florhizome[m]: Can shepherd virtual services provide some kind of template <- Can you elaborate?
<florhizome[m]><AwesomeAdam54321> "florhizome: Can shepherd virtual..." <- well, having virtual services makes a lot of sense since different processes can share some functionality but also it doesn’t seem to be able to account for much complexity in difference between services sharing a nickname. So I thought a virtual service maybe should have some more information about the functionality associated with its name, imagining it somewhat like a template,
<florhizome[m]>and the actual services would define how they fill those slots. I guess it would be kinda like a class–object relation but I‘m not sure since I don’t know much about oop
<nckx>sneek: later tell civodul: No objections from me! Happy hurding.
<euandreh>If I'm doing "guix pull" locally and running "guix deploy"s, do I also need to "guix pull" on the remote machine?
<nckx>Depends on why you ask. The deployment doesn't care about any remote guixes, of course, but nor will it mess with them. You can't say 'oh, I deploy changes to this machine weekly, therefore my remote user's guix can't be a year old'.
<unmatched-paren>is it safe for me to update my kernel yet? (I currently have it pinned to 5.15.16 because any later kernel either doesn't boot or hangs when i try to launch a desktop. I see in the logs that there's some iwlwifi-related bug in linux-libre causing it [i have a (currently unusable, for obvious reasons) iwlwifi card in this laptop])
<unmatched-paren>oh, yeah, another thing: there are some dmesg messages about the deblobbed wifi. they're annoying, because the hijack the login prompt. would they disappear if i `modprobe.blacklist=iwlwifi`?
<florhizome[m]><AwesomeAdam54321> "florhizome: It should be..." <- i guess you could use inheritance but I think in practice that would turn out very hacky on any more complex subject
<phodina[m]><maximed> "There's also a transformation..." <- Thanks, that's exactly what I'm looking for.
<lfam>It could be helpful to look for other programs that change their locations like this, to see if they handle it more gracefully
<apteryx>lfam: I'm on master, with 3 extra test-related only commits on top
<lfam>Guest40's experience is probably very common
<nckx>apteryx: scrub works only on multi-device (or, well, dup data but who does that) file systems. Plus, guix should just work. That's a pretty bad bug, would make an interesting system test (dm flaky...?).
<the_tubular>I'd agree, guix probably has the "highest" entry bar of every distro I've used
<lfam>What I mean is that instead of merely documenting workarounds for problems, fix the problems so the documentation is not necessary
<the_tubular>Also, there's nothing wrong with looking at documentation, I'm not the biggest fan of the cookbook and how it's layed out. But documentation should be avaialble and straight to the point when someone encouters a known problem imho
<lfam>The issue reported by Guest40 is definitely a bug
<the_tubular>It did, but through the web ui, i encountered problems
<lfam>Right. We had to disable the web UI submission form
<lfam>Not enough people to help maintain the web UI
<the_tubular>I already asked the question in the past, but never had an answer I liked. Maintaining guix is a huge undertaking and I feel like the developper are overwhelmed. We should find a way to draw more pair of eyes on guix
<apteryx>lfam: and yes, I'm on x86_64. Beware though. install tests are crazy expensive (they needs to build the whole Guix as a start)
<the_tubular>And also, another point. I feel like a lot of people are submitting patches for new packages, but I really don't see activities with people writing services to configure the said new package
<singpolyma>nckx: "not welcome" might be strong, but I did not get the impression that submitting reviews was something you should self-select to do since that's pretty unusual across other projects I participate in
<apteryx>maximed: did you have something more to add to #54235 (sysbench), or was it good to go?
<nckx> singpolyma: To be frank, that was my unquestioned impression of the status quo. I see enough fresh names and 'I'm not a committer but...' mails that I didn't think much of it.
<singpolyma>nckx: since I don't know who "the names" are very well it's not always clear to me a review is from a "fresh name". Though a couple times there has been a review by one person asking for changes and later someone else comes and comitts it before I got around to changing, so that's probably what happened.
<nckx>Saw one such today, in fact. I'll explicitly reply 'no, that's fine, great even, thanks' from now on.
<singpolyma>Not unusual for reviewers to have different opinions on things IME
<nckx>That's a pity, reviewers shouldn't ignore each other, at least address those differences.
<apt9>Hello all. A month or two ago, I heard that Guix was going to simplify package definitions soon, so I decided to wait for an update before doing a deep dive. Is an update imminent, or should I just go ahead and learn the current version?
<singpolyma>apt9: it's always evolving but no time to learn like the present
<nckx>The biggest change has been made apt9 . Not all packages use the new style but just ignore them, they're stupid.