<nckx>pimi: Does ’guix environment <package>’ do what you need? If not, what's missing? <nckx>You can use ‘guix environment <package> -- true’ if you don't actually want to enter it, just download/build the prerequisites. <pimi>nope, I need to add in the description of package other places form where I need to download some files for testing phase <kirisime>pimi: If you're missing build-time dependencies of a package you're writing, you need to add them as dependencies. If they're not packaged, you'll get to write those packages too. <pimi>these files are just simple archieves with some bioinfo data <pimi>I do not think they are worth to be considered packages <nckx>pimi: You can use (origin …) records as inputs. <nckx>That's what it sounds like you want. <nckx>‘Anonymous’ store items from a package perspective. <pimi>I will try to find a description that already does this <nckx>pimi: Good luck. Random example: lynis in (gnu packages admin) does this. <kirisime>Here's something I'd like to see: A list of packages that use fancy packaging tricks so you can find a reference fast rather than going though all the package files with your favorite text search tools. <kirisime>Like, package-1 demonstrates how to use snippets, package-2 demonstrates modifying complex-build-system, package-3 uses wrap-program... <jlicht>I usually keep some notes around with links to often-referenced package expressions in my git checkout as well <jlicht>It would be nice to have some sort of "Packaging Issue" -> "Existing Solution" mapping available <nckx>kirisime: Sounds like a welcome addition to the cookbook or other learn-by-example documentation. <kirisime>nckx: I'd do it if I knew the tricks, too. <nckx>The problem is once you know or understand them they aren't ‘tricks’, just ‘the way it's done’. I never considered (inputs … (origin …)) a trick, it's just… there's a thing that takes holes, and a thing that makes pegs, so of course… <pkill9>well, the examples themselves, anyway <smithras>Also I think a lot of them aren't in the manual yet, so they definitely feel like 'tricks' to newcomers like me <nckx>Not being obtuse here: does nobody just read the source? Like, as learning material? That's how I learned Guix, I don't think I've read 1/20th of the manual. <nckx>It's full of code snippets 😛 <smithras>nckx: I should probably start writing down the things I learn when I read the source, I feel like there's a lot I'm already forgetting <nckx>pkill9: Is there anything like that available? <pkill9>nckx: a page/document of code snippets for common tasks? Not that I know of <nckx>smithras: Oh, same. I do keep notes. They're just useless to anyone but me. <kirisime>nckx: It's the way, but reading source is a lot more effort than reading documentation. And there's a large difference between system operators, users and developers; treating source as documentation only really works for the last one. <nckx>kirisime: I didn't mean to imply that it's the superior way. I don't consider myself a developer, either. <nckx>If I want to learn how to use LUKS and someone tells me to read the source I'll tell them to shunt right off, trust me. But if I want to add code to it and someone says… here's a handy copy & paste board of… ‘snippets’? Hermmm. <nckx>OK, loaded example, shoot me. *nckx dies, goes back to work for a while. <kirisime>I do get that. In a way the homogenous environment lisps and schemes provide moves everyone closer together so there's source everyone could benefit from reading. *nckx comes back to say: that example was bad and I feel bad. LUKS configuration files are not written in C, and Guix users need to write code sooner rather than later. I just deeply mistrust snippet-based programming. You may not have noticed, I was quite subtle about it. <kirisime>It means that usage and extension goes through the same interface; A user of LUKS would be interested in the user interface and a developer of LUKS would be interested in the program's internals, and for the user you do give out example snippets... <kirisime>If you don't someone else will. Go see how many websites are providing sed examples for instance. <nckx>I believe you. I didn't know because I never looked. <leoprikler>AFAIK the Guix manual does contain a fair amount of snippets, but there is only so far you will go with them until you develop an understanding for Scheme itself. <leoprikler>imo sed is more of a golfing language than a script language really <leoprikler>while it's limited to text manipulation and therefore probably can't do HQ9, the way that commands are written breathes this air of "I really don't want this to be just one character longer" <nckx>It's just so alien to how I (can) learn, and I see all the pitfalls & none of the benefits. If it helps users & doesn't mislead them or keep them ‘down’ (my main fear), great. <leoprikler>I do get where you're coming from. Endorsing certain snippets through the cookbook sounds very prone to creating a cargo cult. <kirisime>I get what you mean, it'd be great if your users knew how to use things rather than just copy-pasting code. <leoprikler>On the other hand, some of the more exotic features do lack documentation in a way that is easy to grasp, and also a context in which they may be applicable. <kirisime>Though, if you list packages that have odd qualities to them, maybe the fact that your users would be reading living code would help. <leoprikler>For instance, take the example of GTK+ applications/library, that defy the standard of autotools or meson. <nckx>It's very easy for me to say ‘we should have documentation that explains the concepts and empowers users instead’ while not writing any of it. <nckx>I get it, and I have no answer (I don't think I'd be a good doc writer if I had the time). <leoprikler>Some users may very well know how to add the glib-or-gtk-wrap phase, (or where to look for packages to do), but for others both the way to approach this problem and the snippet that actually solves it might be very confusing. <nckx>Or a traveller's guide to the Guix code base, taking curious users on a curated trip past some ‘interesting’ packages without throwing them in the deep end outright. <leoprikler>IMO the cookbook would do well to go deeper into various build systems and explaining their use/phases. While some can be inferred (again only through prior knowledge) or looked up in mailing lists, the state of information on them is not ideal. <leoprikler>A collection of commonly found code patterns and what they accomplish might also help. <nckx>I like that a lot better already. 🙂 *nckx is easily lured with nuance. <kirisime>leoprikler: Actual code in the guix source that a user can acces with `guix edit'? <leoprikler>Not quite, perhaps even somewhat of the opposite. <leoprikler>To help understanding: A snippet is a few lines of code, that does one thing and can usually be copied and pasted around without much thinking. <leoprikler>A pattern on the other hand is (in the words of my teacher) "a proven solution to a recurring problem". <leoprikler>For instance, the use of a pre-build phase to set up environment variables is a pretty common pattern inside the Guix source. <leoprikler>So is the post-install use of wrap-program, that is in some instances even abstracted away through the build system. <nckx>ZombieChicken: Slightly below average, heading into quiet time (European night). It's more active during the Euroday. <pkill9>what's the minimum kernel version required to support guix? <smithras>pkill9: Unsure, maybe the manual has some information in the section about installing guix on a foreign distro? <nckx>pkill9: It depends on your distribution, e.g. Red Hat has some ‘2.6’ kernels that are so heavily patched that they can run Guix. <pkill9>latest, but i was thinking about trying to install guix on my phone, which would require old kernel <pkill9>also apparently because it uses old kernel, postmarketos won't have hardware acceleration :< <guix_user_9000>Hi! I'm new to Guix and I'm trying to build a disk image with a small patch to fix something on my server. What is the easiest way to do this? <guix_user_9000>I don't have any git server setup, and I only need to change a few lines of code. <nckx>guix_user_9000: You can ‘git clone https://git.sv.gnu.org/git/guix.git’, apply the patch with ‘git am’ or your method of choice, then follow the ‘Building from Git’ instructions in the latest Guix manual. Then, without installing the guix you built, you can build the installer with ‘./pre-inst-env guix system disk-image gnu/system/install.scm’. <nckx>guix_user_9000: If you get stuck and #guix is quiet as it tends to be at this hour, try the help-guix at gnu.org mailing list. <str1ngs>wednesday: mount your efi partion to /mnt/boot/efi <str1ngs>wednesday: actually you might have not booted in efi mode <wednesday>str1ngs:I got my boot partition mounted on /boot, and I'm pretty sure the usb is booted in efi mode <wednesday>this was an old install from just before 1.0 I belive <wednesday>str1ngs: I've checked like 4 more times and I'm pretty dammn sure I am booting the usb in efi, and that I got a fa32 part llabled esp mounted on /mnt/boot, any idea what to check or do now? <notzed> /sys/firmware/efi should exist? (according to a search) <PurpleSym>sneek: later tell civodul: Yes, the former, i.e. override an existing package by name. I guess I’ll have to fork guix’ repository, alter the packages there and provide it to the user. <wednesday>notzed: well from what it looks like in my bios it should be booting in uefi mode, I'll check for like the 15th time though ha <wednesday>notzed: getting somewhere, my boot order had the uefi usb first but it seems like it was still booting in legacy, told me bios it can only boot efi and now that folder is there, so hopefully it'll work this time <notzed>wednesday: went through it all last week, although i ended up with slackware in the end but i'm trying guix for packages on it <wednesday>I've had this same guix install for maybe a year now, not sure, but a while before 1.0 at least <wednesday>I used to contirbute a bit but life has gotten in the way since then, fixed sddm and added some packages back in the good ol dats <notzed>life has a way of getting in the way of things. i broke my hip so i've suddenly got a lot of free time <wednesday>thar we go, got the pc booting, thanks for the help notzed heh <wednesday>all this effort just to start from scratch on saturday when my nvme shows up ha <leoprikler>PurpleSym: I don't think what you're trying to do is indeed possible. <leoprikler>You can (if you're very evil) bump the version of your thing, but the replacement/graft mechanism relies on the original package being aware of the graft (which it is not if you're using a channel). <sneek>civodul, you have 1 message. <sneek>civodul, PurpleSym says: Yes, the former, i.e. override an existing package by name. I guess I’ll have to fork guix’ repository, alter the packages there and provide it to the user. <PurpleSym>leoprikler: Yeah, I thought about bumping the version, but it could break with every update to the guix channel. <leoprikler>You'd have to do something like (version (string-append (package-version original) "-lol-imma-breaking-your-builds")) <leoprikler>there is no clean solution since what you're trying is dirty to begin with <PurpleSym>I’ll try to upstream everything I can and the rest I’ll have to maintain myself. <civodul>i think it shows a need for customization, though perhaps we'd recommend a different angle <civodul>such as package-input-rewriting, like we discussed yesterday <civodul>IOW, package names are really secondary in Guix, so one should probably not tackle customization needs at this level <PurpleSym>Yeah, this is kind of confusing at first. Especially since `guix install` relies on the package name and will simply pick one if there’s a name conflict. <PurpleSym>I get that you can work around that with input rewriting and manifests, but fear our users will not. <civodul>right, either manifests that use 'package-input-rewriting', or --with-input on the command line (it's equivalent) <civodul>there are limitations as to what one can express on the command line though, and that's where having a manifest can help <PurpleSym>Alright, thanks so far. I’ll look into that again. <civodul>incredible that you're back at the keyboard at such an early time, roptat ;-) <roptat>actually, I went to bed earlier than usual because it was exhausting <civodul>so it went well, no weird questions from the jury? <roptat>some of them I couldn't answer properly, but it went very well overall <civodul>"based on your experience, how do you envision computing 30 years from now, Sir?" <roptat>is "in 30 years we'll be busy with other things than computing due to climate change" a good answer to that question? <roptat>well, that's not really how I see it, but I guess it will have an impact that makes it difficult to predict what will happen in 30 years <roptat>so now I have some free time to work on Guix. I'd like to help on the documentation/usability front. Is there any issue that comes to mind? <roptat>how could I find this kind of issue on the bug tracker? is there a tag system? <roptat>maybe reducing the size of some closures <zig>roptat: congrats! I am jealous, I wish I could do a phd. <civodul>roptat: re climate change, i guess you're right... <civodul>roptat: reducing the size of some closures would be real nice! <civodul>e.g., i was discussing the possibility of having the Tor Browser folks use "guix pack" <civodul>problem is: they currently ship an 80MiB tarball (which does not include glibc, gtk+) <civodul>whereas our icecat closure is 1+GiB... <roptat>mh... I'll see if I can do anything <civodul>as for documentation, i don't know if there are open issues, and no, there's no "doc" tag in debbugs <civodul>one thing that'd be nice is to augment the cookbook <roptat>I tried to split llvm into multiple outputs, but their cmake file is not designed for that <civodul>(i saw you wrote a message about the cookbook but i haven't taken the time to read/reply) <civodul>roptat: mesa is terrible, for example <roptat>well, it's more on what we want the cookbook to be <roptat>I was suggesting to make it a document for helping users grow from newcomers to advanced users or even contributors <roptat>but there was some opposition, because I was suggesting to have a more rigid organization, which would probably exclude some kind of entries in the cookbook <g_bor[m]>civodul: in the menawile we could request doc related issues to have a title like [DOC] ... manually tagging these in the subject line. That would at least help searching for them. <g_bor[m]>roptat: for that there is a good old method, having an others chapter, you just have to make sure, that not everything ends up being other :) <roptat>so maybe the solution is to have a new document, I was thinking about "la documentation dont vous êtes le héro" (sorry, I'm not sure what that kind of book is named in English) with tutorials and articles that would suggest different tracks to follow, depending on what you want to learn (a developer track, a scientist track, a packager track, ...) <g_bor[m]>civodul: I was thinking about the --ad-hoc as default for guix environment. You told that a good deprecation mechanism would be needed. <roptat>that's probably not how I put it in the mail I sent though ^^ <roptat>so I'd like to have more than just a collection of unordered articles <g_bor[m]>What about having an environment variable, something like GUIX_ENVIRONMENT_DEPRECATED_AD_HOC <g_bor[m]>It will not make transition completetly smooth, so script user become aware of the problem, but can solve it quite easily. <g_bor[m]>It could come with an announcement that support will be removed two releases later, or so. That would allow time to adjust to the situation. Maybe we could also include a command line flag, like : --ignore-deprecated-ad-hoc, and simply make it a noop when the other code is removed. <g_bor[m]>This woul allow to fix the scripts one by one. <civodul>g_bor[m]: i think we should discuss it on the list, but yeah, this is probably the kind of thing we could do <valignatev>Hey Guix! How's it going! Does anybody have a recipe to build Emacs from current master. I have a definition which successfully builds, here it is: https://pastebin.com/fCZ5Fm28 . Unfortunately, when I try to execute "emacs" I get "emacs: could not load dump file "/gnu/store/y8p3p7izcp3mk7q9ij4nfras250yz3pg-emacs-git-27-0.d57bb0c/libexec/emacs/27.0 <valignatev>.50/x86_64-pc-linux-gnu/emacs.pdmp": not a dump file" <valignatev>And indeed this "emacs.pdmp" is some bash file that has exec -a "$0" "/gnu/store/y8p3p7izcp3mk7q9ij4nfras250yz3pg-emacs-git-27-0.d57bb0c/libexec/emacs/27.0.50/x86_64-pc-linux-gnu/.emacs.pdmp-real" "$@" in the very last line <leoprikler>Let's say I wanted all of the dependencies of guix as is currently the default behaviour? <valignatev>When I try to execute this .emacs.pdmp-real, it fails with "permission denied". <leoprikler>Adding your package definition to emacs.scm I get warnings about unbound variables <roptat> civodul how do they manage to have only 80 MiB when our icecat alone is already 168.7 MiB big? <valignatev>leoprikler: what unbound variables? This one that I posted is building <valignatev>You can also freely delete snippet, modules and patches from the definition, it should build as well <leoprikler>gnu/packages/emacs.scm:274:8: warning: possibly unbound variable `jansson' <leoprikler>gnu/packages/emacs.scm:277:8: warning: possibly unbound variable `perl' <leoprikler>gnu/packages/emacs.scm:277:8: warning: possibly unbound variable `python-3' <leoprikler>gnu/packages/emacs.scm:277:8: warning: possibly unbound variable `rc' <g_bor[m]>civodul: ok, I will send a mail with the summary of this. <valignatev>jannson is from gnu packages web and rc is from gnu packages shells <nixo__>Hi guix! I almost completed the julia 1.3.0 package update (there are few failing tests and building it takes like 3 hours on my laptop)! However, my julia-xyz patch has not been merged yet, anybody had time to look at it? I don't know which one should be rebased onto the other <civodul>roptat: well the compressed tarball is ~80 MiB <roptat>I could reduce the closure of llvm by 80 MiB by adding an output for the opt-viewer scripts <roptat>it would remove python2 and some dependencies from the closure (it would remove 65 MiB from mesa I think) <roptat>since we received a message about staging, I'll see if I can send such a patch there in time (and if it's the right branch) <roptat>1826 dependents... that's core-updates, right? <nckx>roptat: Congratulations! <civodul>roptat: also, that llvm itself takes 118 MiB looks fishy to me <civodul>hopefully we can strip some of that, or at least not build all the targets <civodul>$ ls -1 /gnu/store/nsrym6zn3yb4390fazx1gq8rg0m8dhkd-llvm-8.0.0/lib/*CodeGen.so |wc -l <leoprikler>valignatev: this appears to be a collision between emacs 27's behaviour and glib-or-gtk-build-system <leoprikler>I'm trying "--with-dumping=none" as configure flag <g_bor[m]>roptat I believe 1826 dependents might be ok for staging <roptat>g_bor[m], the manual says 1200 is the limit <roptat>civodul, I don't know llvm enough to understand why <pkill9>i see no reason why guix system can't be installed on pinephone, as it's designed to be able to run traditional linux distros <leoprikler>It's funny how Pinephone uses the Nix logo as advertisement and then doesn't tell you how to install Nix on it. Next level genius. <pkill9>they're firmware blobs, so forgot about those <pkill9>where is info on the nonfree blobs in the pinephone? i wonder if there will be/are efforts to liberate them <nixo__>pkill9: I think the gpu is one of them <kmicu>Without a leak I doubt they liberate those. <nckx>‘there are no new wifi chips that work w/o a proprietary firmware’ — is that true? That is sad. <valignatev>Emacs builds so long without dumping :( leoprikler sorry for electricity bills lol <kmicu>(Here Emacs builds in ~3min) <kmicu>nckx: it’s sad and even worse is that proprietary firmware from Broadcom blesses are with RCEs from time to time. <kmicu>Iirc we only got libre firmware for Atheros9 thanks to leaks. The only rev. engineered chip was old Broadcom circa 2012. <kmicu>So better grab your favorite AR9271 while it’s still available. <kmicu>(Added benefit: that chips gives us a way to ‘pentest’ wifi networks.) <nckx>I buy them when I find 'em, but USB-A and µPCI won't be around forever. <valignatev>kmicu: It's three min for me as well if you go for the default pdumper settings. Without it, it takes some time <valignatev>leoprikler: Btw it works wih dumping disabled. Unfortunately, without dumping it's not that usable :( <kmicu>Just by a USB-C to USB-A dongle for your Wifi USB-A dongle and attach it to your phone or laptop xD <valignatev>I'll try to figure out what's the problem with gtk build system, thanks for the clues! <kmicu>It’s also possible to buy second‑hand TP‑Link dongles but only old revision have libre chip. <leoprikler>gtk-build-system wraps all programs in bin and libexec <leoprikler>the pdmp should be placed elsewhere in my opinion <zimoun>hi! I cannot 'guix pull' because of python-pandas, apparently. Does anyone experiemt the same issue? <nckx>kmicu: I love old hardware, but I hate being forced to treat my shoebox-o-crusty-chips as some valuable hedge against a horrible future. <nckx>‘Son… this was your mother's dongle, and her father's before her. Guard it well, and hide it when the seeers come. Godspeed… Well, not really, it's quite shit by today's standards actually.’ <jlicht>kmicu: you jest, but that is actually how I ran around for a while :P <valignatev>leoprikler: Yeah, it works. Emacs runs successfully albeit it loads a bunch of stuff on startup because it's not dumped. And fonts are borked, e.g. they are wihtout any antialiasing. But it runs <jlicht>nckx: this could be a good writing prompt for a spin-off/sequal to "The Right to Read" <valignatev>I wonder how Emacs 26.3 from guix works well with gtk-build-system and with dumping <leoprikler>Emacs uses unexec for dumping before 27, meaning it probably finds the dump elsewhere *jlicht wonders why ispell took an early holiday break <leoprikler>However, as of 27, unexec is deprecated, so I wouldn't try to --with-dumping=unexec <leoprikler>Let's see what else I can come up with, but first it's time for me to eat. <kmicu>nckx: the next decade looks ok thx to FPGA, RISC-V, OpenRAM, and so on. Only this decade with last libre laptops from ~2012 is so grim. <nckx>jlicht: Without your fancy software augmentation you are nought. <nckx>kmicu: I sometimes share your optimism 🙂 <jlicht>valignatev: at the risk of being horribly wrong, I've actually heard the opposite (that well managed and responsibly managed fasting can help with brain work) <jlicht>but I Am Not A Food Science person, so definitely take my vaguely informed gossip with a grain of salt <jlicht>I have a working bitlbee build that uses libpurple (e.g. pidgin) for supporting different protocols. I even have a functioning way of loading plugins for libpurple, but had to do some unspeakable things to the bitlbee service definition to make it all work. <jlicht>Would it be preferable to add a `libpurple-plugins' field to the existing service, which would be ignored by default bitlbee, or rather make a totally separate service for bitlbee-plus-libpurple? <nckx>Coul ‘totally separate’ be replaced with ‘extended’? I'd like that. <jlicht>How would/could that work, shepherd-wise? *jlicht always gets rising stress levels about the meaning of the word extended in guix services <nckx>I was once like you, now I'm only slightly less so after cmarusich patiently explained the main points of service composition to me at FOSDEM. <nckx>I'd have to look at the code to answer you though, and I don't have guix here. <civodul>i feel stressed when i read people are stressed by service coposition! :-) <valignatev>jlicht: Well, the truth is somewhere in the middle I think. My brain goes dead when I both hungry and overeat ¯\_(ツ)_/¯ <roptat>nckx: I pulled successfully about 2 hours ago <jlicht>sorry, civodul :-). It's rather that the term "extend" can only mean so many things at once in my brain before I have to hit swap-space <leoprikler>what procedure would I use to get a libexec subdir like "x86_64-pc-linux-gnu"? is this a gcc-triplet or something like that? <nckx>roptat: ? I don't quite follow. <civodul>jlicht: yup :-) and more seriously, i'm sure the lesson here is that there's room for improvement in the doc or in the implementation (or both!) <civodul>leoprikler: this is a "GNU triplet" and there's no procedure that can give it to you <leoprikler>hmm, I see %current-target-system and (nix-system->gnu-triplet (%current-system)) <civodul>that said, it's not clear whether you really want to do that <leoprikler>Indeed, I really don't, but I want to fix valignatev's Emacs build without disabling the portable dumper <valignatev>Welp, eventually somebody have to package emacs 27, so we need a hero! <civodul>leoprikler: ah well, on the build side, phases receive a #:target argument that's the triplet <bgardner>Good morning Guix! Two questions this morning - first, is there any way to ask 'guix pull' to use ssh rather than https since I have a savannah account? And after I struggled through a successful pull/reconfigure/reboot last week emacs 'forgot' how to use one of the installed packages (emacs-ledger-mode), and while emacs is installed systemwide, emacs-ledger-mode is per-user. Any advice for how I should <alextee[m]>isn't the virt-viewer package supposed to provide a virt-viewer binary? <alextee[m]>virt-install says: Unable to connect to graphical console: virt-viewer not installed. Please install the 'virt-viewer' package. <alextee[m]>but all i see in virt-viewer's /bin is remote-viewer <leoprikler>bgardner: probably by editing your channels.scm, but I don't know whether that has SSH support <bgardner>leoprikler: Thank you, I'll research that. Worth a shot anyway. <zimoun>roptat: thank you. Thank you. It should be one change that impacts my channel. <bgardner>leoprikler: Thanks very much, that sorted me out - I'll change my default so emacs is always per-user from here on. <zimoun>Where do I submit patches to the repo maintenance? On guix-patches? Elsewhere? <civodul>bgardner: right now Guile-Git (which "guix pull" uses) does not support SSH, but this is about to change <civodul>in the meantime, you could make the checkout by yourself with Git, and then do: guix pull --url=file://... <bgardner>civodul: Gotcha, thank you for the tip - I'll investigate <nckx>Wireguard will be in Linux-Libre 5.6. Neato. <valignatev>leoprikler: Thanks, I'm trying it now! Do I understand correctly that your addition unwraps real pdump after gtk builder wraps it? <pkill9>what does it mean for it to be in the kernel as opposed to userspace? <rekado>for the past few days I’ve been thinking about user interfaces and desktop environments. I don’t really want to (ab)use Emacs for everything. I wonder if it’s time again for some efforts towards a lisp machine like UI, backed by Guile. <leoprikler>Exactly, it basically reverts glib-or-gtk-wrap for this one file. <jlicht>guile-wm is imho very very bare-bones <jlicht>(or at least when I tried it some 2 years ago) <leoprikler>that is sadly the state of most "program your own window manager" things <leoprikler>I'd be personally interested in something that has the Look & Feel of GNOME, but running Guile instead of Javascript underneath. <bandali>if you're an emacs user, exwm is pretty great <snape>and if you don't mind your whole windows manager freezing every time you run a blocking command within Emacs ;-) <jonsger>raghav-gururajan: and what did you get from that? <raghav-gururajan>jongser guile based wm that can be hacked and extended like guix and emacs? <bandali>snape, hehe :D yeah you gotta try and minimize those <leoprikler>i3 appears to use its own ad-hoc command language <bandali>it's been pretty okay in my experience in that regard tbh <jonsger>raghav-gururajan: and wouldn't be bindings enough? <raghav-gururajan>Folks! how to pass more than one package name to the option --do-not-upgrade= for guix package --upgrade? <snape>bandali: I've used EXWM a lot and I find it way too unstable <leoprikler>either through multiple options or through regex <snape>I will surely be much better when Emacs has full multithreading support ;-) <bandali>snape, ha. i haven't used it *extensively*, but i've used for a at least a good few months <bandali>can you elaborate on what things you found unstable about it? *raghav-gururajan finds multiple options less complicated :D <leoprikler>sure, but regex allows for e.g. --do-not-upgrade-emacs.* <valignatev>We can't just disable wrapping stage altogether because it wraps something else important, not only pdump, right? <leoprikler>sadly, there is currently no way to exclude files based on regex <leoprikler>you'd have to work tha into glib-or-gtk-build-system <nckx>raghav-gururajan: If regexen intimidate you you can use ‘--do-not-upgrade={a,b,c}’ if ‘--do-not-upgrade a b c’ doesn't do what you expect. <nckx>Try ‘echo --do-not-upgrade={a,b,c}’ to see what bash turns that into before Guix even sees it. <valignatev>It really works very well, I'm sure I wouldn't be able to pull it of with my current guix knowledge, thanks a lot leoprikler! Now I have to figure out how to make font antialiasing and hinting work, but that's another story <snape>bandali: I don't remember well but really, the freezing issue was critical. Lots of Emacs commands are blocking. E.g. gnus commands. or Tramp ssh, etc. Plus, I find that I often need to restart Emacs (to test a conf change...) - I don't want that to imply that all my applications will be restarted. And, most importantely, if you want to run Emacs within a specific environment (cd src/guix && ./pre-inst-env emacs), it's not possible <snape>with EXWM unless you run Emacs within EXWM, which is... impossible (almost, because of the bindings conflict) <snape>By the way, I haven't seen that anywhere in the docs, but running (cd ~/src/guix && ./pre-inst-env emacs) is ultra-useful <snape>because every thing works out of the box <leoprikler>valignatev: Are you running a fancy WM like GNOME et al. or something minimal like ratpoison? <snape>(within guix environment guix too) <valignatev>I really can't imagine using emacs as a window manager considering that its rendering capabilities are older than the last living dinosaur. It can't even handle smooth scrolling let alone doing serious graphics stuff. Even if EXWM works with xlib directly, I can imagine Emacs being a big bottleneck <bandali>snape, ha. yeah, i luckily don't use much blocking stuff in my day to day use of emacs. so perhaps that's one of the reasons using exwm has been pretty smooth for me <bandali>you do have a point wrt restarting though <valignatev>If you're asking with fonts antialiasing in mind then I have Emacs from Arch repo, and fonts there are beautiful <valignatev>Maybe Emacs form guix can't see my .Xresources, or I should do something with fontconfig so guix is aware of it, I dunno yet <bandali>e.g. for gnus, i use a local dovecot server and point gnus's nnimap to that, so no blocking in emacs :) <bandali>valignatev, for guix packages, i'm pretty sure you need to install fonts via guix as well <bandali>and like leoprikler said, fc-cache -f <leoprikler>Guix can't do that for you, so without doing it yourself, you end up with weird blocks and what not. <nckx>valignatev: You can set them on Guix as well, just plonk some XML into ~/.config/fontconfig/conf.d/. I use that to tweak hinting, for example. <snape>bandali: I find using dovecot too much of an overkill :) <snape>also, to browse news.gmane.org (nntp), it's blocking, and I need that :) <civodul>Gnus in general is very much blocking all around <bandali>snape, hehe :) i was a bit hesitant at first, but i think it's been one of the best decisions i've made wrt using gnus <bandali>with nnimap pointed to a local dovecot, it's always pretty instant <nckx>fc-cache doesn't have anything to do with font antialiasing and hinting. <bandali>but yeah using nntp would involve a bit of blocking for sure <civodul>does C-g work in exwm when Emacs is blocking? <snape>I know, I hesitated about that. But my workflow now is: I use GNUS to brows nntp news or local .mbox files, and mu4e for IMAP <bandali>civodul, i *think* so (not on my exwm machine right now to test) <snape>also, mu4e and gnus share a lot of config <bandali>another benefit of local dovecot is always having access to email <snape>so it does make sense to use both of them <nckx>bandali: So does isync tho'. <bandali>nckx, yeah. i use isync to sync mail from my mail server via imap to a local maildir, and put a local dovecot in front of it <bandali>i would've used gnus's nnmaildir, but it's very slow <bandali>but thankfully (local nnimap is blazing fast :) <snape>yes, but that implies running a daemon :/ <snape>with all the configuration in /etc, stuff in /var, it implies too <valignatev>leoprikler: Oh I've installed these fonts a long time ago. And emacs from guix uses them. It just bad at rendering them. So there's probably a fontconfig mismatch between what guix sees and what Arch has <snape>I'm trying to keep my config as small and understandable as I can <snape>it makes it pleasant to look at it, and easy to maintain <nckx>bandali: Ah, so you're using a full-blown dovecot daemon to replace what could be a simple local readdir but that's too slow in gnus? <snape>nckx: it's not the same, readdir doesn't store things <snape>sorry, nnmaildir doesn't store things <nckx>valignatev: Assuming you read my replies above: have you tried something like fc-conflist. <snape>hm actually I might be wrong, I was talking about nnimap <nckx>Oh I have no idea, I'm just sitting here thinking ‘I must have been spoilt silly by mu4e’ 🙂 <bandali>snape, i feel ya, but it's not that bad :) <leoprikler>valignatev: That may very well be. I'm trying this out on Guix System, where Emacs 27 doesn't look so different from Emacs 26. <leoprikler>And Emacs 26 looks like Emacs 26 as I'd expect it on other systems. <snape>bandali: indeed, with Guix services it's way nicer already! <nckx>I link to the Arch wiki but that's a coincidence, these settings would be for Guix. <nckx>Glad someone got the heh 🙂 <valignatev>Okay people, I symlinked my default fontconfig from Arch to ~/.config/fontconfig and it did the trick. So guix reads XDG_CONFIG_HOME and doesn't read anything from /etc. As it should, I suppose <nckx>Hm, maybe, I think it's just a bug/oversight (I bet it does look in /gnu/store/…fontconfig…/etc). <valignatev>I hope such symlink won't confuse an actual fontconfig, because it supposed to be created from various places including the one from ~/.config. And I just symlinked this generated config to ~/.config :) Home it's smart enough <nckx>I don't think /etc is evil even on Guix. <nckx>But then I don't use other distros. <nckx>valignatev: Happy to hear it's fixed. What do you mean by ‘actual’? ***ng0_ is now known as ng0
<valignatev>By fontconfig installed in Arch. According to doc, the file it's using is /etc/fontconfig/font.conf. It's generated automatically from many places including ~/.config/fontconfig/fonts.conf. What I did is I symlinked this generated config to the place it supposed to gather info from. It seems to work fine, but it's a bit scary <leoprikler>If something's not scary, you're doing it wrong. That is the Arch way. <valignatev>Knowing Arch enough, I'm sure i'll now that something is wrong only after reboot, which won't happen in the next month or who :) <roptat>llvm is still building, but I worked a bit on coq. it used to be 1755.7 MiB. With a split of coqide to a separate package and removing of duplicate binaries, coq has now a closure of 788.6 MiB (composed of coq and ocaml mainly) :) <roptat>I am also working on adding a bin output to gtk+-2, which I hope will remove python3 from its closure <roptat>now I need to test it properly :) <roptat>that's mainly because of coqide, which requires gtk, and the whole set of graphical libraries behind it <roptat>I split it from the main package <roptat>also, I removed some references to lablgtk in binaries that didn't need it (it was in a string that was never used, but defined in a coq_config module) <civodul>yeah i think it's important to be able to use Coq without the GTK+ IDE (e.g., with ProofGeneral) <johnjay>uh.. is there a minimum hd size for guix? <johnjay>civodul: also since i have you here, can you tell me is proof general somewhat extensible? <reepca>so I'm in the middle of a long, painful rebase, and I've realized that I made a mistake on one of the earlier commits. Is it possible to do a rebase-within-a-rebase? <johnjay>i had the idea to add a minor FOL based thing to it <civodul>johnjay: i guess so, but i'm no expert <civodul>i've only used it once quite some time ago <johnjay>ah ok. i glanced at the .el file but nothing jumped out at me <bandali>civodul, i think i'd asked a similar question a long time ago, but i'm not sure. so here goes: is it possible to use a different version of emacs in guix? <bandali>like, i'd like to use emacs-git instead for the emacs and emacs-minimal packages <civodul>bandali: you could define an "emacs-devel" package where the 'source' field is (git-checkout ...) <civodul>it would thus take the current tip of the branch when you build it <bandali>right, yeah makes sense. and is there a way to have that be used when installing various emacs-* packages? <civodul>you could use --with-input=emacs=emacs-devel <johnjay>bandali: your name is really familiar. are you an emacs dev? <bandali>civodul, ha! where would i issue that? with guix package? would that work when using a manifest? <bandali>johnjay, not officially an emacs dev :p but yeah i do hack on it every now and then. i also hang out on #emacs here and post to help-gnu-emacs@ occasionally. or you may know me from EmacsConf :) <johnjay>bandali: maybe. i think i was browsing r/emacs for info about guile and saw you there <bandali>johnjay, ah :) yeah i've posted to /r/emacs a bunch, mainly the EmacsConf 2019 announcements <johnjay>ah ok. i was reading the emacs in next 40 years thread, that must have been it <johnjay>mostly i was trying to figure out how much progress guile had made since i had trouble compiling it <pkill9>does anyone know of a package for sd-bus (the systemd implementation of d-bus)? I'd like to run anbox but they use sd-bus, which means you need libsystemd :/ <johnjay>actually that's why i'm trying to install guix <johnjay>but guix installer just said it ran out of space in virtualbox. T_T <pkill9>well, not a package, i mean a project <johnjay>ah the guix installer crashed again. says unable to locate keymap update file <nckx>johnjay: How big was the box? <johnjay>virtualbox VDI, i set it to dynamic 8 GB size hd space <nckx>My guess is 10-20 GiB to be usable, but a limited-use or non-desktop VM might get away with less. <pkill9>hmm interesting, there is one reference to sd-bus in guix, the localed package <nckx>I guess I'll say more than 10 in future 🙂 <snape>reepca: you can end your rebase and later on rewrite the wrong commit can't you? <pkill9>ohh, localed is extracted from systemd <pkill9>maybe i can use some inspiration from it then <nckx>johnjay: Like all ‘system requirements’ ever it's an arbitrary guess. If you edit your system.scm before installing to remove non-essential parts you could make it fit into 8 GiB with ease. Just not very fun. <civodul>in a manifest you'd use package-input-rewriting <bandali>civodul, ha, i see. btw, what do you think about having a guix config file, a la git's, where one could specify options/args to always be used per each guix subcommand? <valignatev>I wonder if it's worth polishing and submitting as a patch to upstream Guix as something like emacs-next. I've noticed that python.scm has python-next and guile.scm has guile.next. What do you think civodul? Eventually there will be pinned release of Emacs 27, and Emacs-next could be pinned to commits that go to some relatively later HEAD <civodul>note that there's $GUIX_BUILD_OPTIONS, which can help sometimes <valignatev>Wow, I'll put my "-c 8" to $GUIX_BUILD_OPTIONS right away <bandali>and yeah, as someone who hacks on emacs often, i think having a ready-to-use emacs-next or emacs-head would be great <civodul>valignatev: you can also pass -c 8 to guix-daemon so that it's the default <civodul>bandali: you could also maintain an "emacs-next" package that would build from a snapshot, and regularly update that snapshot <civodul>but yeah, it'd be nice to have in Guix proper! <bandali>okay cool, i might send a patch if i get a clean and working emacs-next definition :) <valignatev>bandali: Fell free to use the definition that I put to github! I'll be only happy if emacs-next appears in guix out of the box :) <bandali>valignatev, thanks :) i'll definitely peek at it while working on an emacs-next. just in case, would you add a license to it? ideally gplv3+ :) <bandali>though i doubt i'd straight up copy anything from it <valignatev>Sure, I meant to do that. Sad that you can't initialize a github repo with a license right away <bandali>ha. yeah i haven't used github in a long time. it's not the most free-software-friendly project forge out there <pkill9>OH, sd-bus is already included in elogind <valignatev>> "it's not the most free-software-friendly project forge out there" Oh it definitely isn't X_X <snape>it's not the less friendly either <reepca>snape: how does one "end the rebase"? I'm using magit, and the options presented to me are "continue, skip, edit, abort". I guess I'd edit, remove the remaining steps, and then continue? <snape>reepca: one solution would be to 'continue', end your rebase, as you would normaly do, and after it's done, you rewrite the commit where you did a mistake <reepca>sounds like I need to write a note somewhere <snape>another solution is to start from scratch again :) <roptat>llvm 8: 270.1 MiB -> 188.9 MiB of closure \o/ <snape>reepca: you add a fix-commit during the rebase <snape>that later on you'll move down and squash <reepca>snape: ooooh, I like that idea a lot <reepca>no need for external notes, and I can start testing with the fix applied right away <snape>it's easy to add a commit: you stage the thing you want to add ('s') and 'cc' <snape>and it's a normal thing to add commits during a rebase <reepca>also, I'm running 'make' currently, and I'm getting a bunch of "<unknown-location>: warning: shadows previous definition of `-location' at <unknown-location>" <reepca>is that a regular thing now or did I screw something up? <snape>without context, it's hard to know what you are 'make'ing <snape>(but I've no idea whether it's normal or not) <bavier>reepca: I see that warning all the time <kirisime>There was an issue where the pam-limits-service didn't work for GDM login and I've worked around it by copy-pasting the service into my config.scm with the affected file list fixed. Has the issue been resolved or do I still need this workaround? <kirisime>Actually nevermind I can just read the source and yes it's fixed. <civodul>reepca: these warnings come from the configuration machinery under gnu/services <civodul>no big deal, but would be nice to fix <nomr>#guix, when I run guix on my foreign distro, ld.so gives me this now: elf_machine_rel_relative: Assertion `ELF32_R_TYPE (reloc->r_info) == R_386_RELATIVE` failed! <nomr>... instead of doing what I ask e.g. installing package. Does an know what it is? <roptat>Have you installed guix for the correct architecture? <nomr>roptat yeah it was working fine yesterday <nomr>I tried LD_DEBUG=all and it starts relocation processing for libgcrypt 1.8.5 right before the crash. <roptat>Do you have any LD_PRELOAD variable, or stuff like that? <nomr>I have one guix that still runs and it uses libgcrypt 1.8.3 ... Can I somehow use it to verify or rebuild my libgcrypt 1.8.5? <roptat>I think so, try to run guix gc --verify <nomr>No, just GUIX_LD_WRAPPER_ALLOW_IMPURITIES=no <nomr>nice --verify=contents checks hashes =) <nomr>Any way to enable verbosity for guix gc? <utraz>When i try to run "guix system reconfigure /etc/config.scm" i get a long error. I tried modifying my config.scm a bit, but to no avail <snape>utraz: could you paste your /etc/config.scm as well? <snape>btw you can use 'sudo -E' to make sure you preserve your environment <snape>utraz: so the problem is with the 'services' field <snape>first of all, the 'append' call is useless <snape>then, you have (list service1 service2 %desktop-services) <snape>but %desktop-services is itself a list! <snape>(cons* service1 service2 %desktop-services) <snape>which will return a list with service1, service2, and all services in %desktop-services <snape>in other words, instead of having (a b (c d e)), you should have (a b c d e) <utraz>Thanks a lot, it's working :) <lispmacs>my Debian 9 nautilus had the ability to open a folder in the terminal, but this doesn't seem to be available in Guix Gnome. <lispmacs>i needed it to figure out the file system path for gvfs mounts <nckx>lispmacs: According to a random Internets, on Debian that's provided by a separate nautilus-open-terminal thing. <nckx>Maybe it's not packaged. <nckx>Or nautilus-extension-gnome-terminal. <nckx>So many random Internets to choose from. <lispmacs>does anybody know if Gnome is still putting a virtual directory for gvfs mounts somewhere on the filesystem? It used to be under /run/user/etc... but I can find them <lispmacs>my problem is that keepassxc file dialog does not allow browsing gvfs mounts <lispmacs>so, I can see the remote database with nautilus, but can't connect keepassxc to it <lispmacs>hmm, seems that was some kind of fuse application <lispmacs>hmm, gvfs package says "It also supports <lispmacs>exposing the GVFS mounts to non-GIO applications using FUSE." <leoprikler>sometimes that directory is not correctly set up though; killing gvfs might help <lispmacs>leoprikler: I see that directory, but nothing inside it <lispmacs>leoprikler: should I restart some herd service, I just killall -9 gvfs...? <lispmacs>leoprikler: well, what do you know, that worked ***MinceR_ is now known as MinceR
<leoprikler>I think it's pkill gfvsd, but either way it's some weird bug that I haven't sufficiently analysed yet. <lispmacs>hmm, so, the /run/etc... files now exist, but keeppassxc is unable to create files there <atw>nckx: I'll have you know I spent a couple hours last night trying to get emojis to show up in emacs/erc so I can see what you're expressing without C-u C-x =. Got any font recommendations? The closest I got was using Unifont everywhere, which I wasn't happy with <lispmacs>but I can manage to write a file from the command line. hmm <lispmacs>I can open the file from Nautilus into Keepass, but only in read only <lispmacs>getting error "invalid argument" when trying to save. Maybe something to do with fuse file naming? <pkill9>anyone have any idea why my build of anbox is failing? I *think* it's failing at a link phase from looking at CMakeErrors.log: https://paste.debian.net/plain/1120820 (put it in a file and run `guix build -f <file>` to try to build it) <lispmacs>yes, other applications getting the invalid argument error also <nckx>pkill9: It took me longer than I'd like to admit to figure out I was lookit at a Scheme file. That's… certainly… a way… to ship patches. 😛 <nckx>atw: Not really, I've never successfully got Guix + Emacs + mojies working myself. I don't like emacs IRC clients for unrelated reasons so I use HexChat. <bavier>pkill9: oh cool, I was wanting to try anbox; a guix package would be nice! :) *nckx forgot to build anbox with -c1, builds again. <atw>nckx: fair enough, and yeah, the erc user experience has not been a bed of roses... <leoprikler>atw: Noto Fonts work most of the time. Emoji support gets better with Emacs 27 <atw>color me very excited for 27! Noto is pretty nice <nckx>atw: I use Google Noto for mojies elsewhere even though they look like crap. <bavier>pkill9: seems like some shebang patching not working <nckx>I use an older version (no longer in Guix upstream) that looks slightly less crap. <bavier>pkill9: scripts/gen-emugl-entries.py: /usr/bin/env: bad interpreter: No such file or directory <bavier>warning from patch-shebangs phase says "python2" cannot by found *nckx just built anbox for nothing (╯°Д°）╯︵/(.□ . \) <nckx>Back on the warm blanket the laptop goes. <zig>I am not sure what will be the purpose but I think I will come to both (even fosdem!) <bavier>pkill9: but yeah, other errors with missing systemd headers and boost header errors <nckx>zig: FOSDEM is fun! What do you mean by ‘not sure what will be the purpose’? <zig>nckx: well, I don't know what will happen at guix (un)conference, or more precisly how I will be useful, since I am not very good at guix. <pkill9>ah yea i gave it python3 instead of python2. <pkill9>systemd header error should be fixable, i fixed a couple other systemd header errors in the patch <zig>the few times I went to a conference, I gave a talk, so this will be first time I go to a conference without giving a talk. <nckx>This reminds me that our Nim package is extremely outdated, if anyone's interested. <zig>usually I disappear after my talk! ahah! <bavier>pkill9: oh, I guess what I saw from the boost headers are just warnings. the coloration 'guix build' does just made the 'error' part of the namespace stick out *smithras is thinking about going to FOSDEM for the first time this year <nixo__>Hi! Can I get the version of an input? <nixo__>docbook-xsl stores templates under /xml/xsl/docbook-xsl-1.79.1/manpages/ and I don't know how to construct this path without accessing the vesion <pkill9>nixo__: "(package-version package)", though inputs are neccessarily packages <nixo__>pkill9: Thanks. grepping for it I found the same usage under moreutils.scm. NixOS instead ships the path already stripped <bavier>nixo__: `grep 'package-version docbook-xsl' gnu/packages/*.scm` for examples *nckx backspaced 3 messages so far, this room is too damn helpful & efficient! <nckx>zig: Of course I personally recommend the Guix days, but everyone's different. It's fair to say that the Guix days are more of a laid-back community-building event than 2 days of highly technical talks & discussions. Of course there is some of that, too. <nomr>It turns out my libgcrypt-1.8.5 (and two profiles) _are_ corrupt ... How do I properly recover this? Can I guix gc -D the store path and then repull? <nckx>nomr: Did you run --verify=contents with ,repair? <nckx>It will automatically re-download damaged items *if* a substitute is available. <nomr>Oh, thanks! Forgot repair was there <smithras>Does anyone know if issues.guix.gnu.org is down? I can't get a response :( <nckx>smithras: Same here. rekado might need to poke it again. <nckx>That's (IIRC) provided by gcc (or something very core like that) so it's a sign your library path is lacking. <nckx>My CMake-fu is too poor to say more. <nomr>until I ran guix, I had no idea files were getting corrupt on my system. It uses flash storage. <nckx>'t Is the week of Guix corruption ♪ falalala… <bavier>pkill9: 'libiberty' is the scheme value <nckx>My /var/guix/db got destroyed for the same reason: bad flash. Unfortunately there's no repairing that. <bavier>seems it's a hidden package, not sure if that's intentional <bavier>or just because it's inheriting from gcc <nckx>Oh, it's separate? I apologise for spewing bullshit, I've never seen that before. <nckx>grep libiberty gnu/packages/*scm <nckx>("libiberty" ,libiberty) it is. Sorry. <pkill9>may as well try adding it anyways <nckx>Yeah, the last time (and all previous times) I ran into that error on other distributions is was a sign of path/toolchain borkage, not a missing package. But Guix isn't other distroes. 🙂 <nckx>nomr: I've switched to btrfs for this reason. I've become paranoid of backing up subtly damaged files and not noticing before all copies are bad. <zig>re -liberty, fun name. <nckx>I think it made me laugh when I first saw it. <nckx>In my defence I was, like, 9. <zig>i discovered gnu/linux at 18 <zig>mongodb wiredtiger database people recommend xfs, does it make sense to anyone? <zig>(and now I will be 35 soon-ish) <nomr>is it that btrfs helps on flash because it refrains from rewriting? <nckx>nomr: No, it just checksums everything, so it will throw an error if a bit flips (or worse). ext4 & friends just happily return garbage. <nckx>XFS still has a good reputation for performance with some workloads, yes. <nckx>I know several people who still swear by XFS on their laptops, although they all look exactly like the stereotype of ‘person who uses XFS on their laptop’. *nckx is up to 90%... where will it fail? Suspense! <nckx>sd_bus_process is a libsystemd function. <pkill9>nckx: i replaced include references to systemd/sd-bus* with include references to elogind/systemd/sd-bus* <pkill9>but maybe it's not a sufficient replacement, dunno <nckx>pkill9: Then what I find strange (at first glance anyway) is that the string elogind doesn't occur anywhere in the build after it starts (grep it). <nckx>I'd expect -lelogind. It looks like ld does too. <pkill9>the configure file doesn't check for it, i commented out the pkg check for libsystemd <pkill9>(i don't know what i'm doing, lol) <pkill9>just pushing things around until they look like they work <nckx>Well, would that check have added -lsystemd? Then you need to patch it or otherwise pass -lelogind to the linker. Adding it to LDFLAGS manually would probably do that. But it's ‘cleaner’ IMO to properly beat^Wpatch the systemd check into becoming an elogind one. Who knows what other logic it changes? <nckx>Adding -lelogind to LDFLAGS manually (making sure that you're appending to it, not resetting it) would be a good way to test my suspicion. You might need to add the path (-L/gnu/store/…-elogind-…/lib) as well. <nckx>That's all I have time for now, got to go, BRB, TTYL, LOL o/ <johnjay>is there a way to modify the installer so that when it fetches substitutes it uses --retry-connrefused on wget? <johnjay>my install has failed and it gave the reason bad network <nomr>So, I'm using an old current-guix profile because my libgcrypt-1.8.5 is corrupt, but when I run guix gc --verify=content,repair it tries to do the repair with a newer, broken guix. How do I repair it? <nomr>I'm thinking it would be simplest to delete the store dir and repull <nomr>I'm trying to find information on the substituter protocol to see if I can do the repair manually <civodul>nomr: "guix gc --verify=content,repair" attempts to do that <civodul>note that you must never modify or remove stuff from /gnu/store <nomr>civodul: it for some reason launches a newer guix to do the substitution rather than the one in my path, which then crashes because of my corrupt package <nomr>Hmm maybe it would help to run an older guix-daemon <nomr>leoprikler yes I do that but verify seems to fork a subprocess or something .. it dies with ld.so error that broken guix links to, midway <nomr>Yeah checking source verify is done by daemon =). I bet i can repair by launching older daemon <pkill9>i've forgotten, how do you change directory in guile? <pkill9>where do i add kernel modules to the operating system? <nckx>pkill9: In Guix we also have a more functional(ish) ‘(with-directory-excursion "foo" <code…>)’ style. <nckx>pkill9: (initrd-modules (list "mymod" …)) <bandali>would be cool to upstream these little nuggets to guile, no? <nckx>There's probably a %default-modules or similar you need to cons* onto that. <pkill9>yea there is looking at the manual *nckx sees through your ruse of rebranding ‘snippets’ as ‘nuggets’ 😛 <nckx>It would be nice to have it into a mid-level example package if there was such a thing.