<truby>would be kinda cool if you could teach spacemacs to grab packages (that are available) from guix tho :-) *truby thinks they've found a new project to work on <cornburglar>How do I create a channel for a local git repo? I tried (directory "path") but that did not work <truby>cornburglar: url "file:///path/to/file" works <truby>idk if that's the "correct" way of doing it though <cornburglar>does it need to be a .git file or will the directory work fine? <truby>just the path to the base directory <truby>e.g. if your (my-packages hello) package is in /path/to/folder/my-packages/hello.scm then you can do (url "file:///path/to/folder") <truby>(you also need to run guix pull after making the change to config.scm which wasn't mega clear to me) <cornburglar>and now idk what Git error: unable to parse OID - too short <truby>hmm. the folder might need to be a git repo? <truby>where's the channels section? <truby>ah, sorry, I asked for the wrong thing :-) I meant to ask for channels.scm <truby>try just deleting the (commit ""), and the (branch "master") <truby>so it just has the name and the url <cornburglar>and I did leave the commit empty so that must be an issue <truby>you're welcome :-) you can probably also replace the guix channel with %default-channels unless you're pinning it to a specific commit for a reason <truby>yes, probably asking for a specific branch and commit works but I don't think you need to <cornburglar>Yeah I've been keeping it to a specific commit on purpose <truby>(GUIX_PACKAGE_PATH is another option but I understand this is mostly supposed to be superceded by channels) <Nardos>Hello! I am hoping someone can help. where do I find items that needs to be packaged? I am new to all this, and it feels like I am out of reach with this. <Nardos>never-mind, I found a lead from the chat logs <cornburglar>After creating a channel and running guix pull, I get 0x0.st/zxmF.drv and I have no idea why or where to look to try and fix it, anyone seen this before? <wdkrnls>Hi Guix, how do I turn the /gnu/store/*-disk-image object into an ISO to write to a USB disk? Do I need to redo guix system disk-image with that --file-system-type=iso9660 argument? <wdkrnls>The *file* utility calls it a DOS/MBR boot sector file. <roptat>wdkrnls: you need --file-system-type=iso9660 as you said <leoprikler>cornburglar: what is the folder structure of your overlay? <rekado_>gnome fails to build because a patch doesn't apply to parted <rekado_>same thing that jje reported earlier <roptat>rekado_, also, I couldn't run a system test because of that... <rekado_>I'd like to but I can only use one hand right now... :) <c0c0>I'm booting the Guix installation image in a VM as described in "Installing Guix in a Virtual Machine" in the Guix manual. It seems to get stuck (no visible progress) at "ssh-keygen: generating new host keys". Is that supposed to take really long, or is something going wrong? <rekado_>when it gets stuck it can be due to a lack of entropy <rekado_>that generates sufficient randomness for the key generation to move forward <c0c0>interesting. why is that an issue only in a qemu VM, but not on bare-metal? <rekado_>my guess is that there are fewer sources of entropy in a virtual environment <c0c0>looks like i need to mash the keyboard rather long... <roptat>c0c0, or maybe it hid the login: message, what if you type "Enter"? <c0c0>roptat: nothing, except that it goes moves down a line <c0c0>a note on this in section 3.8 in the guix manual might help other people running into the same issue (it's not a guix issue but a qemu issue, but still helpful) <roptat>rekado_, looks like the patch is from a commit that is already applied in the current version of parted we have, so simply removing the patch should work. I'm testing and will push if it works <leoprikler>do people who commit to master not even run guix build locally? <rekado_>leoprikler: what makes you say that? <rekado_>sometimes problems appear due to branch merges. <leoprikler>rekado_: fair enough, merges would be more difficult to debug <leoprikler>but roptat seems to be debugging a single commit currently <roptat>I don't know if it's from a specific commit <refpga>Hello, is there a way to configure guix to use 2 (or more) keyboard layouts which may be switched using a keybinding? <leoprikler>from my experience, the GNOME desktop doesn't care about Guix config at all <leoprikler>if you need this in another WM or even in the DM already, you will have to look at the configuration for that <nixo_>In the following days, I'm going to push the first batch of julia packages (hundreds of them .-.). Before pushing, I've got a question <nixo_>julia wants to precopile things, so a writable folder is required (usually ~/.julia/compiled/v$VERSION). This works fine, but when instantiating different guix environments the content of this folder contains artifact from the other environment. <nixo_>The question is: is there something like a UUID in the GUIX profile that I can use as compiled folder path? like ~/.julia/compiled/$GUIX_PROFILE/ <nixo_>Or is this solved in some other way in other languages? <roptat>oh, I didn't have time to push my own patch, it's fixed in 20e015733361033667a730e09af94939aef8873a by mbakke <leoprikler>create $GUIX_PROFILE/share/julia/compiled-v$VERSION <leoprikler>and set some environment variable (e.g. JULIA_COMPILED_PATH) to that directory <roptat>that directory is not writable though <leoprikler>Guile and Python both behave that way with their respective PATH variables <nixo_>leoprikler: thanks, but $GUIX_PROFILE is readonly, isn't it? <leoprikler>yes, but you don't need to write to it, if the things are already compiled, do you? <roptat>right, but I think this was for compiled things outside of guix, and I don't think we have a generic solution <roptat>python for instance builds stuff in the current directory, not in a global one <brendyyn>Looks like parted was broken for 15 hours or so mid upgrade <leoprikler>I think the solution for that would be something like the pre-inst-env that Guile devs use <roptat>really, it's not a good idea to mix guix and non-guix packages <brendyyn>I think it is a supported use case though, we can't expect every user to just switch right over to Guix System <nixo_>Btw, is it fine to submit a patch of ~150 commits? <nixo_>I'm using like, 10 julia packages, but with their dependencies I had to package 140 packages for now <leoprikler>For each of the ten packages, put it plus dependencies into one patch <jlicht>leoprikler: I'm not quite sure if that will be accepted <jlicht>at least I have not often seen more than one package per patch being accepted <roptat>yes, one package per patch, and try to not send them all at once <leoprikler>btw. as far as the compilation stuff goes: you can set JULIA_LOAD_PATH and JULIA_DEPOT_PATH, but I've so far not seen anything to set a "compiled" path <nixo_>Yeah I'm already setting them. The "compiled" stuff is inside the first depot_path, along with julia_history and things like that <leoprikler>Guix doesn't deactivate Guile autocompilation, so keeping Julia's as-is should be fine ***benny is now known as Guest93436
<jfred>anyone know offhand if there's a way to expand the strings in a guile backtrace during a package build? I can't quite see what file it's referring to since the path is truncated <jfred>i.e.: `0 (delete-file "/gnu/store/8w285skr915h0i5yg0ky1klj1lzy7j…")` <nckx>(…so, don't hold your breath.) <jfred>hrm... yeah, the daemon being involved throws a wrench into things a bit <kaun_>Hi. Attempting to install guix (replacing my year-old Gentoo install, which had replaced a long-lived Debian installed). <jfred>aha, I was able to get what I was looking for with a (setenv "COLUMNS" "300") in the build phase that was failing <kaun_>Any pointers to installation "troubleshooting" info? I can't see the guided installer in Alt-F1, it looks like an unused terminal. <kaun_>My GPU is not compatible linux-libre. <kaun_>I was hoping vesa would be workable. Any boot flags I can add? <roptat>kaun_, are you sure you're using the latest installer? do you see any error message? <nckx>jfred: Beautiful ;-) Glad it worked though. kaun_: I'm guessing it's an AMD GPU (amdgpu, even)? <jfred>oh yeah it's a huge hack but if it works... :P <kaun_>nckx: yes, and it doesn't sound good that you guessed correctly. <kaun_>roptat: I got 1.0.1 its from May. <roptat>oh, is there a known bug with amdgpu? <roptat>1.0.1 is the latest, so you're good, I was just surprised the graphical installer didn't show up for you <roptat>thought it could be an older image that didn't have the installer yet, maybe <kaun_>roptat: Its one of those APU's with CPU and GPU on the same chip. <nckx>kaun_: AMD is just the worst vendor when it comes to freedom (and in the GPU space that's saying something); I don't know if there's a work-around yet. <kaun_>Needs firmware for max resolution. Maybe it needs firmware to even initialize the video? <efraim>perhaps nomodeset? I forget what the workaround was <kaun_>nckx: I knew it was not all good when I bought the chip (real cheap!). I didn't expect it was this bad. <nckx>kaun_: Try passing nomodeset on the kernel command line (in GRUB). <kaun_>While I ponder my hardware fate, has anybody tried to have partitions on the free space in the installation media? <nckx>kaun_: I don't blame you. AFAICT AMD has been waging a very successful disinf^Wprop^Wpromo campaign to paint their proprietary drivers as ‘open’. It's become a meme: AMD works with free drivers (nope). <kaun_>I have 6+GB of free space, and it would be nice to use it to keep my Gentoo /home. ***benny_ is now known as benny
<kaun_>ISO image resizing, or can something be done to the installation drive itself? <kaun_>nckx: Yeah, it is terrible that even GPU initialization and 2D needs a firmware blob. <nckx>kaun_: You can't resize an ISO, but the installer uses a well-known hack to provide both an ISO file system and a GPT partition table. You should be able to edit the GPT table without breaking things, but I can't speak from experience. <kaun_>leoprikler: Ha ha! I only want to keep part of it handy. *nckx .oO 6 *GiB* not enough for a live medium's home? Me old. <kaun_>nckx: I can gain that experience ;-) isn't that what making mistakes is called? <kaun_>leoprikler: nah, I am one of those mythical creatures that use vannila Emacs. <kaun_>nckx: it is not for a live home, just convenience (its there, so make it useful). <leoprikler>nckx: a live medium's home is like a vacant house <nckx>kaun_: I've even (ab)used the EFI partition for that. 100 MiB of unused space? Criminal. <kaun_>leoprikler: I've "lived in Emacs" for 15 years, and the default packages and key bindings are enough (at work, I do customize). <nckx>kaun_: Dunno your Guix-fu, but VT switching with C-M-Fx will probably still work & you can then install Guix manual-ly. If that's your thing. ***benny is now known as Guest81021
***Guest81021 is now known as benny
<kaun_>nckx: I can muck around like that (that's how I realized I can't do an mkfs on the free space and copy the old /home in the installer session). It is concerning that that installer didn't even become visible. <nckx>kaun_: Absolutely… help really is welcome. <nckx>ThinkPad groupthink is real™. <truby>nckx: what's not open about the amdgpu driver? not doubting you just curious <truby>aren't the binary blobs optional though? <truby>(I don't have an amd gpu so this is purely academic to me, but I had bought in to the disinf^Wprop^Wpromo campaign that nckx mentioned) <truby>I thought there was a fully opensource amdgpu driver and then some binary blob amdgpu-pro thing that implemented "better" (read: worse) support for vulkan and opengl? <leoprikler>Oh, I too thought AMD GPUs would work with free software <kaun_>truby: the open source radeon and amdgpu drivers don't cover all GPU features. <kaun_>For some features, closed firmware is needed. <truby>hmm I know a few people that play Total War Warhammer 2 without amdgpu-pro so I can't imagine what extra features it adds that you actually need I guess? :-P <kaun_>Older GPU's probably only needed closed firmware for say, hardware accelerated video decode and encode. <truby>aha, no, that might well be the difference <leoprikler>if they use the linux kernel as-is, they already get some blobs for free <truby>yeah, I forgot about that. So, what is the best GPU to have if you want to only use free software? <kaun_>Newer, as in hardware made in the past 5 years, ones need firmware even to initialize the graphics! <truby>I guess the choice is between having decent graphics performance and having free software? which is pretty sad. <nckx>truby: I was out for a sec, but yeah, it's basically that for some chips at least these ‘optional’ features start at… modesetting 😛 And people don't realise this because vanilla Linux (now *that's* a fetish I'll never get) ships blobs by default. <truby>does modesetting require binary blobs necessarily? or just for AMD cards <leoprikler>I have an AMD card, that somehow worked without blob, but very badly <leoprikler>and GDM failed to load appropriate drivers while slim worked <nckx>truby: The 2 should not be related. It's a choice. (Sure, maybe forced by ‘third-party “IP”’ licencing, but still a choice.) <truby>yeah I see, doesn't seem like the situation will get any better any time soon either I guess :-( <truby>the issue is there's a lot of open CPU hardware now right? (SPARC, POWER, RISC-V) but I can't think of a single GPU one <nckx>I'm preaching to the choir here, but… computing going where it's going, that is a very bad thing. <truby>I keep getting this issue: `error: failed to run download program '/home/truby/src/guix/scripts/guix': Permission denied` when trying to run a source checkout :-(. But I can run that script with ./pre-inst-env fine, so it's definitely there and executable <truby>(I just followed the instructions in the manual) <kaun_>The situation apparently is not so bad on ARM, because the NEON instructions make software drivers faster so you don't miss the hardware acceleration much. <kaun_>Of course, the ARM booting situation is apparently bad, no standardization full-on balkanization. <truby>hmm why would NEON make things faster when SSE wouldn't? <truby>AArch64 actually specifies that you should be using UEFI.. it's just nobody listens :-( <kaun_>OK, nomodeset, video=vesa, both don't work with either VGA or HDMI. <truby>is there a way to use guix packages from a source checkout without using the guix from that source checkout? (since I can't get that to run) <kaun_>Off to commit blasphemy (probably Devuan). I hope to be back soon as a user-land Guix user. <nckx>kaun_: Oh. Pity ☹ See you soon! <kaun_>I have an older Macbook with an older GPU, I have hopes of GuixSD working on that. <truby>I was going to try and version bump texlive, although having looked at the file it looks like a lot more effort than I had anticipated :-) <kaun_>nckx: yep, pity. But I can't throw away otherwise good hardware. The only way to libre on this is as a headless node on WiFi (even the bloody Ethernet needs a nlib, which I never installed). <nckx>truby: I've never encountered your problem before. Consider a bug report? *truby goes to look for the bug reporting process <ixtlan>Hello all. I'm trying to install the full guix system on a pc but there's a problem.. somehow. Specifically, when "populating '/mnt'", it bails with an error and claims 'You have a memory leak (not released memory pool)'. <nckx>truby: It's quite simple: just send an e-mail (with as much info as is reasonable; hopefully slightly more than ‘Permission denied’) to bug-guix at gnu.org. <truby>well... I've changed nothing and now it works. Despite not working the many times I tried yesterday and so far today. Spooky :-) <truby>ah. Ok, it's because I used guix download to donwload that package outside the pre-inst-env. It's back now :-) <nckx>ixtlan: My last message to truby applies to you too, if nobody here responds. <nckx>Sunday is weird-ass bugs I've never seen before day. <nckx>ixtlan: Is it reproducible? <ixtlan>nckx: It is. First time around I did it twice, then went travelling, had media issues at first but then ended up with the same error as before. I tried downloading again from the site just in case, but it appears to be the same image as before. <nckx>truby: The downloader will fail to run if your daemon is running everything as root (so without --build-users-group=) but a) it's unlikely you're doing that and b) I think it gives a better error message in that case. <nckx>truby: Other, slightly better, random idea: are you running this on a ‘foreign’ distribution that has some kind of advanced access control like SELinux? <truby>nckx: I'm on a foreign distro, I haven't turned on SELinux and I doubt Arch turns it on by default but I can check <nckx>ixtlan: Huh. Interesting (which is not what you want to hear as a user, sorry 😛). <nckx>truby: Nah, I doubt it too. <truby>yeah SELinux isn't even officially supported by Arch heh <truby>I have another small but fun bug, if I ctrl-C something inside a guix environment it kills that program, then the environment, then the shell I called the environment from :-) <truby>I have no idea how that even happens <ixtlan>nckx: Well *shrugs* 'Interesting' is a fine answer inasmuch that it tells me that a) It's not a common problem and b) I am not hilariously stupid for having forgotten something obvious :] <bdju>09:51:47 < truby> the issue is there's a lot of open CPU hardware now right? (SPARC, POWER, RISC-V) but I can't think of a single GPU one <truby>not sure I can see how RISC-V would translate well to GPUs though <truby>then again I know very little about actual hardware, I just write compilers :-) <nckx>There is no ‘just’ in that sentence. <nckx>truby: Does this happen with something trivial like ‘sleep 1h’ in an environment shell? Because I can't reproduce it. <truby>nckx: I worked it out :-) my home directory was not world readable <truby>so the guixbuild users couldn't get to that file <nckx>truby: Ooh, you're running your daemon from /home? Of course. <nckx>I run Guix from ~/guix all the time (drwx------ /home/nckx), but not the daemon. <bdju>I think GPUs are just very specialized CPUs, but I am not confident in this thought. I would say amd and nvidia offerings are probably using something not that different for their stuff <truby>yeah, that's where I did my source checkout. Might be worth adding in the guide that the source checkout needs to be somewhere that the guixbuild users can get to? It seems obvious to me now that I think about it <truby>bdju: the architectures are quite different, Intel tried to make an x86 GPU and it failed horribly :-). But, RISC-V might be more flexible enough than x86 that it could work <bdju>well, I wouldn't expect x86 bits, maybe arm or mips or something. the sort of stuff you see in embedded devices like routers and TVs <truby>I suspect that my other bug (the one where ctrl-c kills everything) is probably related to the fact that I'm using fish <nckx>truby: I agree. Wanna bug report that…? 🙂 <nckx>No opinion on fish, I used it once as a novelty but never since. <truby>bash syntax just makes me shiver :-) I want to play around with a shell that uses scheme as its language... I know there's a racket one floating around <nckx>TIL you can have (version "") and (commit version) and everything will just work (presumably checking out master). <nckx>An R⁵RS Scheme shell. Never tried it. <truby>oo fun :-) I looked at it though and it seems rather dead <nckx>Hm, maybe that's not what you mean after all. What would a *usable* Scheme shell even look like? <nckx>Ah, cool. That's what I was imagining too (a syntax reader or whatever it's called). <truby>Yeah, I don't know if you've used racket but it can do some crazy things with those <truby>There's one (I don't think it's still in development) where you can use python's syntax and even call into python libraries <nckx>There seems to be a pattern of Racket beguiling Schemers so it'll probably happen yet. <truby>It's a lot of fun. I enjoy typed racket a lot because I have real issues getting my head around dynamic typing, it's the only thing I don't like about most lisps <lifestronaut>Are there any known issues with being unable to boot the install USB? <lifestronaut>I get an error stating "Error: Driver 'pcspkr' is already registered, aborting..." <lifestronaut>When I try to disable modprobe from finding/loading pcspkr via grub "modprobe.blacklist=pcspkr", I get a new error - "no sender credentials received, message ignored" <leoprikler>I too get "already registered" messages on boot, but they don't turn into a freeze <leoprikler>It's likely, that the freeze is later, but you don't get any message for that <leoprikler>does anyone know, whether the installation image boots quiet? <lifestronaut>I added "modprobe.blacklist=amdgpu" to the grub line and I got to the install screen <nckx>leoprikler: It very much does not. <nckx>truby: ☝ another thing you could try. <truby>nckx: not sure if you meant to ping me or someone else here? I don't have an AMD gpu :-) <nckx>Oh memory. You're right. It was kaun_, who has left us. <nckx>lifestronaut: I mean that it prints a lot of info to the screen while booting and doesn't put up a splash screen or anything. <nckx>Maybe the intention (and kernel argument) is there, but it's not quiet in practice 🙂 <leoprikler>nckx: "no splash screen" is far from "not quiet" tho <ixtlan>Hopefully an easy question - Which log file(s) should I attach to a bug report? I was unable to find anything that seemed relevant under /var/log. <ixtlan>^-- Sorry about that - The joys of working with two keyboards+computers through a single screen :] <kmicu>AMD is the worst? C’mon, even Mesa folks know that nVidia is the worst ;) <kmicu>(I cannot help too cuz I have no idea what to really recommend.) <leoprikler>ixtlan: depends on the kind of bug you're reporting <nckx>leoprikler: Yes, I know. But I read & answered the question ‘is it quiet?’, not ‘is it booted with the “quiet” command-line parameter?’. The latter is true. <leoprikler>nckx: well, fair enough, my wording was somewhat ambiguous :) <c0c0>probably more of a qemu question than a guix question, but let me ask it anyway. when i try to install guix in a qemu vm, i create an image with "qemu-img create -f qcow2 guixsd.img 50G" as described in the guide. but then the graphical installer doesn't see a disk. when i go for the manual install and run lsblk, i see this: https://paste.debian.net/1106392/ sda is the installation medium, and the <c0c0>rest doesn't look like something were i can install the guix system. any hints on what i'm doing wrong? <ixtlan>leoprikler, it's something that happens during install. I think screen output would be helpful, but I see no log similar to screen output. <leoprikler>ixtlan: Where exactly during install? In the final stage when building everything? <ixtlan>It is after building and applying grafts, during 'Populating /opt': <ixtlan>When "populating '/mnt'", it bails with an error and claims 'You have a memory leak (not released memory pool)'. <ixtlan>Eh. Not /opt, /mnt. Good that copy-paste's memory works. ***wingo_ is now known as wingo
<leoprikler>ixtlan: I'm not sure where this message would end up in <leoprikler>do you get a message afterwards saying "derivation bla failed, check X log"? <ixtlan>"Guix system error: Failed to install bootloader." <ixtlan>"Command failed with exit code 1." <ixtlan>(some specifics left out; it has the filename of said bootloader) <ixtlan>I don't know how to use the manual one. And it seems like it'd require a lot of research to find out. <ixtlan>Even if they/you helped out quite a bit with the info pages. <leoprikler>actually, manual install after a failed graphical one is not /that/ hard <ixtlan>Well.. that would be awesome, but it was non-obvious to me :> <ixtlan>Also the config.scm does not appear to be in /etc. <ixtlan>True. It is. So I take it the just-almost-built-system resides under mnt right now. <ixtlan>Ah good. The need for that command confused me a bit. <leoprikler>that's just if you had restarted it in between ;) <leoprikler>all you really have to do now, though, is "guix system init /mnt/etc/config.scm /mnt" <leoprikler>redirect the standard output and error into some files <ixtlan>Aha. And also, managed to find the guide you are referencing. <ixtlan>So it's the same text..? Okay, I find it much easier to skim through on the web page for some reason. <leoprikler>I'd assume the Website might be a bit fresher than the CD <leoprikler>(not everyone has a second machine right next to the first) <ixtlan>It has proven useful in the past :] ***jonsger1 is now known as jonsger
<ixtlan>leoprikler: That command.. seems to have succeeded. But it was the bootloader install that failed before, I think? *reads manual more closely* <leoprikler>It may just be, that it succeeded by chance on the second try <leoprikler>Grepping for that message, it didn't show up in Guix or Guile, so I have no idea where it would come from <bdju>weston still fails to build (bug report #37682) <ixtlan>leoprikler, this was the fourth try, and the first to use the manual approach where the 3 previous was through the graphical guidance. <leoprikler>I too have more luck with manual than graphical, but there's two reasons for that <ixtlan>The resulting system does seem to work though. It complains over sector size and other things, and passphrase for the encrypted harddisk is asked twice for some reason, and the system is -very- bare-bones since i3 complains it can't find a terminal to use, but.. it seems to work. Just needs some filling in. <leoprikler>1: I inevitably f up in the middle and the graphical system is not nice when restarting <leoprikler>2: networking almost always fails for me through the graphical one <ixtlan>Ah. Which networking, wifi? Fails for me too, I fetched a cable for it. Wifi is still missing, probably. <ixtlan>Arguably the wifi problem for me may be caused either by proprietary drivers or possibly.. missing wifi hardware :] <leoprikler>basically, i have to set up networking manually, but it still won't work for the graphical even if I do that <ixtlan>So even the ethernet cards are unsupported (and/or very weird)? <leoprikler>apparently there is a proprietary driver, that does not get loaded <ixtlan>For this machine (debian) I needed to do sorcerous things with a proprietary driver that the installation cd admittedly -did- provide. I'm somewhat worried over upgrading the system though :] <leoprikler>driver CDs with Linux software? Not *that's* the weirdest fetish we've seen today <ixtlan>In the future, I believe I'll comb the 'supported hardware' much closer with regards to wifi. Naively, I thought that people had worked those things out over the last couple of years :] <leoprikler>Oh, they did -- we have binary blobs in the kernel for WiFi drivers now <leoprikler>that's why most hardware runs "fine" with "normal" Linux <ixtlan>Ah. Now that you mention it. I did need to patch the kernel with something to make things work. With no little trepidation on my part. <ixtlan>But also I'd just bought these wifi dongles and didn't want to spend more money and time before getting the system working. <leoprikler>It's bad enough, that I have to run my local Guix, because Seahorse broke <ixtlan>I might have to get something more compatible this time around though.. I guess guix is not all that proprietary-friendly. Which I do kind of like. As long as I have my current system already running. Mostly I like guix for providing transparency and repeatability. <leoprikler>There is nonguix if you really need the upstream kernel <leoprikler>also you can do custom channels with all the non-free software you like <ixtlan>Ah.. how does lack of gnome's password manager require you to run guix? <leoprikler>I've fixed it there and don't want to copy stuff into my local channel <ixtlan>Nonguix: Check. I'll see how far I can get with the libre though. Principles aside, it tends to be better overall. <leoprikler>my local channel holds other stuff, like emacs-leaf etc. that I'm not sure whether I should contribute <ixtlan>Ok, good night. And thanks for the help. <pinoaffe>what is the recommmended way to move the root partition of a guixsd installation? <leoprikler>pinoaffe: format some spare partition in the way you want, then rewrite /etc/config.scm <leoprikler>older generations should still use the old partition, though