IRC channel logs

<elpogo>anyone ever try to compile static binaries using the guix packaged rust? the internet stays to pass "--target=x86_64-unknown-linux-musl", but that doesn't work on guix

<apteryx>aren't any rust packaged binary static by default?

<elpogo>Not in my experience apteryx . I tried to compile a rust socks proxy named merino, and it produces a binary that links to libc

<elpogo>and libm and libgcc_s

<apteryx>then I don't know; I remember from past failed efforts attempting to build a static rust itself that it needed libgcc for its macros or something

<apteryx>don't we have a musl toolchain in Guix yet?

<apteryx>hm, debbugs seems to be on vacation

<apteryx>15 minutes and no # created for a recent submission

<apteryx>actually, more like 25 minutes

<apteryx>finally processed

<apteryx>rekado: is pankow out of action? https://ci.guix.gnu.org/workers

<apteryx>(hi![0

<apteryx>(err, hi!)

<sham1>Embedding 0 bytes into the message, eh

<amano>How does guix shell collect search paths?

<amano>Does it collect search paths from build system?

<amano>As far as I know, only build system can collect search paths.

<jakef>has anyone got sane-airscan working on guix?

<amano>jakef: If you know how to make it work on arch linux and know how to write guix services, you can make it work on guix.

<amano>Guix is just another linux distribution after all.

<amano>The basic concepts apply to every linux distribution.

<amano>Guix just requires extra knowledge.

<jakef>airscan-discover picks up the scanner via eSCL and WSD, but scanimage and friends don't

<jakef> i tried changing the sane backend with (udev-service-type (list sane-airscan)) but no effect

<jakef>i see Gio struggling with this too recently https://lists.nongnu.org/archive/html/help-guix/2024-08/msg00124.html

<AwesomeAdam54321>amano: Each package defines the search path specifications that it uses, and it's calculated when the package profile is built

<amano>AwesomeAdam54321: Is it calculated by build system?

<AwesomeAdam54321>amano: No, the build environment includes it's own package profile, so the search paths are already defined

<AwesomeAdam54321>for the build system to make use of

<amano>But, python gets its search path from python build system.

<amano>I mean GUIX_PYTHONPATH.

<amano>Where does GUIX_PYTHONPATH come from?

<amano>Where does GUIX_PYTHONPATH come from for guix shell?

<AwesomeAdam54321>amano: GUIX_PYTHONPATH comes from the python package, wherever the python package is installed

<AwesomeAdam54321>whether it be installed in guix shell or installed as the build environment profile

<AwesomeAdam54321>s/as the/in the

<AwesomeAdam54321>Search path specifications are part of the package definition

<amano>But, guix shell some-python-module populates GUIX_PYTHONPATH with more than 10 paths.

<amano>I don't know where they come from.

<amano>Do python packages manually define GUIX_PYTHONPATH? Or, python build system defines it for python packages?

<AwesomeAdam54321>amano: They come from propagated inputs, they're basically implicit packages that are installed alongside the one you included

<amano>I want to write a build system, and GUIX_PYTHONPATH must be set by something. I want to find the secret sauce.

<AwesomeAdam54321>amano: The `python` package defines it, the python-build-system just adds python to the list of inputs

<amano>Python package can somehow make python libraries get GUIX_PYTHONPATH?

<AwesomeAdam54321>The secret sauce is in ./gnu/packages/python.scm

<amano>Very mysterious...

<mange>amano: Have you already read "(guix) Search Paths" in the manual?

<amano>mange: I scanned it a few times.

<mange>Have you read it, or just skimmed it hoping the answers you seek will jump out at you?

<mange>"Scan" is a bit ambiguous to me. :)

<jakef>if you scanned it with airscan i'd like to hear

<amano>I guess if any package in the guix shell profile adds GUIX_PYTHONPATH to search path, all packages in the profile are scanned for the search path?

<amano>Anyway, this looks saner than gentoo's `eselect python` which forces me to choose one python version.

<amano>I mean `eselect ruby`.

<futurile>morning all

<olndrxyz>Hi! I'm getting `guix system: error: unrecognized boot parameters at /var/guix/profiles/system-x-link/parameters` when I run guix system reconfigure. The system suggests to run guix pull but this does not fix the issue. This started to happen yesterday after a roll-back (I got a kernel panic after a system reconfiguration went wrong).

<amano> https://guix.gnu.org/manual/devel/en/html_node/Search-Paths.html says "What this native-search-paths field says is that, when the python package is used, the GUIX_PYTHONPATH environment variable must be defined to include all the lib/python/3.9/site-packages sub-directories encountered in its environment."

<amano>What is environment for search paths?

<amano>The environment isn't clearly defined.

<amano>It also says " When there are several lib/python/3.9/site-packages—this is the case in package build environments—they are all added to GUIX_PYTHONPATH, separated by colons (:)."

<amano>What is build environment?

<efraim>build environment for inside the build container, otherwise 'environment' is effectively a guix profile

<amano>efraim: Where is it documented?

<efraim>i'm not sure, i'll take a look

<amano>Did you mean guix profile is the environment for guix shell?

<efraim>effectively guix shell creates a temporary profile

<amano>Guix shell is supposed to put every relevant package in a temporary profile?

<efraim>the packages you ask for and their propagated dependencies

<amano>I guess that's why libraries tend to require other libraries as propagated inputs and applications require dependencies as inputs or native inputs.

<efraim>if a package links to a library then the library isn't pulled into the environment unless it's added to it, but it still retains its link to that library

<amano>Are search paths used by guix shell and guix install?

<amano>It seems python build system constructs GUIX_PYTHONPATH independently from search paths.

<taeaad>Is there a hashdeep alternative that is already in Guix? It does recursive hashing and hash checks on files.

<taeaad>So Guix already does hash checks, can you just use that? What about other hashes that are not SHA?

<efraim>packages installed by guix install are added to ~/.guix-profile which is in the search path. GUIX_PYTHONPATH basically creates a custom search path for python modules

<efraim>guix hash can use otheralgorithms, looks like it's not documented in guix hash --help

<taeaad>The help doesn't seem to document it, yes. Let me have a look around.

<efraim>looks like it's in (guix openpgp)

<efraim>md5, sha1, rmd160, sha256, sha384, sha512, sha224

<taeaad>Hmm they should add some other ones too, but thanks.

<efraim>it's probably based on what gcrypt (and guile-gcrypt) support

<efraim>oh, looks like it passes it straight to guile-gcrypt

<efraim>/gnu/store/2bmrqh4w9pcgns0pi3wwqasrshpmv8hw-guile-gcrypt-0.4.0/share/guile/site/3.0/gcrypt/hash.scm

<efraim>well now I feel tempted to submit some packages with different hashing algorithms

<taeaad>efraim: That would make me happy.

<jakef>nerd sniped

<amano>It seems search paths are used for guix shell only and build systems create search paths independently of package search paths.

<efraim> https://dpaste.com/6PVPUZ2RL starting at line 87

<taeaad>efraim: Are you adding the ones after the space?

<efraim>I was working on other things, but I do hope to work on it soon™

<taeaad>More hashes are good. But I wouldn't be able to check anything there, unless you give me a notebook, a mountain and a year. Are those already in gcrypt anyway?

<efraim>yeah

<efraim>I have to remember the alternate hash syntax

<amano>Why does guix shell require python for GUIX_PYTHONPATH when I just want python-numpy?

<amano>This is a minor flaw?

<Rutherther>what do you mean a flaw? if you want to be able to import numpy, you have to have it in the pythonpath

<attila_lendvai>it's a surprise for newcomers. it was for me, too.

<amano>I just don't understand why it has to require python when guix shell is already given python-numpy.

<cbaines>amano, what are you expecting to do with just python-numpy without python?

<amano>development.

<amano>REPL

<amano>If I give python-numpy to guix shell, guix shell should pull in python as a dependency.

<amano>It is a dependency.

<cbaines>how so?

<Rutherther>amano: that's how it's given, by pythonpath. It's just how python works, it looks to places that are in pythonpath plus some defaults that don't have sense in Guix

<Rutherther>it's the same thing as the guix shell providing PATH, so that programs like bash see the executables that are in the shell

<cbaines>there aren't dependencies between packages or store items in Guix, just inputs and references

<amano>inputs are dependencies.

<cbaines>inputs are inputs

<cbaines>inputs that are referenced by the outputs are sort of like "dependencies", but it's best to just think about them for what they are

<amano>Where did you learn that?

<mange>I think saying "there aren't dependencies between store items" is a bit pedantic. For instance, "(guix) Invoking guix build" in the manual opens with "the guix build command builds packages or derivations and their dependencies, ...". Things lie "inputs" and "references" are more precise language, but I think it's reasonable to use the word "dependency" as well (accepting the loss of precision).

<mange>In fact, the documentation for inputs, native-inputs, and propagated-inputs in "(guix) package Reference" even says "These fields list dependencies of the package." :P

<cbaines>it's always hard to define a word (e.g. inputs) without just saying, "it's the inputs"

<cbaines>amano, I don't know where I picked up on the details, but there is some information in the manual https://guix.gnu.org/manual/en/html_node/Managing-Software-the-Guix-Way.html and https://guix.gnu.org/manual/en/html_node/Derivations.html give good information on what's going on

<cbaines>python-numpy having a dependency on python can sound sensible, but if you look at the references of the store item (e.g. guix gc --references /gnu/store/zn0ygfklfrhwbj7wj53jqkdn3bkkmwjl-python-numpy-1.23.2), you won't see python

<AwesomeAdam54321>cbaines: Does the guix gc remove inputs of a package if they're not referenced by file path in its output?

<cbaines>that's sort of right, the manual says " References are a subset of the inputs of the derivation; this subset is automatically computed by the build daemon by scanning all the files in the outputs. "

<cbaines>I think guix gc --references is just asking the guix-daemon for it's list of references that it's got recorded

<taeaad>futurile: What do you mean by idempotent configuration?

<rhuijzer>I've locally updated libusb and rebuilt all the dependent packages locally this week. As far as I can see at the moment I didn't introduce new build failures across the board compared to current master

<rhuijzer>Whats the best next step to contribute this update with the removal of core-updates, it requires a massive rebuild (3000+) and as outsider I can't commit a new feature branch or anything.

<rhuijzer>I didn't completely catch the discussion about core-updates on devel

<futurile>taeaad: sorry, did I say that somewhere? I guess where-ever I said it I would mean "can be applied repeatedly with the same result"

<futurile>rhuijzer: see the devel version of the manual, and there was a recent discussion of this on guix-devel where I asked that question. Essentially, the answer is you request for a new branch to be created which will contain your patch(s). Presumably in your cover letter you'd explain that a new branch is needed for this commit due to rebuilding NNN packages.

<taeaad>futurile: https://www.futurile.net/2021/09/26/guix-alternative-to-snap-or-flatpak-on-ubuntu/

<taeaad>I assume what you mean is that "install x; install x" is always idempotent, but I am not entirely sure.

<taeaad>Idempotency can be a subtle thing.

<futurile>taeaad: I mean that it doesn't twiddle bits in the live file system. I'm not sure if "declarative vs imperative" captures it or what. But basically the difference between transactions as a set of links, and a transaction where someone has to write a script where you undo all the things you did before

<futurile>taeaad: really the only way to do a 'transaction' with deb/rpm is to use the filesystem. Maintainers writing scripts that 'rm' stuff they added is a total lost cause.

<taeaad>If you install from manifests, then it is idempotent but I wouldn't call it idempotent necessarily because it is supposed to be idempotent by definition in that case. But perhaps you mean idempotent by definition. If you mean "./run.sh; ./run.sh" I am not sure if I would ever call that idempotent, even if it does the same thing, due to the time of running being different.

<taeaad>Some people call what you describe "side-effect free" but I also don't like that terminology.

<futurile>Yeah, that's probably the better 'meaning'. At the time I was working with a bunch of container people where everything is 'declarative'. And from my perspective that totally misses the point. So that's probably what was in my head.

<taeaad>futurile: But it does twiddle bits in gnu/store though, and that twiddling _is_ idempotent?

<taeaad>If you say that gnu/store on the file system is changed idempotently then I would say it is a good description.

<taeaad>But I am a beginner with Guix.

<futurile>taeaad: well presumbably the 'time' it takes to do that may vary. But the outcome - the structure with a hash that is the same for *all* users

<taeaad>Runtime and start time both.

<futurile>taeaad: so 'as a user' I can use 'guix challenge' to build a package and check it's exactly the same bit-for-bit with the ones on guix's server

<futurile>taeaad: and if I 'revert' a change (go to an earlier generation) as it's links/profile there's no chance of left over 'stuff'.

<taeaad>I think the problem with calling it idempotent is because idempotent generally should by MM = M, whereas here we are actually doing MM^-1 = 1. Though the parallel part (deploy two things that are bit-for-bit the same) is not captured by calling it invertible.

<taeaad>But idempotent can work if you lay out the structure such that it captures MM = M.

<AwesomeAdam54321>futurile: There's a typo in the article, can you change /gnu/guix to /gnu/store ? :)

<taeaad>The part where I would be interested more is describing it in terms of encapsulation + invertibility or idempotency. Or encapsulation + tree reverse traversal. But I am nit picking. The only reason why I am mentioning all this, is that people not going to use Guix I agree need some simple marketing as to why this makes sense. To me the encapsulation with composability.

<taeaad>futurile: The bit-for-bit part, this applies to gnu/store, but does it also apply to memory?

<futurile>taeaad: say a bit more, what are you thinking?

<rhuijzer>futurile: tnx

<taeaad>Well, don't we also have bit-for-bit guarantee on Guix running itself? Does it run as a system service?

<taeaad>In terms of the rest, there is quite a bit to unpack to explain the whole thing properly, to be honest. You need compositionality, associativity, invertibility and then I think your own installation forms a tree that can be reverse transversed. The encapsulation part I think is underrated and should be better marketed :) Because to me it is not even obvious the extent of how this is encapsulated, because you are running it with a

