IRC channel logs
2025-01-16.log
back to list of logs
<potatoespotatoes>what is the correct way to have a catchall for a match statement in guile? <potatoespotatoes>the derivation I am working with uses `else`, but apparently this is throwing an error <potatoespotatoes>and I'm getting the error: error: (else (quote ())): bad use of 'else' syntactic keyword <potatoespotatoes>thank you! sorry about the obvious thing -- I'm just trying to squeeze in guix with very little time and I sometimes have trouble keeping track of where to look. <kimjetwav>I'm not familiar with what you're looking at but it doesn't /seem/ wrong? Like (match VAR … (else '())) should return the empty list as you'd expect. <potatoespotatoes>it's just weird because when I c/p this package definition I hit an error and there is no word "else" on the reference page for pattern matching. <potatoespotatoes>it seems correct (looking through more of this file), but I just don't know where it is coming from. <kimjetwav>No, though testing in a guile repl with match shows that it's accepted. <kimjetwav>It may be a reader synonym for _ or something. <kimjetwav>cond supports the same thing in scheme; in lieu of common lisp's expectation you'd use boolean t as your catch-all alternative. <kimjetwav>What is throwing the error, attempting to build this package, or attempting to modify the recipe? <kimjetwav>I ask since this is the thing that tests against building architectures. <potatoespotatoes>I run `guix package -v3 -K -L .guix/modules -f .guix/modules/reform.scm` <potatoespotatoes>qemu-minimal? ....yes. I changed it from a (package/inherit qemu) to a (package (inherit qemu)) <potatoespotatoes>reform.scm:653:18: error: (else (quote ())): bad use of 'else' syntactic keyword <kimjetwav>Hmm, seems to be building for me. Your error sounds like it comes right at the start, when guix is evaluating the package recipe, right? <kimjetwav>I swapped the name of the package and the public name and even put it in a file called reform.scm lol. <potatoespotatoes>...if this all seems good and works for you then it might be because I'm running this off of an arm machine @.@ I really hope this is not the case <kimjetwav>You need to actually import the used modules and not just the packages from (gnu packages virtualization), if they're not in your real file. <kimjetwav>When you import gnu packages virtualization, you're getting the package recipes from it, but you're not getting the procedures used by the recipe you define. <kimjetwav>Otherwise the modules of modules would propagate freely. <potatoespotatoes>got it. I thought I would get around that because this package uses functions to extract stuff from qemu. <kimjetwav>Yeah, the inheritance mechanism is explicit, so if you inherit from qemu but then call match in your own definition, you also need to have explicitly called for ice-9 match, even if the original qemu recipe uses match as well, because by using it in yours, you're effectively saying "no, get rid of that part of the original definition, use this part (which references something I haven't looked up the definition of here)". <kimjetwav>If that makes sense. Otherwise the inheritance mechanism would just push forward any old definition from any old previously resolved modules' namespaces. <kimjetwav>Sorry I'm doing like two things so I'm typing this explanation and then being like "this reads correctly, right?" lol <potatoespotatoes>it mostly makes sense. It sort of feels like there are some macros under the hood that are not hygienic <potatoespotatoes>well i am currently thinking that inheritance is pulling in symbols that may not be defined (like the ice-9 match) so these will appear undefined unless explicitly imported(?). Specifically I'm thinking of function calls like `(package-native-inputs qemu)` on line 79... no this is too weird <potatoespotatoes>wait, are you just talking about something like "shadowing components of the package" above? <kimjetwav>Inheritance is specifically not pulling symbols. Inheritance, for guix packages, brings along other packages' recipes and allows you to override parts of them at will, but at the moment you sub in your own code, that code has to have entirely resolvable symbols in the present lexical scope. Otherwise every package would just shunt along its whole environment and the entire guix package repo would take place in a single dynamic top <kimjetwav>The idea behind package inheritance is to let you have things like qemu and qemu-minimal, bash and bash-minimal, emacs and its fifty million modulations, without having to completely copy the definition every time. It's like defining a new branch on a previously defined tree structure. <kimjetwav>When you add that new branch, the thing you're putting there has to be resolvable to the inheritance system. <potatoespotatoes>I am just still a bit confused about how this inheritance system is any different from manipulating an immutable package derivation with regular lisp functions <kimjetwav>Because the original definition is not modified. <cwebber>my blogpost about the full time guix/emacs/org-mode cyborg <kimjetwav>Ever. In any way. By inheriting a definition you're creating a new package which is some other package modulo whatever. <kimjetwav>It's like the tree example, you can define a list whose elements are 1 and 2 and another list whose elements are those of the first list followed by 3, and they're separate structures addressable by their separate names. They can share structure up to the point of mutation and then they branch. <kimjetwav>For inheritance to be mutation, qemu-minimal would have to destroy the availability of qemu, for example. <potatoespotatoes>totally. this makes sense. I think I got confused before "you also need to have explicitly called for ice-9 match, even if the original qemu recipe uses match as well" <potatoespotatoes>so I thought that there was some kind of invalid variable reference thing that I had to resolve (which was a bad read of this statement) <kimjetwav>Yeah. You just gotta remember the multi-staged nature of this code. There's when the package is defined, which is when it looks up all of its symbols, when the derivation is computed, which is after that. Think of it as getting a box full of stuff, opening it up, and being like "replace that widget with <thing-for-which-I-have-no-word>". Even if <thing> is another widget, if you don't know the word for that right now when describing <kimjetwav>what you want in the box, you can't have the old widget replaced with the new widget. <kimjetwav>This is actually a terrible example because it implies that it's the same box rather than a variation of the box. <kimjetwav>The point is when describing what should be in the thing you need all the words on hand at the point of definition. <potatoespotatoes>ahhh, brain exploding a bit. I need to stew on this more tomorrow. I like boiling down this mental model to a tree example and thinking about the implications of this with multi-staging. <kimjetwav>Yeah. You should read the part of the manual on the store monad and gexpressions. One of the key differences between nix and guix is that in nix you have nix expressions which define packaging dependency logic, and get crunched down to derivations which are mostly shell scripts, while in guix gexpressions are a domain specific language using lisp macro compiler magic to churn out more lisp code in place of those shell scripts. <kimjetwav>Also may I suggest the Wizard book lol It basically does this nice pedagogical thing I'm butchering here where it starts with a very abstract notion of how evaluation words (the boiling it down to a tree structure example), then steps you through increasing levels of "well actually that's too simple, here's the more fundamental thing we're groping towards." <wizard>god actually i still need to finish my read of sicp too thanks for the reminder :) <kimjetwav>No one ever finishes sicp you just get to the point where you are building a compiler compiler and then you disappear in a puff of smoke. <kimjetwav>Boil em, mash em, compile em into a monadic derivation. <vhns>Is there any known bug of running `guix pull` if you have an offload server configured? <jakef>futurile: tremendous. did the last talk get uploaded to youtube? <futurile>jakef: not AFAIK, Christine wasn't happy with the audio I think (I wasn't there) and was going to rerecord it - good reminder, I'll chase them <vhns>I'm struggling with extending the openssh-service-type as to add more keys. Does anyone have a working example? By that I mean using (service-extension openssh-service-type) as per the manual. <vhns>(guix) Networking Services <civodul>futurile: hey! i’m ready to hit the push button for the blog post :-) <rekado>futurile: I just read the patch at 75578. What a gargantuan effort! <iyzsong>hey, anyone can create a ci job for the 'xorg-updates' branch? <futurile>rekado: thanks, yeah it's been a lot of work heh - hopefully it will be good data to make part of discussions at Guix Days! <civodul>futurile: it should be online within an hour <futurile>civodul: cool - I'll try and excite some interest on the mailing lists, social media when I see it :-)) <futurile>civodul: hopefully, will have finished converting the second one to sxml in the next day or so, so should be publishable early next week <ekaitz>futurile: looking forward to read it <civodul>futurile: that conversion work alone is heroic! <futurile>ekaitz: there's interesting feedback and quite a few surprises (I think) - the second post has info on architectures which will be of interest to you <vhns>are the posts out already? <futurile>vhns: the first post is building and will be on the Guix blog in an hour (or so); I'm working on post 2 and post 3 - trying to get them out in the next 7 days - so before Guix Days basically <Aure84>Hello I'm creating a guix environment that needs to unpack a .deb package (there are no other alternatives). Does anybody know if there is any native way to unpack/install these in guix? <lilyp>you could try an fhs container, but note that environments/shells are only temporal :) <civodul>ACTION had to kick the web site update job… <civodul>someday we’ll have webhooks that trigger publication <lilyp>stupid question: Is there a way to make a derivation (rather than a local-file or an interned-file) from a locally given file? <maxz>What's the canonical way to discard the output of a Shepherd service? (e. g. not having it go to the Shepherd log or to a log of its own) And would providing /dev/null as log-file work or cause problems with log-rotation? <lilyp>the default log file is #f, which leaves logging up to the service itself – as far as shepherd is concerned, that output might as well not exist <maxz>That does not match what I'm seeing. When it's left at #f the output appears in the log file of Shepard itself. <maxz>Now maybe you meant that Shephard does not consider the output as logs, since it does not fall under its management. But the stdout certainly still gets collected. <maxz>Wow, I managed to write Shepherd wrong twice in three sentences. <civodul>maxz: #:log-file #f indeed lets logging happen in the main shepherd log file (or via syslog, for PID 1) <civodul>#:log-file "/dev/null" should work well <civodul>(1.0.1 had a fix so log rotation would not try to rotate non-regular files :-)) <maxz>Ok, I will try it. Thanks. If log-rotation messes up my /dev/null device file I will come back to haunt you. <maxz>civodul: Ah, that is nice to hear. I'm running 1.0.1. <civodul>also, i have yet to push the log rotation patches to Guix! <yelninei>hi, trying to build the hurd manifest and the libgpg-error and doxygen hurd patches fail to apply <ennoausberlin>Hello. I just read the new blog post. Thank you for that. One point that was missing is the reliability of the infrastructure. Services like https://packages.guix.gnu.org/ or savannah or CI are often down if I want to demo Guix to my colleagues. First impression is not that good. I am aware of the reasons, but this really should be addressed more <yelninei>also a lot of libgc warnings coming from the guile build driver (i.e. same issue as #73181) <maxz>With Shepherd, if I have services A, B and C. B and C have requirement A. Is there an automatic way to have B and C restart if A restarts? <civodul>yelninei: oh, this might be a regression with the recent libgcrypt & co. update, my bad <civodul>ennoausberlin: yes, seconded; we have work to do in this area <civodul>maxz: i think that’s what happens no? if A is respawned, then B and C are restarted, no? <maxz>civodul: No, not according to my tests. But maybe it is related to B and C being one-shot services in my case? <yelninei>civodul: I checked the sources and the patch contents are already in the source (for both doxygen and libgcrypt-error). It looks like the patch was forgotten to be removed when the packages got updated <maxz>civodul: Ok, it really seems to be related to one-shot. <ennoausberlin>@civodul: How about prioritizing builds, that are a pain to build locally on ARM, e.g. tensorflow, rust, java jdk. These are also packages that break easily on ARM when the definition is updated while x64 is fine. It would really improve my experience when builds are tested on ARM before it is pushed <lilyp>Silly question: should we bleep the mentions to proprietary software? <maxz>Then my question would be if there is a way to also make this work for one-shot services. <lilyp>ennoausberlin: some of these, like rust, are deep in the tree so they would be built anyway, but for (pseudo-)leaves that requires building lots of other packages, this prioritization would likely have little impact overall <lilyp>maxz: you could write a one-shot service that on start starts A, B and C. <ennoausberlin>@lilyp: Yes but they often fail on architectures other than x86. It is hard to keep a common environment on both platforms, if things break that often. aarch64 is not a niche platform anymore. <civodul>yelninei: do you want to send a patch or should i remove them on your behalf? <ennoausberlin>And building the rust thing on aarch64 locally can take up to 24 hours depending on the machine <maxz>lilyp: I already have such a service. But that means I always have to trigger it manually. I'd prefer if Shepherd handled this if A ever went down. <lilyp>I get where you're coming from, it's just that we do lack the resources to be constantly rebuilding rust on CI as well (for example) <lilyp>But yeah, I think "fails on <arch>" should be a blocker for merges <ennoausberlin>@lilyp: I have a spare honeycomb aarch64 server, that I do not use due to lack of time. If someone stops by in Strasbourg on his way to Guix Days I can donate it. <cluelessguixer>Is there a monero-service-type? I'm sure there's a way to check if a certain service type exists, but I wouldn't know it. <yelninei>civodul: Still havent set up an email address with this nickname ... . I think they can be removed safely (please check again) <civodul>ennoausberlin: we would put it to good use <civodul>ennoausberlin: perhaps you can email that to guix-sysadmin (private list)? <hako>cluelessguixer: You can search service types with 'guix system search' and 'guix home search'. <yelninei>civodul: a) that the patches are already in the sources, b) that removing them does not change the linux derivations <civodul>yelninei: ah yes; giving it a try right now <civodul>yelninei: i confirm they can be removed (also cross-compiled to x86_64-pc-gnu) <civodul>we can change that when it’s its turn <janneke>we're going to get a rebuild anyway, as i applied the initial version of #73660 <janneke>so that needs to be reverted, or better, the v2 needs to be applied whenever graywolf creates an update <abbe>does anyone have any idea about: error parsing derivation `/gnu/store/301xbdvkdzj78jsbll3kkjwd61x5yrnz-module-import-compiled.drv': expected string `Derive([' <abbe>it's happened with me thrice on different hosts, one arm64 btrfs, one amd64 xfs, and one arm64 btrfs raid, all with regular updates to 'guix system' and ofcourse empty .drv file :( <abbe>any way to have them regenerated or something ? <civodul>abbe: that’s usually the sign of on-disk corruption <civodul>you can try “guix gc -D /gnu/store/301xbdvkdzj78jsbll3kkjwd61x5yrnz-module-import-compiled.drv” for this one, for example <abbe>apparently purging empty files in guix store using above didn't quite fix it, the latest generation is fairly broken <lilyp>abbe: roll-back, then garbage-collect the generation <abbe>lilyp: if I rebuild after roll-back, will that result in a fresh generation with non-corrupt contents ? <lilyp>it should, but bear in mind that yet another power outage can cause the same trouble once again :) <abbe>there was no power outage <abbe>and it's happened with three different hosts <abbe>and btrfs scrub also passed :/ <abbe>thanks for the suggestion though <lilyp>drv files are rarely empty for no reason… this smells like fs trouble <Rutherther>abbe: you need to gc the corrupted files after you roll back. Otherwise they will stay there and be used <abbe>right, but I don't know how to identify which files are corrupted, other than guix gc --verify, which didn't help. <abbe>I used nix for 3y, and it never happened there, so I'm not sure what I'm doing wrong here <abbe>although I use custom linux kernel (linux-xanmod) <futurile>abbe: you used Guix on three different physical machines, and all 3 have corruption in the store? <isf>whats mean "further by additionally supporting stateless, reproducible operating system" What you guys mean with "sopporting stateless" <isf>About this project in guix website <yarl>Is there a patch review session tonight? I see it's 2024. <isf>What mean "Guix takes that a step further by additionally supporting stateless, reproducible operating system configurations." I need understand what you want to say saying "stateless" <ieure>isf, It means you configure everything declaratively instead of editing files on disk, which is stateful. <ieure>Example, if you want to configure Xorg, you don't edit files in /etc, you put the configuration into your operating-system definition and it creates the files for you. <yarl>isf: And if you reboot, what your edited in /etc is not kept. right ieure? <ieure>yarl, It depends on what you edit, most of the work happens when activating a system configuration, which happens at the end of `guix system reconfigure'. <yarl>Every time you want to change the configuration persistently, you have to do in inside the operating system configuration then 'guix system reconfigure'. <yarl>ieure: Do you happen to know if there's a patch review session tonight? <the_tubular>WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete' <the_tubular>Is there anything I should do ? Or can i just ingore it ? <abbe>futurile: one VM, and two physical hosts, all three distinct physical hosts/platforms <abbe>and at one point in time <futurile>abbe: so odd - anything common in the applications? <abbe>nope, two hosts shared same configuration base, with slightly different setup <abbe>they were frequently system reconfigure-d a few times a day. <isf>"Run the build daemon of GNU@tie{}Guix, aka. @command{guix-daemon}." that build daemon is for compiling? is the same compiling than building? <futurile>isf: the 'guix build' command is for building - it talks to the daemon for you <futurile>isf: assuming you're asking about building a package <isf>building is not the same thing than compiling, right futurile ? <futurile>isf: I think I don't understand the context heh - can you give me some more context please? <isf>" Run the build daemon of GNU@tie{}Guix, aka. @command{guix-daemon}. " <isf>I dont have more context, sorry futurile <futurile>isf: where's the sentence from, can you give me the link? <isf>is from Guix the program <isf>Im translating the package into spanish <futurile>isf: ah OK, it's coming from base.scm - I think it's telling you how to run the actualy guix-daemon <isf>yes, whats your opinion is that "building" same than compiling or are different things? <ieure>isf, Building is a superset of compiling & includes things like linking. <PuercoPop>Where does search-patches look for patches? Can I use it in a channel? <PuercoPop>Seems like I would need to set %PATCH-PATCH for that <isf>for sure there are a mailing list for patches PuercoPop <PuercoPop>isf: No, I mean applying the patch to the derivation/package <PuercoPop>The source attribute of a patche accepts patches as an option. But I'm trying to first build it in my channel to test that it works before sending the patch <dariqq>PuercoPop: i think you dont need to adjust %patch-path, you can just use a path relative to the load path <vhns>Is there any standardized way to have home services from a user run on boot? In my case I'd like the ZNC bouncer to come as soon as the server does. <vhns>Since it's a home service and not a system service. <Rutherther>vhns: no, home shepherd starts when you login. You would have to run your user session somehow yourself, from system shepherd <freakingpenguin>One option might be gdm's auto-login? and default-user fields, although naturally it means anyone with access to the server can operate as that user. <Rutherther>freakingpenguin: you can start session in other ways, ie. even just a simple shepherd "bash --login" service as other #:user could work, I suppose <Rutherther>possibly with something blocking indefinitely like "sleep infinity" <Rutherther>so that would be "bash --login -c "sleep infinity"" <gs-101>Quick question: Does anyone know of a channel for getting Emacs from master (source) that features automated updates (as in, updating the commit based on source)? <reyman>see that python-pydevd-3.2.3 failed tests on latest guix commit <lfam>Yes reyman. It's due to be fixed on the python-team branch, which should be merged very soon. We could also cherry-pick this fix to master sooner <lfam>A lot of people noticed it so I'll look into cherry-picking <reyman>there is a dependencies of jupyter, so that could explain <lfam>I'll "just do it" if my blocker builds with the fix <freakingpenguin>I'm guessing it's due to that introducing a circular dependency. If that is the case is the only resolution to extract what I need from (gnu services guix) to a separate module w/o said circular dependency? <freakingpenguin>Specifically I'm trying to experiment with adding a user-account-home-environment field and extending guix-home-service-type. <civodul>freakingpenguin: yes, your diagnostic and suggestion look good to me <podiki>lfam: yes please on the cherry pick, looks like pydevd blocks cantarell which blocks a bunch of gnome <podiki>or more directly pydevd has ~450 dependents <freakingpenguin>If I'm moving a chunk of code to a new module with one associated copyright statement, does the statement go with it, remain in place, or go to both?