IRC channel logs


back to list of logs

<daviwil>true, true
<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
<truby>but it's what I do :-)
<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>yeah that's how I'm finding I'm doing things wrong
<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>I haven't tried without
<cornburglar>it is
<truby>oh, well, I don't really know then :P can you share your config.scm on here?
<truby>where's the channels section?
<cornburglar>channels are handled in .config/guix/channels.scm
<truby>ah, sorry, I asked for the wrong thing :-) I meant to ask for channels.scm
<truby>my mistake!
<truby>try just deleting the (commit ""), and the (branch "master")
<truby>for your own 'my-guix
<truby>so it just has the name and the url
<cornburglar>that works, thanks :)
<cornburglar>I guess branches must be added manually?
<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
<cornburglar>now it failed again :/
<truby>(GUIX_PACKAGE_PATH is another option but I understand this is mostly supposed to be superceded by channels)
<jje>guix system reconfigure currently failing at building libparted with the following error: anything i can do?
<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
<Gamayun>Hello guix!
<cornburglar>After creating a channel and running guix pull, I get 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?
<marusich>sneek, later tell montokapro re: it failed because your guix-daemon wasn't using MIPS emulation - enable it with qemu-binfmt-service-type:
<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_>is anyone working on it?
<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_>mashing the keyboard can help
<rekado_>that generates sufficient randomness for the key generation to move forward
<rekado_>it's a bit silly
<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>rekado_: thanks for the hint with the entropy. looks like that was the issue. i added "-device virtio-rng-pci" to the qemu invocation, and that solved the issue. found via this article: also see
<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
<roptat>there's a failing test...
<leoprikler>do people who commit to master not even run guix build locally?
<roptat>they should...
<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
<leoprikler>parted was upraded in 6ad7e357
<jlicht>hey guix!
<refpga>Hello, is there a way to configure guix to use 2 (or more) keyboard layouts which may be switched using a keybinding?
<leoprikler>depends on your programs
<leoprikler>from my experience, the GNOME desktop doesn't care about Guix config at all
<leoprikler>so you have to use GNOME settings
<leoprikler>if you need this in another WM or even in the DM already, you will have to look at the configuration for that
<brendyyn>refpga: yes. for example via setxkbmap
<nixo_>Hello guix!
<nckx>o/ nixo_
<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>I think you want some setup like the following:
<leoprikler>create $GUIX_PROFILE/share/julia/compiled-v$VERSION
<leoprikler>and set some environment variable (e.g. JULIA_COMPILED_PATH) to that directory
<leoprikler>-- not sure what JULIA actually used --
<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?
<nixo_>roptat: exactly
<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
<brendyyn>(not that i'm having a go at anyone)
<roptat>brendyyn, it's fixed now
<leoprikler>I think the solution for that would be something like the pre-inst-env that Guile devs use
<roptat>my git log says one hour ago
<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
<leoprikler>yeah, but you need a way of building them
<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>I think some logical splitting would be better
<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
<nixo_>roptat: fine :) thanks
<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>then again, Guile too reliese on its ccache
<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>jfred: The general solution is to export COLUMNS (possibly to some large value like 9999). I don't know if/how that applies to the daemon though. (See for background and discussion on how to fix this…)
<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_>nckx: OK.
<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?
<leoprikler>I don't think 6GB is large enough for a /home
<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.
<leoprikler>Lemme guess, ~/.emacs?
*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.
<leoprikler>vanilla Emacs sounds like a very weird fetish
<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).
<kaun_>Lets try nomodeset first.
<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
<leoprikler>the binary blobs :)
<truby>aren't the binary blobs optional though?
<leoprikler>if your GPU is old enough, you might get lucky
<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
<leoprikler>with the linux-libre kernel?
<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!
<kaun_>Intel? I guess.
<leoprikler>what about newer Intel? do they still work?
<truby>I guess the choice is between having decent graphics performance and having free software? which is pretty sad.
<leoprikler>truly it is
<leoprikler>at least we have *some* WiFi drivers :)
<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.)
<leoprikler>and so on and so forth
<leoprikler>it really depends on the very specific model
<truby>yeah I see, doesn't seem like the situation will get any better any time soon either I guess :-(
<leoprikler>we need more open hardware projects
<leoprikler>alternatively seize AMD
<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 can't either.
<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_>No idea, its what I read.
<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
<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: Okay, check :]
<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>oh, interesting :-)
<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>(That was about /home.)
<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>truby: scsh is in Guix.
<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>truby: This is also not what you want but the interesting inverse:
<truby> this is pretty much what I was thinking of
<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>truby: Not yet 🙂
<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"
<lifestronaut>Any idea what's going on?
<lifestronaut>Both errors result in a system freeze
<leoprikler>I too get "already registered" messages on boot, but they don't turn into a freeze
<lifestronaut>Pictures of the errors -
<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>it does. I disabled it via grub
<lifestronaut>It was an issue with my Radeon Rx480
<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.
<lifestronaut>"boots quiet" doesn't mean the quiet option is in grub?
<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.
<lifestronaut>nckx: Ahh, gotcha.
<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
<leoprikler>a lot of information does get hidden by "quiet"
<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>Something else brings me here, it looks like Guix (System) manual is still not optimal cuz folks have issues with basic updating
<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: 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>"Press enter to continue."
<leoprikler>oh, so you're using the graphical install?
<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
<leoprikler>you can skip all the partitioning stuff
<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.
<leoprikler>it should be in /mnt/etc
<ixtlan>Oho. Checking.
<leoprikler>basically you have to do [ Networking]
<leoprikler>mount /dev/sdaX /mnt
<ixtlan>True. It is. So I take it the just-almost-built-system resides under mnt right now.
<leoprikler>yes -- you don't even need the mounting
<ixtlan>Ah good. The need for that command confused me a bit.
<leoprikler>that's just if you had restarted it in between ;)
<leoprikler>you can also skip "herd start cow-store /mnt"
<leoprikler>(again, if you restart, you need that as well)
<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>Will do.
<leoprikler>yeah, it's on C-M-F2 :)
<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>but other than that you get the same manual
<leoprikler>(not everyone has a second machine right next to the first)
<ixtlan>It has proven useful in the past :]
<leoprikler>oh, it sure is useful
<leoprikler>that's why I have three
<leoprikler>(insert "a spare for the spare" reference here)
<ixtlan>:) :)
***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.
<leoprikler>no cable, my cards are crap
<leoprikler>s/no cable/no, cable/
<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>I'm pretty sure it's quite specific to my card
<leoprikler>(and yes, this particular one is very weird)
<leoprikler>apparently there is a proprietary driver, that does not get loaded
<leoprikler>but it still works fine without that one
<ixtlan>..huh :]
<leoprikler>it just ends up as a line in /var/log/messages
<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 :]
<ixtlan>Inst cd of the wifi, that is.
<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
<ixtlan>Sounds... awesome?
<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.
<leoprikler>I like to avoid hacks at such a low level
<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>GNOME's Password/Key Manager
<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
<leoprikler>(there = my local clone of guix)
<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
<leoprikler>anyway, that's it for me today
<leoprikler>good night, y'all
<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>you might want to copy some data like /home
<leoprikler>then reconfigure
<leoprikler>older generations should still use the old partition, though