<taeaad>computer system that is also doing other (arbitrary) things. If you encapsulate it twice (e.g. two different deployments) then encapsulate(my_manifests) is idempotent, even though you are saving the result to different computers.

<futurile>I definitely had a much lower understanding of the composition part. The configuration languages/packages all being written in one language - as long as you like that language - wasn't really in my head when I wrote the post you referenced

<futurile>haven't really thought about the encapsulation part

<futurile>I have multiple deploymens so you're right

<taeaad>I don't think what you wrote is incorrect though.

<taeaad>I would probably call it parallel idempotency or something like that, but it really is about isomorphic subtrees.

<taeaad>For example, if you take any set, and you use von Neumann encoding (with the empty set), then sets are exactly equal if they are isomorphic as trees. So equal becomes isomorphic. If you add the encapsulation in some precise way, you could call it idempotent deployment or something like that.

<taeaad>You are just taking something and decoding it until you can't any further. In the context of Guix, I think it boils down to gnu/store being bit-for-bit the same, but it was created by isomorphic trees (the computation steps) on different computers.

<taeaad>Anyway, I am going on a tangent.

<futurile>heh - well as you explore you'd be very welcome to talk through your impressions at Guix Social - actively looking for people to talk 'as learners' !

<taeaad>What is Guix Social?

