<resttime>Hello, I'm interested in working on guix as part of the google summer of code going on. <resttime>Any of the mentors here or know how I can contact them? <resttime>Lisp is one of my favorite programming languages so I thought it'd be neat to be able to work on a project with it :) <Gamayun>resttime: Some of them will definitely be around. Anyone / topic in particular? Maybe send a little enquiry on the mailing list too... :) <nckx>Hi resttime! Great to hear that. The only mentor listed that I know is frequently in #guix is civodul (Ludovic), but you'll need to be around in the European day. The others aren't such avid IRCers in my experience. <nckx>Definitely send a mail to the mailing list if you're interested. <nckx>sneek_: later tell rvgn: Installing Evolution gives me an ‘evolution’ executable in my PATH (which fails due to some missing GNOMEness, but it executes just fine), so please give more details. <nckx>resttime: I believe your first message will be held for moderation, so just send it and give it a day or so. ***vagrantc_ is now known as vagrantc
<rvgn>Not able to add account to Evolution. At the end of the wizard, when I click apply, I am getting the error "The name org.gnome.evolution.dataserver.Sources5 was not provided by any .service files". What should I do? ***buffet- is now known as buffet
<rekado>civodul: there’s another instance of a thunked field that is now broken. It’s in the cran importer (guix/scripts/refresh.scm), “update-package”. <rekado>I don’t have any record I could pass in, so my fix looks like this: (changes #f) <rekado>instead of “(changes)”, which is now broken *rekado wonders if maybe this should just be a delayed field <civodul>how does that 'changes' get propagated? <civodul>it's not part of a record in (guix scripts refresh) <rekado>it is returned by “package-update” <rekado>it’s one of three values that the procedure returns *rekado needs to leave for a while <civodul>rekado: i'd remove 'changes' from the match pattern, and then write (upstream-source-changes source) <rekado>civodul: I need to look at the issue again. Don’t really know what to do about it. <roptat>rekado, did you receive my email after all? <roptat>I'd like to fix php on armhf. It's failing 4 tests on that architecture compared to intel, so I'd like to disable these, but I'm not sure what I should use to check that we are building for armhf? <roptat>%current-system, %current-target-system, something else? <roptat>like in classpath-jamvm-wrappers for instance? <buffet>hey, im trying to boot guix in a vm (both using the installation medium and the qemu image), but it keeps hanging on `shepherd[1]: waiting for udevd...` <buffet>not much of a qemu person, so i just copied the commands from the manual <shcv>so, will guix support / allow packages for zfs? <kmicu>shcv: did Oracle relicense ZFS under a GPLv2 compatible way? <shcv>no, but OpenZFS is CDDL, so I was hoping that at least the packages might be available for userspace zfs, even if they can't be built into the kernel <wednesday>When I updated to the latest system I boot and end up in sddm(auto login) but have no mouse or keyboard working, and during boot I get this Mar 26 23:28:19 localhost vmunix: [ 16.548419] udevd[409]: failed to execute '/gnu/store/gdm4g9h9nk5g922g56vq89jhbzbda4sc-eudev-3.2.7/lib/udev/${exec_prefix}/bin/udevadm' '${exec_prefix}/bin/udevadm trigger - <wednesday>s block -p ID_BTRFS_READY=0': No such file or directory, anyone got any ideas? <kmicu>shcv: Guix could distribute ZFS as source (with disabled substitutes). Compilation is then necessery on user side but CDDL is free license so not-combined-with-GPL packages can be included. Sure. <shcv>kmicu: ok, thanks; that was what I was wondering <shcv>I'm considering trying guixsd from using gentoo for a long time, so that's not particularly inconvenient <kmicu>Great b/c in reality Guix System is source-based distro. Subtitues are additional, reproducible goodies ヽ(*＾▽＾)／ <shcv>I won't be able to switch for a while though, since I have intel wifi; guess I'll need to do something about that *kmicu *whispers* you can find examples of using stock Linux kernel (*whispers more* with non-free firmware) on the Internet. Switching kernel in Guix System is pleasant if you don’t mind compiling it. <shcv>shhh! we'll get in trouble. But thanks for the tip <shcv>but my system isn't that different from what would be achievable in guixsd (emacs + exwm + FF), and the main thing that's been keeping me devoted to Gentoo is openrc <shcv>and the use flag system is nice too <kmicu>In my experience configuring operating system in lisp is like use-flags^3. <wednesday>except if you wanted use flags for all your packages you probably need to write your own packages =^) also tfw nobody can fix my issue <shcv>yeah, I'm hoping it works out that way; I'm not sure that it will be quite as easy universally, but I end up having to configure a lot of packages individually anyway <kmicu>Regarding OpenRC, that’s currently not implemented cuz demand is… you are basically the first person asking about it xD <shcv>I'm not actually demanding it <wednesday>can guix use systemd? never checked because why would I <shcv>I meant devoted to gentoo in that all of the other distros seem to be caving to systemd <shcv>guix is the first one in a long time that seems like an acceptable alternative <kmicu>wednesday: systemd is not supported but it could be integrated, like OpenRC, or s6. <shcv>I really like just about everything about gentoo, but portage - bless its heart :P - sometimes can't figure out a good upgrade path that balances all of the dependencies <shcv>makes system updates a rather labor intensive process <kmicu>(NixOS could support alternative init/supervision systems too but no one wants to send patches and current users are ok with pros/cons of systemd.) <wednesday>also kmicu do you have any ideas about my problem I said erlier. <rekado>wednesday: this error looks strange. Does it really say “${exec_prefix}”? <wednesday>And before you ask /gnu/store/gdm4g9h9nk5g922g56vq89jhbzbda4sc-eudev-3.2.7/gnu/store/gdm4g9h9nk5g922g56vq89jhbzbda4sc-eudev-3.2.7 does exist, and in its /bin is udevadm <kmicu>wednesday: I would like to help but I’m not familiar with SDDM. I recommend rolling back to a prev. working version and write to guix mailing list and wait for an answer. <rekado>it should just be /gnu/store/gdm4g9h9nk5g922g56vq89jhbzbda4sc-eudev-3.2.7/bin <wednesday>kmicu: from what it seems its more than an sddm issue, since that error is on boot <rekado>I’m looking at the output of eudev and I don’t see that nested directory <kmicu>wednesday: maybe there is a regression in master repo (like with recent guix pull issue) and we need to wait. <kmicu>(Ideally I would bisect changes between the latest working revision and current broken one.) <wednesday>rekado: when I was looking at the code for the udev service everything seemed fine to me, and yea i am using btrfs <rekado>the file /gnu/store/gdm4g9h9nk5g922g56vq89jhbzbda4sc-eudev-3.2.7/lib/udev/rules.d/64-btrfs.rules mentions “${exec_prefix}/bin/udevadm trigger” *kmicu is using btrfs too but did not pull recently. <rekado>so maybe that should have been replaced at build time <wednesday>kmicu: Is there a way to find what commit this system is on now? <rekado>this version of eudev is the same as on the master branch <rekado>I’m looking at exactly the same output directory <rekado>I propose to patch away the exec_prefix in that rule file. <wednesday>I'm on the system thats broken, just an older working generation heh <rekado>so, the 64-btrfs.rules file is generated from rules/64-btrfs.rules.in, which has a placeholder for @bindir@. <rekado>@bindir@ is expressed in terms of exec_prefix <rekado>I’m rebuilding with “--bindir” explicitly set to $out/bin <rekado>(there are still references in pc files, but that’s fine) <rekado>unfortunately, I don’t think we can change eudev on the master branch <rekado>wednesday: if you’re not averse to compiling things could you please try to reconfigure your system after applying this patch to a Guix checkout? <rekado>changing eudev would cause 1,353 packages to be rebuilt. <rekado>we usually do something big like that on a separate branch to reduce the impact on substitute availability <wednesday>So what would my best choice be in order to apply that patch/fix it myself^ <rekado>you would fetch the Guix sources via git, apply the patch, compile Guix, and then use ./pre-inst-env guix system reconfigure … <rekado>the manual has some information on how to do each of these steps <wednesday>Would I have to do that each time I want to reconfigure? and since its a package could I just redefine a new eudev package that inherits from the other one and changes the config flags? <rekado>wednesday: you’d have to keep your modified Guix around until this change makes it into the Guix master branch. <rekado>wednesday: you *could* build a variant of eudev and use that in some strategic locations <rekado>it wouldn’t affect all packages that currently depend on eudev, but that might be okay. <rekado>unfortunately, I can’t tell you what those strategic locations are. <wednesday>well I have a directory in my package path already, hopefully that would do, migth give it a go <rekado>something in your system uses eudev (some service maybe?) — you’d have to tell that part to use your modified eudev instead. <rekado>just having a package variant for eudev does not cause anything to use it. <rekado>Guix provides APIs to rewrite dependencies recursively and to use a different package for most services, but you’d first need to figure out where the change would be needed. <civodul>rekado: re eudev, we could work around the issue in the eudev service (providing a correct rules file), or have the service temporarily use a patched package <rekado>ah, so there is a service using eudev :) <wednesday>sddm probably has a dependency on it, but who knows where esle <rekado>that’s the part I wasn’t sure of. <rekado>wednesday: the change really only affects the generated rule file. So you only really need to change whatever uses that rule file. <nly>how can I instruct `guix build` to use a local channel? It'd be nice to use the working directory. <nly>Atm, I have to commit, push, and then `guix pull` to make the changes available <wednesday>rekado: I'm not sure how I would do that, and the place I know it to be used is the service since that's where I'm getting my problem <rekado>nly: you can either use “guix pull” after specifying a channel, or you can use GUIX_PACKAGE_PATH for quick local tests. <rekado>wednesday: the udev-service takes two arguments: [#:udev EUDEV #:rules ‘'()’] <rekado>so, you’d define a variant package “my/eudev” that “(inherit eudev)” but overrides the configure flags <rekado>and then in your operating-system configuration you’d replace the udev-service with (udev-service #:udev my/eudev …) <civodul>fun thing: type "guix build r-XYZ<TAB>", where X, Y, and Z are random letters <civodul>works for pretty much any combination or X, Y, and Z! <rekado>frustratingly, it does not work for “r-xyz”! *rekado goes to package more R things… <wednesday>rekado: I'll give that a go in a minute, thanks my dude, and thanks eveyone else too heh <civodul>also, i was looking for an R package that would not be up to date, to test 'guix refresh' changes <civodul>and guess what: they are all up-to-date! *civodul looks at the CPAN URL issue that nckx reported <civodul>commit 1ee3d2dcb8892b2ed1a0212fdd6ac2c47f2c8da2 fixes the 'guix refresh' bug we discussed this morning <buffet>is it known that the log gives a 403? <buffet>rekado: that one. gives me an nginx 403 Forbidden <buffet>for some reason makes a difference <buffet>thanks alacritty for ommiting it *apteryx the pypi importer is starting to look good! Remaining point: parsing the new METADATA file instead of metadata.json from wheels. <rekado>apteryx: thanks for working on it! <efraim>Now that I have perl6 in I should look into an importer *bavier always building libreoffice... <civodul>bavier: it seems to be available on ci.guix.info though *bavier kills and tries again <civodul>or perhaps you're building a different derivation? <bavier>I pulled about 12 hours ago, I guess, can try again <bavier>oh, right, the store path is the 510aq... <bavier>--dry-run says the derivation would be built <efraim>Up to you to try deleting /var/guix/cache or the like <bavier>and 'guix weather --coverage' doesn't say it's missing <bavier>I deleted /var/guix/substitute/cache, then reran 'guix package -u', and it still insists on building libreoffice <Blackbeard[m]>now that i think about it your IRC Nick is Ludovic backwards <Blackbeard[m]>I am a lawyer and I am studying a master so I didn't thought I could participate. <civodul>the GSoC web site lists the eligibility criteria <Blackbeard[m]>I know I haven't sent any patches to Guix but i would like to participate <civodul>sure, GSoC is primarily here to bring new people to the project <civodul>see if there's something that would suit you <civodul>and then we can discuss the subject on the mailing list or here <roptat>nothing prevents you from contributing afterwards if you liked the experience ;) <Blackbeard[m]>and I am waiting for the weekend after all the crazy homework <Blackbeard[m]>this one looks awesome: Content-addressed protocol for substitutes <apteryx>do we already have a function which is generally useful at extracting any kind of archive? <resttime>Blackbeard[m]: we might be pretty similar lol <resttime>Krita and Guix are the exact two projects I'm interested in for gsoc <apteryx>I'm thinking url-fetch should know how to do this <resttime>Haven't sent any to Krita yet but do have fair amount of EXP with C++ and animation features are something I'd actually use if I worked on it <apteryx>eh... built-in-download. Seems it just hands-off to the daemon. <resttime>Don't have too much XP with Racket/Guile, but have done stuff with Common Lisp and Emacs Lisp <resttime>Also thinking it'd be really cool to work on a lisp project for once <roptat>so I disabled four additional tests in php for armhf, but I'm unsure why they fail <apteryx>ah, gnu-build-system's unpack phase. Doesn't do anything too magical. <roptat>one of them is related to a CVE but it seems harmless: one command might trigger a CPU-intensive computation, so they check that in newer versions the operation is truncated and they check that it takes less that a microsecond to finish <roptat>I have no clue for the three other tests though <civodul>apteryx: yeah we just call out to tar to extract archives <civodul>with Gash we may have something more fancy, we'll see :-) <Blackbeard[m]>civodul: this one looks awesome: Content-addressed protocol for substitutes <civodul>so i'd suggest making sure you understand how the "substitute" mechanism works currently <civodul>to get a better feeling of what this means ***maddo_ is now known as maddo
<nckx>civodul: Thanks again for fixing the CPAN importer so swiftly. *nckx .oO maybe they're *both* bots. <shcv>so, what about guix is 'fixed' vs 'rolling' releases? <shcv>isn't it just packages all the way down? <shcv>besides, obviously, the package manager itself... <vagrantc>shcv: not sure i understand the questions <nckx>shcv: I don't get the distinction. Yes, it's a package collection, yes, it's a rolling release? <nckx>shcv: A non-rolling example would be Debian. Packages aren't ‘really’ (feature-)updated between releases, only ‘fixed’ when needed. <nckx>Does that make sense? I've never even used Debian. Great idea to use it as an example. <vagrantc>guix does have a staging area for more disruptive updates ... core-updates? <nckx>vagrantc: Hm. Disruptive from a ’rebuilds’ perspective, not really a ‘fallout’ one. <nckx>E.g. the thunking breakage yesterday was pushed to master. *nckx likes that rapidity, to be clear. <nckx>And the fact that 400 Perl rebuilds are probably lighter than something that ’only’ rebuilds 40 packages… including icecat & libreoffice. *nckx needs to buy a new laptop. Is an X200 still a realistic thing to invest in? Is anyone running Guix System on one right now? Are there performant alternatives? <apteryx>X200 is probably as hackable as it gets for a laptop (with libreboot, custom wifi card, etc.). Otherwise I've heard of Purism but never bought one. <nckx>apteryx: My current budget is about half a Librem, I'm afraid ;-) <apteryx>nckx: yeah, their pricing is a bit like that of Apple. <apteryx>but I appreciate the effort they put in their offering! <rekado>nckx: I probably wouldn’t go for a X200 these days for two reasons: bad GPU (= no supertuxkart or blender) and limited max RAM. <rekado>others might add that the display isn’t great (or worse: quality depends on the batch you’re buying from) <rekado>other than that the X200 is lovely. <nckx>rekado: That addresses my exact reservations(/fears), thanks. <rekado>the Librem 13… well, I wouldn’t recommend it, but my experience with it may be unusually bad. <rekado>coming from a Thinkpad it never quite clicked for me. <rekado>I’m sending it in for repairs next week to address recurrent flickering problems <rekado>build quality was just fine, but it’s so much more fragile than an X200 <rekado>(I don’t treat my laptops like pets and I take them everywhere; the Librem doesn’t really like that) <rekado>the X220 or X230 might be worth a look <rekado>you can’t get libreboot for it, but you can likely disable the ME on it. <rekado>(same as what they do for the Librem) <rekado>the X220 and X230 have sufficiently better graphics chips compared to the X200 <apteryx>nckx: otherwise the T460s I'm using has a nice screen and GPU, but the ugly part is that you can't swap the internal (blobbed) wifi card, so you're stuck with a USB dongle/ethernet cable. <rekado>nothing great but just about good enough for many cases. <apteryx>(and it doesn't support coreboot/libreboot) <rekado>ah, yes, forgot about that: the Thinkpads all have a whitelist of WiFi cards <rekado>and they won’t get past POST with an incompatible card. <rekado>on some of them you can apply a BIOS hack to alter the whitelist <nckx>rekado: I was just looking at X230 s. I might be too optimistic. <rekado>on some you can install Coreboot. *nckx would like an X230 tablet just for the retrocoolness, but nobody's crazy enough to sell them pre-flashed and I'm too chicken to try. <rekado>the tablets are much more challenging to flash <rekado>I flashed the X200s and it was already really hard (the X200 without S is way easier) <nckx>rekado: I've never (successfully, ahem) flashed a BIOS. What does hard mean here, exactly? Physically? Fragile? <rekado>the X200s has its BIOS chip on the *bottom* of the main board <rekado>so in order to get anywhere near it you need to disassemble the laptop completely. *Everything* has to be taken apart, including the display bezel. <rekado>this is tricky because you can easily snap off the tiny plastic tabs that hold things together <rekado>some things are held together with tape and putting things back requires patience <rekado>once the mainboard is out there you have to solder 8 wires to a tiny chip <rekado>(it’s an SMD chip with WSON package) <rekado>the other ends of the wires go to the flasher, which also powers the chip while it’s connected to the board, so getting the voltage right is … a matter of luck. <rekado>took us four days to get it right, read out the contents of the chip, and slowly push the Libreboot image onto the chip. <vagrantc>yeah, but it's not like coreboot releases happen more than .... twice a year? :) <rekado>then you put it all back together and hope that it still works. <rekado>you only really need to do this once. <vagrantc>and libreboot hasn't release in... a very long time. <rekado>you can leave the chip unlocked (which is probably not a good idea) so that you can write to it from the OS. <nckx>rekado: If locked, do upgrades to *boot require going through the entire process again? <rekado>I soldered a header to the pins and glued it to the inside of the case so that I could flash it with less effort <rekado>but I never had to flash it again. <quiliro>i am using gsd and epiphany hangs all the time <rekado>I dropped the laptop one too many times and then later the backlight started burning … <rekado>and now I’m stuck with the Librem :-/ <rekado>quiliro: do you have lots of tabs open? <rekado>quiliro: how much memory does your machine have? <rekado>I found that epiphany really likes to use a lot of RAM. <rekado>I’ve got 16GB and epiphany will eventually use all of it :) <jonsger>nckx: don't go for the x240... it's not good. I have experience... <apteryx>modern browsers are RAM black holes. <rekado>so better close tabs and use icecat for big sessions. <quiliro>is that the case for epiphany outside of guix also? <apteryx>quiliro: probably, given that you'd have a similar experience with Icecat. <quiliro>rekado, you mean not to use epiphany but icecat? <quiliro>but i figured epiphany would be better with gnome <rekado>I use both browsers – which is not ideal. Epiphany uses way more RAM than icecat in my case and it makes my fan spin… <nckx>rekado, jonsger: Thanks so much. I've never owned a ThinkPad or *booted machine & feel rather lost amidst all this new old stuff. <rekado>nckx: I don’t want to be too discouraging, but I haven’t found any good recent laptop in my long search. <nckx>I naively thought ‘I'll just check a *boot/me_cleaner wiki and look up the best supported device in my budget’. It… doesn't work like that. <rekado>that’s the reason why I kept lugging around the broken X200S with a burned out backlight for much longer than any sane person would have. <rekado>I’m hoping for good aarch64 laptops to become available in due time. <quiliro>would it be possible to gather 1 million free software activists to put 800 usd each for a medium range laptop which would be all libre hardware specs with schematics and all? <nckx>Yah. What I've learned about ARM laptops is meh, and I'm weary to leave the well-supported x86 platform just yet. <nckx>quiliro: Isn't that what the PineBook 64 is, kind of? (Said without an ounce of source-checking.) <rekado>nckx: that X230… that’s suspiciously cheap. <nckx>Glad (well: superdisappoint) to hear someone say it. <rekado>nckx: well, I don’t know. The price is really good. I see on greenpanda that they sell the refurbished X230 for EUR230 (no coreboot, no Atheros WiFi). <nckx>quiliro: Well, yes, that's why I'm not buying one ;-) But I think that's a realistic — actually, very reasonable — price. <quiliro>nckx: i don't worry too much about capacity but its freedom *nckx *has* 16 gigs of RAM, SSD, and ath9k in a box here, so them being optional from that seller is a) rare and b) nice. <rekado>flashing coreboot + libre-ready wifi — the price on purelab doesn’t seem impossible. <nckx>quiliro: I don't know enough about ARM to know if it's free or good or whatevs. <rekado>quiliro: no comparison. The Purism hardware is in a different league. <nckx>rekado: Which greenpanda? Don't immediately find a laptop seller by that name on DDG. <nckx>Thanks. (Really. Thanks for the hand-holding.) <rekado>they sell refurbished computers. <rekado>I got the X200S from there. There’s a discount code to tell them not to include Windows. <quiliro>but even though purism has laptops which work with free software...the hardware design is not libre...which is what i am looking for <nckx>Sigh. Guess I'll give Mr. Swiss a chance and ask for a binding quote, at least… <rekado>nckx: good luck! I might do the same soon. <nckx>Hey no stealing my stock. <rekado>“soon” in my life currently means “maybe in a year” :-/ <nckx>Interesting Thrace facts™. *nckx requested a quote for an i7 x230, just 'cause. Now we wait. <nckx>apteryx: I'm a lot more enthousiastic about Power (and RISC-V) than ARM, but being a laptop is unfortunately a must. <nckx>(And if a €1300 Librem is out of budget, I'm afraid a €1150 motherboard is too…) *jonsger 1.319,24 EUR wasn't too much for Mainboard+8core+Fan for me :P <nckx>jonsger: Trains in Belgium have 220V sockets, what am I waiting for. <kmicu>shcv: Guix System doesn’t have a stable channel yet. <nckx>That I think Talos is great and not too overpriced, but I really need a laptop. <nckx>Not really :(. I actually like laptops a lot. <kmicu>nckx: I recommend buying a second-hand laptop with the best possible CPU and then compiling what you need to make it work. Not a purly libre path but good for the environment and your pocket. <nckx>kmicu: That's the plan. I've never bought a new laptop. <jonsger>nckx: the nice thing about the Talos is that they have a BMC. So I having the idea to give it a "static" IP over DynDNS and controll it also from remote :) <nckx>The x230 has a very-probably-completely-disabled ME which is good enough for me. That there's an inert binary blob left behind bothers me less than some. <nckx>jonsger: Can it be hard-disabled (not from a trust but from an attack-surface perspective)? <nckx>I'm irrationally sceptical about such out-of-band stuff. *nckx .oO Rationality is a matter of opinion. <jonsger>I think the BMC cannot disabled as it's required for the boot process for the main system. But it's fully open source and I'm sure it's attack surface can be minimized by removing functions... *nckx prefers disabling code over pretending to audit it. ***vagrantc_ is now known as vagrantc
<apteryx>civodul: how can I invalidate memoization cache? <apteryx>I think I just discovered that the second pypi->guix-package test in (tests-pypi) always return the value of the previous pypi->guix-package call (the test before it) ***slyfox_ is now known as slyfox
<pkill9>or it's something wrong with the website <rekado>this URL is wrong. It redirects to a generic page. <pkill9>it's downloading that page when running `guix build armagetron-advanced` <pkill9>ah the name needs to be armagetronad in the url instead of the new package name 'armagetron-advanced' <civodul>you could disable the suspicious memoization bits <bavier>pkill9: which is why nckx has been removing the use of 'name' in source urls <vagrantc>it's almost like someone pushed changes without checking that they build... <nckx>vagrantc: To be fair, it might have worked fine on their machine since Guix doesn't re-download sources if their hash hasn't changed (even when the URL does, i.e. the tarball hash is an input, the URL is not). <civodul>nckx: it does redownload it if the file name changes, though :-) <nckx>Ah, I didn't check the package in question and was thinking about my Perl adventures. <civodul>but yeah, the big rename has been a bit cavalier IMO *vagrantc is really confused about gnu/bootloader/depthcharge.scm only being recognized when run from ./pre-inst-env and not when pulling the commit <rekado>vagrantc: it hasn’t been added to GNU_SYSTEM_MODULES *nckx has gone from ’I should buy a pre-flashed ready-to-use x200’ to looking up flashers and ‘I could buy an x230 tablet off ebay and do it myself’ in… hours. <nckx>This is how weekends are lost. <nckx>rekado: Those at least have full-size big-boy ROM chips... <vagrantc>rekado: but it is added to GNU_SYSTEM_MODULES in gnu/local.mk <vagrantc>entirely open to the possibilitiy of missing something <civodul>vagrantc: if depthcharge.scm is not referenced by any other modules, it may be dismissed by (guix self), the thing that 'guix pull' uses <civodul>i think we should explicitly add (gnu bootloader ...) to *system-modules* there <rekado>“error in finalization thread: Success” ¯\_(ツ)_/¯ 