IRC channel logs
2024-05-01.log
back to list of logs
<Kolev>What is the best shebang for Guile scripting? <Kolev>nat-418: That works on System? <nat-418>maybe change for /usr/bin/env guile etc <coyote>another day, another package being built locally on my laptop X( <zilti>Why on earth is it such a PITA to use Flatpaks on Guix? <Lumine>Good night Guix (celebrating a finnish traditional holiday) <Kolev>zilti: It is? Generally, all foreign package managers are not ideal. <zilti>Oh yes it is. I've never seen it be such a broken mess on any other distribution :( <ieure>Flatpaks are horrible, one of the reasons I like Guix is that I pretty much never have to deal with snap/flatpak/appimage nonsense. <Kolev>ieure: I do miss the containerization. <ieure>Kolev, I don't. PITA most of the time. Download something in the browser, it's not in Downloads, try to upload something, you can't, it's not mapped inside the container. Looks like normal program, but fails in all kinds of weird and mysterious ways. Don't care for it one bit. <Kolev>ieure: Insecure systems are often more convenient. That doesn't mean it's good to use them. <ieure>Yes, well, a system so secure it's broken isn't much use. <Kolev>Unix was made in an age where computers couldn't be easily stolen, so the security design of the system did not take that risk into account. Mobile operating systems, on the other hand, did. Laptops are now playing catch-up to mobile OSes, security-wise. <zilti>Mobile operating systems did barely. The main reason they're so locked down is simply vendor lock-in. <bienjensu>Assuming I'm not hacking on the channels I'm using myself, but just on my config, would it be possible to put my guile directories in my profile on the loadpath instead of pointing to external copies I've pulled in? For using geiser/ares with them <bienjensu>In a similar vein, when querying the search paths of an 'empty' profile. Would it be wrong to expect it to return the paths to the guile directories of its channels <bienjensu>it feels as if `guix repl` should pull these into the load path anyway, and I don't think it does (but it does for the guix channel afaict). <freakingpenguin>For now I think if you manually require (gnu packages) it'll make those extra channels in current guix visible. <bienjensu>ok great, this simplifies a lot of configuration for me. Thanks <jakef>hi guix, just checking, are folks aware of the failing build of `/gnu/store/i0dwnijjj17sc9p3a8622cg6ax5yyrhy-guix-1.4.0-18.4c94b9e.drv'? <coyote>I mentioned it didn’t have a substitute but didn’t really bother trying to build it on my puny laptop so I wasn’t aware it’s outright failing <wakyct>are there any other distros run like what they're proposing? <nerthus>what exactly are they proposing, because it doesnt sound Debian-like either :p <wakyct>I saw 'constitutional assembly' and stopped reading the thread ;) <nerthus>seeing they're all Dutch namse its probably gonna get run The Hague style + UN-like verbiage <nerthus>community here means then: do I know you and what have you done for me <wakyct>I wonder what the relative sizes of Guix and NixOS are? users and maintainers. <nerthus>Im gonna do an easy guesstimate and that they're more than twice at least but not as zealous :P <nerthus>mindshare wise it's not that far off from my little bubble tho <nerthus>if you heard about Guix you likely heard about Nix and vice versa with the hangup being Scheme vs their...DSL ig <wakyct>yeah that sounds about right, #nixos is roughly twice the size of #guix <wakyct>I don't know if Nix folks congregate elsewhere <wakyct>I guess they're on Matrix as well? <nat-418>ive been proposing to form a loi 1901 association like guix <wakyct>there are what, 10k registered useres on the Nix forum? Don't know how many are active but there are non-profit clubs with far fewer members than that <nerthus>well ofc, a non profit is usually just 1 person :D <nerthus>a Dutch stichting can be at least, unless you are VOF because then you are obligated to have meetings <nerthus>becoming a 1 man foundation is easy; cheap too but a notary can help you sign for free depending on the goal of that non-profit <nerthus>+ chamber of commerce registration with limited responsibility so it would be weird if there wasnt a stichting alreadt <nerthus>ye they have one, would be stupid not to <bienjensu>links to the wiki pages of 'constituent assembly' and 'institutions'.. <nerthus>how is that gonna work with a Stichting tho lel <nerthus>a few get written down as right to represent nixos and rotated <nerthus>it must be clear to all tho who is not on the board but can make decisions :) though I dunno how much they care internet drama x] <Franciman>Hi, I'm in the following situation. In the repos there is rust-rspotify@0.11.7 <Franciman>but i need rust-rspotify@0.10.0 for packaging spotify-tui. Can i send a patch to add this version of the package? <Franciman>to upstream, or is it better to wait spotify-tui to be updated? <futurile>Franciman: are you sure spotify-tui won't work with rust-rspoity@0.11.7 - sometimes the lib requirements aren't really what they seem <rekado>that's why it doesn't create new evaluations. <Franciman>futurile: if i use a different version, i get an error saying that cargo can't satisfy dependency for rspotify "^0.10.0" <futurile>Franciman: try changing it in the cargo toml file to see if it works - sometimes the developers are a bit over-zealous in their dependencies <Franciman>would it be accepted by upstream if i patched the cargo.toml in this way? <futurile>Franciman: no - but there are examples of this being done in our final package builds <Franciman>ok, so i would keep it in my personal package repo <futurile>Guix would accept a patch where you changed a dependency; I thought you were asking if the upstream (spotify-tui) would accept such a patch <futurile>Yeah there's a few in the cargo files - look for Substitute* <Franciman>ACTION thanks futurile and start singing "looking for a substitution" <Franciman>i wonder whether this is a secure approach, if it compiles it's good to go? <Franciman>don't i risk inserting bugs because of changed semantics? <futurile>Franciman: it's just a library - if the upgrade of the library wasn't due to a security issue (where they should have pulled the crate anyway) then it should be fine - yeah you risk bugs ofc <futurile>Franciman: but "in my experience" Rust developers upgrade a lot - and sometimes it's possible to use a library which reduces the packaging load <Franciman>now i read the changelogs for breaking changes <Franciman>this technique would be suepr helpful for texlab, where i have to update around 50 rust crates :P <futurile>Franciman: one option when exploring the package is to keep a build (using --keep-failed) then just manually edit the cargo.toml - try and build it by hand <cbaines>the problems with nss seem to apply to all systems apart from riscv64-linux (where the tests are disabled), and aarch64-linux <Franciman>but in the build process it doesn't perform the substitution <cbaines>Franciman, that snippet isn't for the build process, it's being applied directly to the package source <cbaines>but the package source is a .tar.gz file? <cbaines>at least that's what the file-name bit suggests <cbaines>this kind of change should generally happen as part of the build process, you can search for "add-after 'unpack" to find similar examples <Franciman>I don't understand, tho. In the guix packages there are some packages doing the substitution in the snippet, even if they download the tar.gz as i do <futurile>Franciman: you can do alterations in two places, snippets or phases - you can find examples of both I guess <cbaines>Franciman, can you share an example of that? <yelninei>i think the problem is that if you have already the source locally and then add/change a snippet it is not rebuild. <cbaines>Franciman, I suspect that snippet doesn't do anything <cbaines>Franciman, actually, I think it might work, but only because the package is being patched <cbaines>see the patches bit in the origin record <Franciman>i tried locally, on my package and the substitution* worked <cbaines>applying a patch requires unpacking the source tarball, then repacking it <Franciman>cbaines: the docs say that the snippet G-exp is executed in the source directory <futurile>yelninei: oh that's interesting - didn't know that - so if you have the source in your local Store (and no patches), and you add a snippet it won't know to apply the snippet because it's "got that derivation" already? <cbaines>Franciman, hmm, yes, it looks like it will still unpack and repack if there's just a snippet <cbaines>under the hood this is pretty complex because it's actually generating an additional derivation <yelninei>futurile: I think so. At least taht would explain why the snippet was not working for Franciman <cbaines>yelninei, futurile the snippet isn't applied in the fixed output derivation, so I don't think this is correct <Franciman>probably i don't know the content of the crate <civodul>to cbaines & whom it may concern: okay if i remove nss-certs from all the configs in maintenance.git? <sneek>civodul, you have 1 message! <civodul>alternatively i remove it for berlin only <yelninei>i had something similiar occuring with snippets before. Let me check that. <cbaines>civodul, it's fine with me if you want to remove it from more/all configs <cbaines>does having nss-certs twice in the list break things? <civodul>cbaines: from your message, it looks like it does, but that would need investigation <cbaines>civodul, back on the nss issue, I think I've got a patch that'll fix the test failures for nss@3.99 <cbaines>there's a performance test with a threshold of 5 seconds, and we're seeing 5 to 7 seconds on the build farm <cbaines>probably because we're using faketime, which I imagine is slowing things down <civodul>i found the test suite log hard to grasp <civodul>(coudln’t even find the name of the failing test) <cbaines>yeah, the test suite is quite extensive <civodul>“guix graph --path guix nss” is interesting :-) <Franciman>cbaines: yelninei futurile fwiw the snippet is applied <cbaines>civodul, yeah, maybe we need a poppler minimal <civodul>and/or po4a without the texlive dependency <tissevert>I expected it to be a string but I get yelded at when I try to use the return value inside a (string-append …) ^^ <yelninei>Franciman: Maybe that was my issue when I came across that as well. Can't remember now <tissevert>any clue about how to wrap (file-append sway "/bin/sway") inside dbus somehow? I'm trying to configure wlgreet <cbaines>tissevert, file-append relates to gexp's, it returns a record <ehrt74>hello :) how does guix deal with c library paths? i've installed gmp but i don't know where it's been installed to :/ <tissevert>ok, so it can only run within guix-daemon? I tried to #$ it just to see how it'd turn but it didn't do much good either <cbaines>usually you'd be un-gexp'ing file-append, e.g. (string-append #$(file-append sway "/bin/sway") " --foo") <tissevert>ok, that's what I tried, then guix system build cried that it didn't know about "ungexp" <tissevert>I included (guix gexp) in my module of course but to no avail <Franciman>uhm, looks like substitute* works line by line <tissevert>so I guess it must be a problem of "included in my config" vs. "included in the snippet that runs in guix-daemon" <tissevert>I remember facing similar stuff when tweaking the sources of some packages, but I have no idea how I could pull the same stunt in a system declaration <cbaines>tissevert, sounds like you might have been using ungexp outside of gexp. e.g. #$ works inside of #~ <tissevert>so does that mean I can simply #~-wrap anyblock and it will be run by guix daemon? even from within a system declaration? <cbaines>tissevert, nope, think of gexp's as staging code, rather than the guix-daemon running it <tissevert>so far, I still lack the understanding of where gexps are expected, where they can occur. To me they just "happen" :) <cbaines>and more generally gexp's can be used to produce arbitrary text, e.g. config files too <tissevert>I don't know where I read they were related to guix-daemon <tissevert>thank you so much (command #~(#$(file-append sway "/bin/sway"))) does work! So I guess from there I can just write my (string-append <stuff for dbus> <stuff for sway>) <cbaines>#~(#$(file-append sway "/bin/sway")) should be equivalent to (file-append sway "/bin/sway"), but you'll need the extra bits if you want to add arguments and such <tissevert>exactly! thank you so much, you changed the way I view gexps. <ehrt74>mm, i've found the libraries in /gnu/store/<somehash>/... i think that's probably not the best way to include them in the header path <tissevert>ehrt74: no, indeed, usually you use the (guile) object corresponding to the package (typically in another package's `inputs` field) <tissevert>and the full hash is taken care of by guix while building your package or preparing your development environment <yelninei>cbaines, futurile: i think my previous comment was wrong. in my little test the snippet gets applied correctly I guess i also had a bad regex in the susbsitute* when this originally happened to me <ehrt74>mm, i'm making progress. now it can't find linux/limits.h. i installed linux-libre-headers, but this didn't help :/ <ehrt74>i'll just try restarting the vm :) <ehrt74>hurrah! new start and it works :D <tissevert>fun story: actually she didn't need the gexps because (command …) gets execld eventually and hence needs the path to the executable, not a command to run <futurile>oh F - I've just realised I'm going to ahve to explain quasiquote in this blog post - <cries of anguish> <jakef>i appreciate your blog posts futurile! <jakef>waiting for substitutes cause my 8 GB laptop can't build guix ;( <Franciman>i have a desktop with 16gb ram and an i7, running guix <jakef>i'm happy to wait for the farms haha <Franciman>i was doing some guix weather, but apparently only guix is missing <Franciman>(among the packages i have in my home config) <jakef>i can confirm i built it with my 16 GB desktop, so you should be right. maybe close your browser though <Franciman>usually the check phase is more expensive than the build phase lol <Franciman>how to get the sha256 of a git-fetch origin? <apteryx>cbaines: hi! having nss-certs twice in the list of packages for an <operating-system> record was causing reconfigure to fail with a profile conflict error <apteryx>at least when their versions differed, haven't tried the exact same nss-certs object twice (I'd hope they get deduplicated then) <civodul>i restarted ‘guix publish’, it’s not supposed to leak anymore <cbaines>apteryx, when I updated a few machines, reconfigure worked but I had certificate issues with running the nar-herder <civodul>yes, likewise “invalid certificate” errors with Guile-Git and with Git itself <apteryx>civodul: well done w.r.t. guile-lzma leak resolved <civodul>thanks! ‘guix publish’ usage is still unreasonably high, even after a few minutes <civodul>in part that’s because lzlib is memory intensive, especially at high compression levels <civodul>but i hope there’s no other issue lurking here <cbaines>apteryx, looking at berlin, you can see that in system-133, it's missing the ssl directory /var/guix/profiles/system-133-link/profile/etc/ssl/ <cbaines>I haven't checked, but I wonder if that's the system resulting from having nss-certs in %base-packages and the system config <apteryx>civodul: did you use any tool to help pinpoint the leak, or just manual inspection of the source? <apteryx>civodul: moving to zstd only at some point would lower that memory usage (I haven't gotten yet figuring out how to issue a proper deprecation warning for the daemon) <civodul>apteryx: i checked /proc/N/maps and realized that most likely that was C heap, not GC heap, that was growing <civodul>i gdb’d into it just to call GC_get_heap_size to confirm <civodul>and then inspected the guile-lzlib code <civodul>took me a while to find the best strategy to fix it <civodul>fortunately i had a fresh mind, coming back from vacation :-) <civodul>but yes, zstd seems to use much less memory (we do zstd only at guix.bordeaux.inria.fr and it’s all fine) <apteryx>looks like my shepherd is hung up, even 'sudo reboot' doesn't take effect (and reconfigure was leaving me on a "guix system: chargeur d'amorçage correctement installé sur « (/dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde) »" message without returning prompt) <civodul>apteryx: any hints from /var/log/messages? <civodul>it could be that a service’s start/stop method is blocking <civodul>like blocking on a waitpid(2) call or something <civodul>this doesn’t happen when using the standard constructors/destructors, but can always happen in custom code <nikolar>civodul: another way that could happen is if the clock changed <civodul>nikolar: ah yes, there’s still this bug <civodul>less likely in “normal” situations as described here <nikolar>Well I was testing guix in a vm and I can't set the clock without herd getting stuck <civodul>the more polished ‘guix git authenticate’ is in the house! <apteryx>yay, my G80 2007 GPU 3D works again with Linux-Libre 6 <civodul>it was apparently caused by changes on ‘mesa-updates’ <Guest36>how can i build an iso image of gnu guix myself, since ci returns "{"error":"Could not find the requested build product."}"? <apteryx>Guest36: that's an annoying issue. I believe something along the lines of './pre-inst-env guix system image -t iso9660 gnu/system/install.scm <Guest36>apteryx: Ah that is the command i am looking for. thanks <apteryx>it's a script that exists in the built from source guix tree, to use that built guix (although it's not yet installed) <Guest36>Franciman: so it uses the stuff from the git checkout and now from your own system <apteryx>or if you already have guix installed it's fine to use that one as well <apteryx>perhaps 'guix pull' to ensure it's recent <jpoiret>apteryx: one doesn't necessarily need a checkout, just use `-e '(@ (gnu system install) installation-os)` instead of gnu/system/install.scm <apteryx>does someone has (service libvirt-service-type) in their config <Guest36>apteryx Yes, I use the libvirt service <apteryx>what does 'prtstat $(pgrep libvirtd) | grep -i rss' show for you? <apteryx>for me, a whooping 714 MB, which is insane <apteryx>I reported that in #70315, but I'm keen on hearing if others reproduce it <apteryx>it's supposed to use about 20 MiB of resident memory <Guest36> RSS: 21 MB RSS Limit: 18446744073709 MB <apteryx>that's normal... is your store small? I have 1 TiB of stuff probably <apteryx>(strace suggested it was scanning my whole /gnu/store) <apteryx>after starting, while its memory usage grows <Guest36>apteryx is there a smarter way than du -hs /gnu/store? <apteryx>OK! Thanks for checking. I have no VMs running either. <Guest36>"error: failed to load 'gnu/ci.scm': ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <bootloader-configuration>>: record ABI mismatch; recompilation needed" produces by "make -j8", what am I supposed to do? <Guest36>ah nvm. says in the docs in the bottom <user_oreloznog>Hi guix! Last week, I have removed "nss-cets" from %base-packages so the reconfiguration was OK. <user_oreloznog>Was nss-certs not installed any more? Because '$ whereis nss-certs" apparently did not find it. <user_oreloznog>And today I have installed nss-certs by '$ guix install nss-certs'. Do you think it's sufficient? <Guest36>if you have a recent guix system, nss-certs is already included <apteryx>user_oreloznog: hi, 'whereis' would find some command on your PATH <apteryx>nss-certs is just data that gets added to your system profile, i.e. at /run/current-system/profile/etc/ssl/certs <apteryx>it's also linked at /etc/ssl/certs, as this is where some applications, e.g. gnutls, are hard-coded to look for them <mgd>I'm still having no luck with setting enlightenment as a desktop service. xfce, gnome and lxqt work fine. nothing in the logs either <mgd>i've had no luck with setting up enlightenmenmet as a desktop service. xfce, MATE, gnome, exwm and lxqt work fine. nothing in my xorg logs either. is this a known issue? <mgd>i'm not so versed with guix but i reconfigured my system and added enlightenment-desktop-service-type <futurile>mgd: I haven't heard that enlightenment doesn't work - but it's worth checking the user mailing list archive (help-guix), and maybe issues.guix.gnu.org just in case <futurile>mgd: seems odd if you're having success with other ones <mgd>thanks, i'll give that a try <Guest36>make authenticates errors out without finding the guix executable <Guest36>am I not supposed to run it in a guix shell? <podiki>or you can do it outside of guix shell; it needs guix to authenticate <dariqq>hi, is bourdeaux doing something weird with times during builds? My patches for #70460 don't build there for qa due to tests timing out. <PotentialUser-18>Hello. I could really use a hand in installing Guix on my computer. I cannot find a system configuration on the installation media. /etc/configuration/ is empty. <Kolev>PotentialUser-18: I'm guessing you're not using the "graphical" installer? <PotentialUser-18>You are correct. Nor am I using the official ISO. I am using an alternative from the "System Crafters" guy due to "hardware limitations". <PotentialUser-18>However, even when I used the official VM images, the configuration file was not there. <Kolev>PotentialUser-18: I haven't done a manual install before. <PotentialUser-18>Would you happen to know of a configuration file I could use a basis that I could adapt? <PotentialUser-18>There is a small one on the Guix guide, but it seems really minimal. The "System Crafters" installation guide just talks about the configuration file and mentions the UUIDs for the partitions that should be adapted. I'm guessing it will be the target. <PotentialUser-18>However, I'm not sure how to handle the decryption of the root partition. <Guest36>Kolev bender as of bender from Futurama? <podiki>sneek: later tell civodul i fixed spirv-llvm-translator locally by updating to latest version (18.1.0) and making the clang/llvm inputs to v18 as well. libclc and mesa-opencl then <podiki>sneek: later tell civodul so, I'll push the fix, though spriv-llvm-translator and mesa have different llvm versions...at least it all builds, I don't know how to test though <podiki>sneek: later tell civodul oh, and with the guix git authenticate updates perhaps you want to chime in on that guix-devel message I sent about the security concern raised around make authenticate? we can just use guix git authenticate more easily now? <efraim>by popular demand (thats a lie) I'm getting closer to %test-gui-uefi-installed-os working on aarch64-linux <stencilv>Hi -- trying to following instructions in `guix-cookbook` to make a local channel. Created directory `/home/george/foo` containing file `foo.scm`. Then `guix build -L ~/foo foo` succesfully built. Now I made `~/foo` into a git repo via `git init; git add *; git commit -m "initial"`. <stencilv>But then `guix pull` gave me error: `Updating channel 'guix' from Git repository at 'file:///home/george/assets/guix'... <stencilv>guix pull: error: Git error: cannot locate remote-tracking branch 'origin/master' <stencilv>(not very good at formatting in IRC, sorry...) <coyote>might want to use a pastebin for snippets like that :) <stencilv>OK. But basically I was just following exactly what was in the `cookbook` <apteryx>dariqq: could be using lesser/more heavily loaded hardware <stencilv>(well, simplified a little -- I didn't use (string-append ...) <stencilv>I guess what I'm trying to confirm is whether I really did all that is needed to make a "channel". It is just a git repo, no need for any kind of upstream? <ieure>stencilv, Not sure, looks like maybe the cookbook is out of date? The error you're seeing is Guix running a `git pull', but there aren't remotes configured for your local repo. <stencilv>ah. that is exactly what I was wondering. So can't really have a local repo. (I was just following instructions to learn - no real task at hand, at this point) <dariqq>apteryx: the test fails after the daemon is unable to start in 5 seconds, i guess i could try to increase the timeout and see if that helps <podiki>does the branch have a different name? <podiki>and your error says that it is trying to get channel "guix" from your local channel, so something is wrong <ieure>Oh, maybe Guix is still assuming it's "master," but the Git default has been "main" for a few years now? <podiki>you should paste service your channels file <podiki>that's what i get for trying to help! :-) <podiki>or rather, that's what i get for not reading completely <civodul>podiki: re spirv-llvm-translator, excellent, thank you! <sneek>Welcome back civodul, you have 3 messages! <sneek>civodul, podiki says: i fixed spirv-llvm-translator locally by updating to latest version (18.1.0) and making the clang/llvm inputs to v18 as well. libclc and mesa-opencl then <sneek>civodul, podiki says: so, I'll push the fix, though spriv-llvm-translator and mesa have different llvm versions...at least it all builds, I don't know how to test though <sneek>civodul, podiki says: oh, and with the guix git authenticate updates perhaps you want to chime in on that guix-devel message I sent about the security concern raised around make authenticate? we can just use guix git authenticate more easily now? <rekado>podiki, civodul I've got a fix for spirv-llvm-translator on wip-python-team <podiki>meant to say that libclc and mesa-opencl now build <rekado>it's commit 4b109e8b4a43d91526d5659ecdbeaa7de9163331 <podiki>rekado: whoops, didn't think to check! <civodul>rekado: oh nice; i’ll let you two coordinate to pick the fix of your choice :-) <podiki>do we foresee any issues with difference between llvm-18 and -15 here? i'm not sure what to test, since mesa uses llvm-15 <rekado>(I intended to merge that branch much earlier but I got pulled into ever more upgrades on that branch...) <podiki>my guess, as i said in the commit, is the spirv-headers update that was in mesa-updates (vulkan patch series) <civodul>it looks like spirv-llvm-translator is only used as a CLI, and i suppose LLVM IR is backwards compatible (?) <civodul>now, we could push rekado’s fix on master, since it’s safe <civodul>and have the upgrade in separate patch for qa.guix to check? <podiki>...i had already pushed the update <podiki>i build libclc and mesa-opencl locally and since anything depending on spirv-llvm-translator was already broken... <podiki>so far no new failures on the CI <civodul>yeah, it’s going to be better than the status quo anyway <civodul>that prolly means some rebasing work for rekado :-) <podiki>i'll keep an eye and sorry rekado! <efraim>I wonder if I can make guix weather more verbose. I got 'guix weather: error: #<unspecified>: invalid G-expression input' on aarch64 <civodul>efraim: what arguments did you pass? <efraim>--help doesn't show --verbose as an option <civodul>you could edit weather.scm and remote the with-error-handling wrapper <civodul>we should add a command-line option or something <efraim>huh, it is wrapped with with-error-handling, but not the part defining the package-list. I'll try moving that inside the with-error-handling <rekado>if we could log full errors somewhere out of sight <rekado>and retrieve them upon request after the fact <coyote>i think i'm going to reinstall Guix on my laptop with a bigger disk today <coyote>I originally installed it in a spare 240GB SSD just to try it out <coyote>but I feel like I've tested it enough and I'm ready to commit (plus I want to probably use btrfs) <podiki>depending on what disk is where, might be easier to just use guix system init to install guix on the new disk and skip going through an installer process <podiki>in other words, you format that disk, get the right labels you need for file systems, and then use guix system init with the configuration you want and should be able to boot from that new disk into a configured guix system <coyote>probably not possible on my laptop though since i dont have where to attach the new disk <coyote>could I do that from the installer image? maybe that’s an option <coyote>seems like it's possible, that could be an option <coyote>just realized that's just the normal way, lol <Kolev>coyote: I have two USB SATA connectors. They're awesome. <coyote>I used to have one but I think I lost it sometime while moving :-( <podiki>Yeah, you can boot the installer and just use your config file at the end (making sure to get the right file systems declaration) <Kolev>coyote: I lost the power cable to it while moving. <podiki>For my server that's what I did, just used an external adapter for the hd and then popped it in the machine to boot all ready to go <Kolev>podiki: UUIDs scare me. I usually install with the provided config and then reconfigure with my own config. <ieure>UUIDs are the dog's danglies. <ieure>Linux device topology isn't stable, you're in for an (eventual) bad time if you don't embrace /some/ kind of topology-agnostic device identifier. <podiki>Never had an issue with uuid, just format and use the uuid for the config (I also just use labels too, but I use just a few disks in a stable configuration) <Kolev>I don't know how to get the UUID of a newly-formatted disk. <Kolev>So I wait until it's in my config.scm after a guided install. <sham1>One annoying thing about UUIDs is that certain behaviours change depending on if you use them or not. For example with LUKS devices. you get decryption by the bootloader if you use the UUID, but grub doesn't handle luks2 particularly well, so you have to use device paths (unreliable) for devices you don't want automagically unlocked <ieure>sham1, That's an annoying thing about grub, not about UUIDs (IMO). <coyote>speaking of grub, is keeping /boot in a separate partition a supported layout in guix? <coyote>asking since the default encrypts the entire disk <sham1>Well it's annoying about UUIDs since there's no good way to indicate that a mapped device is needed to be mounted by the initrd but which doesn't need to be mounted by the bootloader <sham1>Of course, the real solution would be fixing GRUB to accept LUKS2 <sham1>coyote: yes. In fact, you can also separate / from /gnu/store <sham1>Where /gnu/store is needed for the actual boot since that's where the kernel resides <coyote>if /gnu/store is needed for boot, does that means i'd need to unlock root anyways on grub? <sham1>You don't need to unlock root if you have / separated from /gnu/store, although you might want to do that. Also, having /gnu/store be on the root partition does make certain things easier, like unlocking your partitions via keyfile <Kolev>efraim: Are you back from vacation? <sham1>Since if you don't do keyfiles, you'll have to type your passphrase twice <Kolev>Other distros only make you type it once. <sham1>Not if you're also unlocking with grub they don't, you'll still have to type it twice <coyote>i see. i'm trying to figure out how to avoid having to type the passphrase twice without needing to partition in a different way but seems like that's not possible <Kolev>How do I do this keyfile thing, and what are the security implications? <coyote>normally in NixOS I'd just keep an unencrypted boot and another partition with the store and etc. encrypted <sham1>If anything, in NixOS it'd make sense to have your /boot encrypted since the kernel and initrd is brought in there <sham1>Which makes encrypting the /nix a lot easier than dealing with /gnu/store. That's a downside IMO <coyote>so it seems there's not really much if a way to avoid typing the passphrase twice without using a keyfile (possibly in an external drive) <sham1>Yeah, you need so do that somehow <sham1>I do wish that the FDE story would be nicer <sham1>Oh well, it's a small matter of programming <coyote>yeah.. well, thanks for the input! i can live with typing the passphrase twice ;-) <sham1>Speaking of the LUKS stuff, there's currently also no way to have the mapped-device use luks with keyfile whilst simultaneously have it be recognised by the bootloader as such <sham1>I know exactly where the problem lies, I'd just have to contribute a fix. Haven't had time yet <coyote>hm, i guess that's still secure enough since the initrd is encrypted <jackhill>you could also copy the kernel and ramdisk outside of the store. Would be super cool if grub did argon2 and could magically generate the write initrd, but we don't live in that world yet :) <jackhill>sham1: yep, but one wouldn't have to deal with it daily. Or am I missing the objection? <sham1>Well the objection above is that "other distros don't make you type the password twice" but they do, unless you setup a keyfile. So there's not really any objection <Kolev>sham1: So Trisquel uses a keyfile? <sham1>The only real objection to the extra-initrd is that you can't really make it work if you have / and /gnu/store separate, since the extra-initrd is relative to the partition where the kernel is, due to how the grub config works <sham1>Kolev: maybe, I haven't looked at how Trisquel handles this <jackhill>there's also some hooks for the bookloader configuration that copy the kernel and initrd out of the store to a different partition, which is what other distros do, but I don't have that documentation as handy (check the maintaince repo because the build farm needs it), and sounds like even more trouble to me