<futurile>taeaad: https://www.meetup.com/guix-social/ started as guix chat/talks/patch review learning sessions - https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 - really more chat, less patch review I would say ;-)

<taeaad>The one topic I think that would be useful to add to blogs/docs if not there already is how Guix the program runs in memory and interacts with the Linux kernel or system services etc. It is a topic that even in Linux circles becomes murky to me, a la systemd arguments. But rather than the arguments just the low level working.

<amano>Is it possible to put the same package in inputs and native inputs?

<Rutherther>Why don't you try stuff like this yourself? It is really better to get to know a tool

<amano>It really has steep learning curve for people who want to write packages, services, and build systems.

<amano>Casual desktop users may get away with minimal config.

<oriansj>but guix training matters definitely could use improvement.

<cbaines>amano, it's possible and required in some cases to have the same package as an input and native-input

<cbaines>this is most relevant when cross building (e.g. --target) since the input will be the package build for the target system, and the native-input will be the package build for the host system

<amano>I think packages as guile symbols make sense for reproducibility. Gentoo's version solver breaks reproducibility.

<amano>Version solver is non-deterministic.

<amano>Are guix maintainers receptive to package parameters?

<amano>Package parameters == gentoo USE flags

<amano>Package parameters are a set of prescribed package transforms.

<mange>There was GSoC project for it last year: https://guix.gnu.org/en/blog/2023/parameterized-packages-for-gnu-guix/ with https://blog.lispy.tech/parameterized-packages-the-project-completion-update.html about its completion. I don't recall seeing anything about it being merged, though.

<amano>Guix has a lot of things but is actually simpler than gentoo linux under the hood because functional package management avoids entanglement between packages.

<amano>Gentoo linux packages are entangled and require extra tools to resolve package update conflicts.

<amano>mange: The author has been busy with academic work, but he will probably make time this year to submit package parameters to gnu guix.

<amano>Rich hickey said simplicity results from avoiding entanglement between things. Functional package managers avoid entanglement.

<amano>What can I do if I want to compile a debugging version of a library without creating a bunch of packages for dependent packages?

<amano>B depends on A. If I want to compile a debugging version of A, I have to create a new package for B that depends on the new A.

<amano>Perhaps, package parameters can make this possible without creating a new package for A?

<amano>I mean B.

<jmes>Does #guix recommend any VPS services for deploying Guix?

<amano>jmes: I think there are VPS providers that allow you to install any linux distro?

<Rutherther>amano: you will always have to make it a different package in that case. Different inputs imply different package. There is a possibility to override the whole tree with package-mapping, though. But no need for that, as there is a convenient transformation --with-debug-info. Also some packages have debug output (stripped from the library file) which you can add to a shell to get the debugging info

<jmes>amano: Yeah I'm aware of a few. I'm just curious if there are any glowing recommendations or ones to avoid :)

<amano>jmes: Choose VPS providers that don't engage in censorship.

<amano>I don't like your right-wing view. Thus, we are going to cancel your VPS instances.

<amano>Rutherther: package mapping?

<mange>Documented in the manual: (guix) Defining Package Variants

<amano>Okay

<Guest73>hi! I am getting guix shell --check: warning: variable 'OBJCPLUS_INCLUDE_PATH' is missing from shell environment. there was a long thread about PKG_CONFIG_PATH not sure its related..

<Rutherther>Guest73: warnings are shown only if your .bashrc or equivalent for your shell exports some variables. It shouldn't do that, only the profile should do that. If you ensure that, then --pure shells will work well - with a pure environment

<apteryx>jmes: Not an endorsement, but I'm happy with OVH (very low price of a few dollars per month, and unlimited bandwith). Install Guix System on it was a bit of a pain, but should be easier now that the recipe is in the open: https://lists.gnu.org/archive/html/help-guix/2024-08/msg00125.html

<apteryx>basically, you use the rescue environment, which is a Debian I think, and from there you format the main disk and 'guix system init' your config to it.

<apteryx>the virtio_scsi initrd module is required to find the storage drive

<apteryx>I've also shared a post detailing how to setup wireguard as a 'hide my IP' kind of VPN: https://lists.gnu.org/archive/html/help-guix/2024-09/msg00032.html

<apteryx>well, not really good for privacy since the IP of the VPS is static, but my use case was just having an IP of a given country.

<taeaad>I am not sure if I asked this before, are there any of you who use Guix to deploy to AWS instances? I tried looking around but it's bits and pieces.

<jmes>apteryx: Thanks for the tip, that's some good info!

<futurile>I think I've seen people using hertzner and digital ocean

<efraim>I think fixing icedtea@3 for armhf is going to be a bit more involved. then again I got lucky with icedtea@2

<taeaad>futurile: Thanks.

<freakingpenguin>jmes: If a VPS provider lets you upload custom ISOs you can alternatively use Guix to generate said ISO and deploy to that. e.g. https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/rsent/system/digitalocean.scm

<freakingpenguin>Can't customize the file system as thoroughly though.

<podiki>another week and no further progress on subs for mesa-updates, i may just merge it rather than let it get stale

<Rutherther>Why does that happen that there are no subs?

<Rutherther>Or is it just for some archs?

<cbaines>podiki, at least for QA, there's a queue, and mesa-updates isn't at the front yet

<weary-traveler>any elisp package reviewers/mergers around? #73326 could do with some love. trying to clean up my personal channel

<peanuts>"[PATCH] gnu: emacs-htmlize: Update to 1.58." https://issues.guix.gnu.org/73326

<futurile>Rutherther: have you seen this before - https://qa.guix.gnu.org/branch/mesa-updates and on the front page it shows the branches that are queing to merge: https://qa.guix.gnu.org/

<efraim>oh, the last time we updated icedtea-3 was december 2021. I should probably see about doing that rather than fixing armhf

<efraim>oh, icedtea 3.19.0 is the last icedtea3 release

<podiki>cbaines: i see. the oldest merge request i see is from june; any idea if other branches will actually merge soon?

<podiki>i should say that i don't expect any issues, more of a matter of having substitute coverage but arm/aarch take weeks (or more?) to build it seems

<futurile>sometimes the package graph confounds me, I tell it to build python-textual, it starts by building cmake - I'm like, "WTF?! ... argh go get tea"

<kaij>trying to debug a one shot service not working. are herd logs logged somewhere if not explicitly configured? can I manually get the command somehow?

<rekado>apteryx: hi, I'm still on parental leave until November. I'm blissfully unaware of computer things until then.

<Rutherther>kaij the default log is /var/log/messages for system and ~/.local/state/log/shepherd.log for user

<kaij>thank you!

<futurile>rekado: congratulations btw

<Rutherther>As for the command, you could be able to get it from the generated configuration file of shepherd

<rekado>futurile: thanks! Same kid, but new parental leave :)

<sepeth>jmes: Installing guix iso on vultr was easy for me. You just give the iso, and you boot from it and follow the steps like you would to a computer that you phsyically have. It was a breeze after struggling with creating images for other cloud services.

<Hamled>freakingpenguin: have you tried using the built-in digitalocean support with guix deploy?

<tobtoht_>things that are disproportionate time-sinks: macos support, everything related to trezor, cross-platform qr scanning, reading through wallet2 spaghetti, dealing with windows AV false-positives

<Hamled>is macos support something that would be considered for guix?

<podiki>as far as i know it is not possible without a port of glibc?

<podiki>(built with libre tools)

<podiki>so for the guix side (as opposed to building stuff on macos more generally) the issue is having libre compiler and thus able to port/build glibc, if i remember

<Hamled>Makes sense. I had assumed it wasn't much of a priority but I wasn't sure if tobtoht_ was referring to guix in the message about time-sinks

<futurile>the OSX isn't free software, hmm didn't know that - just assumed it was

<futurile>uh the word 'compiler' should be in there somewhere

<podiki> https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00111.html discussion here

<podiki>(7 years ago)

<futurile>ah interesting

<podiki>there's also this, which i haven't tried but looks interesting https://superkamiguru.org/projects/msg.html

<podiki>basically some tools to have guix on a vm on macos

<freakingpenguin>Hamled: I have not. I figure booting from an image is faster than corrupting a Debian instance if/when I want to spin up new droplets.

<Hamled>Fair enough

<futurile>podiki: looks cool (though I don't have a Mac), also who knew that Fedora has a 'forge'

<PotentialUser-41>sooo, I was wondering if someone already attempted to install guix system from a foreign distro (with guix installed on there, obviously)? Since 'herd' is not installed on there, it's not possible to activate the cow-store service... I can also do it the easier way, just pretty curious... (away for an hour in the meantime, but curious for any

<PotentialUser-41>clues)

<PotentialUser-41>Thanks!

<Rutherther>PotentialUser-41: the cow-store service is nothing fancy. It's just an overlay mount. So I don't see why you wouldn't be able to do it elsewhere

<nckx>PotentialUser-41: You don't even need an overlay mount if you're not already running Guix in the ‘live’ environment. You can just use a bind mount since nothing relies on /gnu/store before you run ‘guix system init’. Just don't forget to bind-mount both /gnu/store and /var/guix to the target partition, or your fancy new store will be quite useless when you reboot into it.

<nckx>Actually, since you're not rebooting into the same store, ignore the entire /var bit.

<Rutherther>nckx: what is the reason for overlay in the installer as opposed to a bind mount?

<sepeth>PotentialUser-41: I have a Guix System installed from a debian on another partition. guix on debian I installed was via the script on the manual and not via apt/apt-get though. The latter failed for me for the reasons I can't remember now. Once I got guix, I created partitons etc via following nix guide: https://nixos.org/manual/nixos/stable/#ch-installation then did the steps in this guide in the

<sepeth>section Installing on another drive: https://guix.gnu.org/blog/2019/guix-on-an-arm-board

<sepeth>I didn't need to do 'herd start cow-store /mnt' bit. One mistake that I made caused me some headache was the bootloader section in my config.scm - I was not using the one for EFI. Once I fixed that, I was able to boot but some kernel drivers was missing - so booted debian, copied the output of lsmod and added to my kernel modules (in initrd-modules section), and voila, I was able to boot, and I am

<sepeth>using that Guix happily since then.

<PotentialUser-41>Thank you all! I'm having a look at the overlay and certainly at the arm-board guide!

<PotentialUser-41>The bind mount I'm not sure how to interpret, since if I bind my partition to /gnu/store, will my guix command even work? Since I would assume that `guix system init` needs /gnu/store to be populated, aka not empty because of my bind mount shadowing the contents (haven't tried yet to see if my assumptions hold)

<PotentialUser-41>sepeth: I do have to admit that I'm not yet seeing how this guide even works... I'm running the `guix system init` right now, but the only store filling up with files is the one on my foreign distro, the /gnu/store on the new guix system partition remains empty, which will probably mean that it remains unbootable...

<PotentialUser-41>Anyway, I'll see after the command finishes and use the overlay probably

IRC channel logs

2024-09-26.log