<Copenhagen_Bram>huh, after half an hour it showed some results. But I can't look at them all because for some reason shift-pgup/pgdown fails to scroll the terminal. And nobody is responding to me on this channel. /r/mildlyinfuriating <cbaines>Copenhagen_Bram, the installer does come with an SSH service you can start (I think) <Copenhagen_Bram>alright, now how do i find out the IP address of the virtual machine? <pkill9>Copenhagen_Bram: have you given it enough RAM? <Copenhagen_Bram>I don't think I specified how much ram. I followed the instructions from the manual <Copenhagen_Bram>Also is it me or has guix restarted the whole process of downloading binaries? Shouldn't it have a cache so it doesn't have to download things again? <cbaines>ip addr might work as a command to find the IP address <pkill9>you generally need to give it atleast 1 gig of RAM <pkill9>it's notoriously RAM hungry for installation <cbaines>pkill9, I'm not sure that's quite correct <cbaines>guix pull requires 1 to 2GB of RAM, but you don't have to run guix pull when installing <cbaines>but generally, you might struggle with 1GB or less <Copenhagen_Bram>also, i don't think it takes much ram to slowly download binaries through my slow internet <cbaines>I thought you were trying the QEMU image anyway Copenhagen_Bram ? <cbaines>Are you trying to install GuixSD from the QEMU image? <cbaines>You mentioned guix system init earlier, which is why I'm asking <Copenhagen_Bram>if you want to know why I'm still at it, it's because my internet runs at at less than a hundred K/s except at midnight to 5, and last night I was too busy looking at the guix manual and learning some basics of emacs/zile to do any installation <cbaines>Ok, what are you installing GuixSD on to? <cbaines>Given you have a working virtual machine, why are you going through the installation process? <Copenhagen_Bram>I even made a luks encrypted partition on it, so now I can finally figure out how to make an encrypted root <Copenhagen_Bram>This practice has shown me that it's probably best to install guixSD at night ._. <Rukako>Copenhagen_Bram: does it ask you for the password two times or once? <Rukako>when I first tried installing guix with luks a year ago it asked for the password once before grub and once after it <Copenhagen_Bram>Rukako: I'd bet the first one unlocked the luks partition and the second one unlocked your account. <Rukako>it was before the login screen actually <Copenhagen_Bram>But since I haven't installed guix yet, it only asks for the password once when I open it with cryptsetup <Rukako>ah, wait, I thought that you used luks on the main parition <Copenhagen_Bram>I'm on guixsd live... I'm trying to install it onto the virtual drive. So I open and mount the encrypted partition to /mnt because it will be the main partition. And then I mount the unencrypted boot partition to /mnt/boot <Copenhagen_Bram>And now I must write a sh script to quickly turn on the network, mount the partitions and start the cow-store service because it seems I'm gonna have to complete the installation at midnight when my internet is faster <Copenhagen_Bram>ACTION realizes he wrote it on the encrypted partition like a dummy so he still has to open and mount it to run the script ._. ***cmd is now known as cd
<axd-v>hey, I have a question about guile. How to get functions like `first, butfirst, etc` to work? I don't know what module to import. First time trying to make something in guile scheme. <axd-v>someone on the #guile channel suggested srfi-1 module and it did bring the `first` function, but not the others, can anyone suggest a way of finding which modules might contain the functions I need to have in my scope? <axd-v>CompanionCube: well guile is an implementation of scheme and not the cannonical standard. I suppose scheme is only whatever RnRS standard specifies and individual implementations choose which version of the standard they implement fully or partially and whatever additions they have that aren't standardized. There are many schemes. <siraben>So I installed the font-liberation package but I don't see it in Libreoffice. <buenouanq>that sounds like one of those things that requires a magic restart <reepca-laptop>hm, attempting to build libreoffice on 0.14.0-11.ab85cf7 has failed twice now for me with an i/o error. <soundtoxin>what's the status on the qutebrowser build failure? <axd-v>soundtoxin: well the version of qutebrowser packaged is like a year old, someone needs to really update the package. Nobody should be using as packaged due to being unpatched and way behind master. <axd-v>I started having problem with the keepassxc package compiling <reepca-laptop>but it only happens when I run "guix package -u", and not when I run "guix build libreoffice" or "guix package -u libreoffice". Really strange. <soundtoxin>it's mainly a secondary browser for me when icecat is giving me trouble, but I have considered switching to qutebrowser full time since it's so nice <vagrantc>axd-v: probably worth filing a bug about it, unless one is already filed... <reepca-laptop>ah, seems I didn't notice an important difference: I set GUIX_PACKAGE_PATH on the one that failed. Oops <axd-v>soundtoxin: it is so nice, but I want it to be more up to date with master. <axd-v>vagrantc: would I send info about it to the mailing list? <axd-v>Question: how would I go about installing an info file to my global one? I downloaded a texinfo file. I found out that the dir for info is located at /run/current-system/profile/share/info/, but I can't add anything there because it's a read-only file system. <reepca-laptop>that's one of the directories it could search, but you can modify INFOPATH to search wherever you want. If you really wanted to be fancy, you could write a package for the info file so that it gets included in your ~/.guix-profile <axd-v>reepca-laptop: I see. So you would suggest for me to create something akin to a .info directory in my $HOME and then include that dir in $INFOPATH? Assuming I don't want to create .guix-profile package at the moment to add it in ~/.guix-profile/share/info as it should be. <axd-v>Is everything in .guix-profile and /run/current-system supposed to be immutable to users and root alike? <axd-v>... unless through guix configuration. <axd-v>reepca-laptop: thank you, that sounds reasonable. <reepca-laptop>makes for really nice rollbacks - just switch a symlink and you're guaranteed to get the old thing (as long as that property holds) <vagrantc>huh. i don't see a section on bug reporting in the guix manual <axd-v>reepca-laptop: the property of immutability? <vagrantc>axd-v: email bug-guix@@gnu.org and include the name of the package and a brief description in the subject, more detailed description in the body <axd-v>vagrantc: got you, will do. I'm recompiling again right now after updating guix, maybe a different day will change something. I've had that mysterous property take place before. <vagrantc>ACTION has been hoping for python-pyqt to get fixed, but hasn't looked too deeply into it <marusich>vagrantc, the maual mentions the bug alias in (guix) Running the Test Suite <marusich>But, that's the only place. We should probably mention it somewhere in (guix) Contributing <marusich>We also mention the alias in the HACKING file in the source tree. <vagrantc>marusich: yeah, i noticed it was mentioned in maybe two places, but yes. <marusich>There is also a contact section in README. <marusich>There is also a contact section in the website, which contains much more information - that seems like the best place, and we should probably mirror its contents elsewhere? <vagrantc>my first inclination is to check the manual whenever i'm trying to do something guix-specific... but maybe others have different ideas <marusich>I check the manual, and if I don't find it, I search the email lists help-guix@ and guix-devel@. The Namazu web search is very useful. <marusich>I don't think the bug-guix@ alias is hidden, really, but if you want to try submitting a patch to clarify it in the manual, I'm sure it would be appreciated. <vagrantc>yeah, it's not hidden, just wasn't where i expected to find it <vagrantc>i'll give a look at the various other text that references and see if i can't write up a brief bug reporting section for the manual ... <marusich>I think that would be great! If you haven't already submitted a patch, it could be an easy way to get started, too. <vagrantc>fairly new to guix, but have a few patches in already :) <soundtoxin>qutebrowser keeps preventing my updates from finishing. can I issue an argument to make it ignore qutebrowser so that I can see an update finish without errors? <marusich>You mean when running "guix package -u"? <soundtoxin>so I use sudo guix pull && sudo guix system reconfigure <soundtoxin>for several days now, it ends in errors related to qutebrowser failing to update <marusich>Ah. Well, there is a --do-not-upgrade option for "guix package", but I don't know of any such option for "guix system". <marusich>Maybe you can get away with removing it from your system profile, installing it into your own profile, and using --do-not-upgrade with your own profile? <marusich>It is possible to install an existing store item into a profile via an invocation like the following: guix package -p test-profile -i /gnu/store/b90y3swxlx3vw2yyacs8cz59b8cbpbw5-guile-2.2.3 <marusich>So, if you can find the store path for qutebrowser that your current system generation refers to, you can install it in your profile with something like "guix package -i $the_path" <marusich>Then you can upgrade all your software except qutebrowser with "guix package -u . --do-not-upgrade qutebrowser" <efraim>Looks like you should check your parentheses <efraim>% will show you the matching parenthesis <efraim>I think we have nvi in the install disk <siraben>Copenhagen_Bram: you need to start the cow herd <siraben>So it writes the packages to disk instead of in RAM <siraben>Copenhagen_Bram: What are you running from? <siraben>How many GB is the destination drive? <siraben>Did you run "herd start cow-store /mnt" <siraben>And have your disk mounted at /mnt before? <Copenhagen_Bram>I've turned on eth0 and made an IP address. Now I open the luks device and mount it at /mnt, and boot at /mnt/boot <mixis>set a password with 'passwd', 'herd start ssh-daemon', and try ssh root@gnu <mixis>you can see the ip with 'ip a' <Copenhagen_Bram>it's a virtual machine, it accesses the internet via eth0 which just feeds it the internet i get from my wifi <mixis>I have a 0.14 live image running right now and it responds to pings <mixis>oh, allright, can you setup port forwarding to the guest? <mixis>which hypervisor are you using? <reepca-laptop>hm, now building vlc on 0.14.0-11.ab85cf7 fails - apparently the "test_modules_keystore" test fails. <mixis>i vaguely remember that there is a way to do it at runtime, too <marusich>Copenhagen_Bram, for port forwarding, try -hostfwd <marusich>The -redir argument, suggested by mixis' link, is deprecated, but it should also still work. <mixis>apparently, there is some key combination to access the 'qemu monitor'. I think qemu informs you about it on startup <mixis>there you should be able to "hostfwd_add tcp::12345-:22" <marusich>for the monitor, you must start qemu with the right option to enable it. <Copenhagen_Bram>well I found the qemu monitor, so what's the right port and ip for ssh? <marusich>For future reference, you can usually look up the port by doing "grep ssh /etc/services" <marusich>The /etc/services file contains a small database of service/port mappings. <marusich>If you redirect a host on the port to the guest, then it's localhost. <marusich>If you redirect a port on the host to the guest, then it's localhost. <marusich>"localhost" can also be written as 127.0.0.1 in IPv4. <marusich>To confirm that the port forwarding is working, try "nc -v localhost 22" <marusich>nc is netcat, you can install it with "guix package -i netcat" <marusich>If you see a message reporting the version of SSH, it means you successfully established a TCP connection to the SSH daemon in the guest. <marusich>(assuming you are not running an SSH daemon on the host...) <Copenhagen_Bram>marusich: if I can get netcat I don't need to SSH, I can use termbin <marusich>What are you trying to do again? I think i missed some of the conversation. <Copenhagen_Bram>marusich: Well, actually... my plan is to use a terminal pastebin, like termbin, to obtain the buggy config.scm on my main system and edit it with good ol' vim, which will highlight the lone parenthesis in red. <marusich>I hope i was able to help. I gotta run for now. Have a good day! <siraben>Right now installing Guix SD feels like installing Arch Linux <Copenhagen_Bram>It really does. There's a slim difference between guix system init /mnt/etc/config.scm /mnt and pacstrap /mnt base <siraben>Hopefully it comes with a GUI interface (calamares?) later <siraben>I'm still not too familiar with the installation process myself. <Copenhagen_Bram>oh man I finally got it to work. It wasn't a parenthese at all, it was a missing quote. And then I had to turn cons into cons* but it's working now. <Copenhagen_Bram>Now it's spamming updating list of substitutes, is it supposed to do that <ngz>This is a (minor) bug, but as civodul explained on the ML, it is difficult to fix. <cbaines>but I think the general answer is, not yet <Copenhagen_Bram>ngz: What is the ML, and can you give me a link to civodul's explanation? <IntoxicatedHippo>If I build a package using --with-input can I force `guix system reconfigure' to use that package? ***jonsger1 is now known as jonsger
<siraben>my other packages can't seem to find the font-hack that I've installed using Guix <siraben>Is there an environment variable I'm supposed to set? <siraben>How do I check the environment variables I need to set? <siraben>And is it correct that I put them in .profile? <pkill9>normally packages define search-paths, but fonts don't <pkill9>that rebuilds the font cache which i think you need to do manually to use newly installed fonts <siraben>I'm trying to load that font into Emac <jeko>all my guile's projects are in ~/.guix-profile/share/guile/site/2.2 and i am wondering how i can add others ? <jeko>I mean without using guix package -i others <jeko>is it ok if I ln -s /path/to/the/other ~/.guix-profile/share/guile/site/2.2/other ? <cbaines>jeko, your profile will be in the store, so adding the symlink won't work <cbaines>how about amending your GUILE_LOAD_PATH to include /path/to/the/other? <jeko>cbaines: yup ok lets try that <janneke>i have a source tarball (gcc-2.6.3) that has everything read-only <janneke>i'm trying things like (add-before 'patch 'chmod ... <janneke>how do i chmod after untar, before patch, do we have an example? <lyr3>hey guys how I get guix to reckon (#!/usr/bin/env bash) scripts? <cbaines>lyr3, are you running these on GuixSD? <lyr3>then I need guix reconfigure? <janneke>ow, crap -- source + patches is built in a separate stage, right? <efraim>I guess you could look at it that way <janneke>efraim: so do we have a way to chmod the unpacked tarball before applying patches? <efraim>janneke does calling chmod work? <janneke>efraim: i'm sure it does, my quest is: when/where to call it <cbaines>janneke, so you have a <origin> with some patches right? <janneke>cbaines: indeed, in fact only one right now <janneke>but the tarball contains read-only source files that need to be patched <cbaines>I had a look at the patch-and-repack function, and I couldn't see anything about permissions <cbaines>also, there is the ability to run some arbitrary code (the snippet), but this is done after the patching... <janneke>so, can i remove (patches ..) from origin and apply them myself after 'unpack? <janneke>ACTION goes to look if (let ((patches ,(search-patches ..)))) works in builder <cbaines>it might be ugly, but if you access patch-and-repack from the (gnu packages) module, you could probably call that twice... along with a <origin> <cbaines>the first with a snippet to change the permissions <cbaines>and the second time with the patches <janneke>i tried to patch frow within the builder, but of course it cannot get at the patch: <janneke>sh: /home/janneke/src/guix-bootstrap/gnu/packages/patches/gcc-boot.patch: No such file or directory <cbaines>maybe you need to add the patch as a native input, and reference it that way? <janneke>it seems noone uses patch-and-repack, cannot find a fitting example of using it twice <Copenhagen_Bram>So, what happens if you've successfully run guix system init to install, but it's not bootable? Do you just fix the config.scm and system init again? Or do you need to system reconfigure or something? <cbaines>janneke, yeah, it's not even exported, this is me really making stuff up <cbaines>Copenhagen_Bram, if it's not bootable, you'll need to init again <janneke>the native-inputs route also is troublesome <janneke>guix build: error: /home/janneke/src/guix-bootstrap/gnu/packages/mes.scm:688:2: package `gcc-boot-2.6.3' has an invalid input: ("patch" ("/home/janneke/src/guix-bootstrap/gnu/packages/patches/gcc-boot.patch")) <cbaines>janneke, wrap it in (local-file ...) perhaps? <Copenhagen_Bram>Do I need an internet connection to init a second time, or will it use files that are already there? <nckx>Copenhagen_Bram: You won't if you didn't add any new packages (including implicit ones). <janneke>cbaines: so i now have: (native-inputs `(("patch" ,(local-file (car (search-patches "gcc-boot.patch")))))) <janneke> (let ((patch (assoc-ref %build-inputs "patch"))) <janneke> (system (string-append "patch -p1 < " patch))))) <nckx>It will probably print some failed substitution attempts but that's just an optimisation. <cbaines>janneke, you're welcome :) You might want to file a bug report, just in case someone has a better approach, or perhaps an improvement can be made to the origin to automatically correct the permissions for files being patched perhaps... <nckx>Copenhagen_Bram: Hm. Sorry. What is it? <Copenhagen_Bram>nckx: you said it wouldn't need to download anything again, but it's downloading 'bootstrap-binaries-0' <nckx>Yes yes don't rub it in. I guess ‘guix system init’ simply ignores everything that's already there, which is defensible in retrospect, but highly undesireable in your situation. <nckx>What I'd personally do (and have done) is chroot into the unbootable GuixSD installation and reconfigure (not init) ‘from inside’, but I just missed that part of the conversation. <g_bor[m]>cbaines, janneke : We have a few more places in our code base where these source permission problems come up. One notable place is reset-gzip-timestamps. I was thinking about this for a while... <nckx>If re-downloading everything isn't an option you could try interrupting guix system init, hope that it didn't zero out /var/guix/* yet and try chrooting. <cbaines>That always gets me, I end up normally just deleting the gzip archives as a workaround... <g_bor[m]>I could propose a patch to fix that phase, or to fix the permissions before applying patches, but this kind of problem seems to be coming up regularly. <g_bor[m]>cbaines: A simple one-liner patch can solve that actually, but I've been wondering if simply giving write permission on everything somewhere at the very beginning could work? We always revoke that before writing to the store anyways? <Copenhagen_Bram>nckx: Whoah, there's no /usr/bin and /bin is empty. And when I chroot there's no $PATH, so where do I find the guix executable? <janneke>not sure we need a generic solution [just yet] <nckx>Copenhagen_Bram: That's Guix for you :-) Which shell did you chroot into if /bin is empty? /gnu/store/.../bin/bash directly? <nckx>Weird. Chroot needs to be able to find a shell *from inside* the chroot, usually /bin/sh, but OK, if it works it works. <g_bor[m]>Of course a change like these would trigger a complete rebuild, so must be done on core-updates, and should be accompanied by checking if current chmods can be eliminated from the code base. I'm not sure, that it worth the effort right now... <Copenhagen_Bram>I found guix in /gnu/store, but when I run it it's giving me warnings <nckx>Copenhagen_Bram: Regarding $PATH, you can ‘ls -d /mnt/gnu/store/*-profile/bin’ from outside the chroot (I assume a brand-new installation has only one profile but am not sure) at set $PATH in the chroot accordingly. <janneke>i cheated, and all but...: /gnu/store/73iv4nlh2rlgz1hfdmyajncd1srzm6bg-gcc-boot-2.6.3/bin/gcc <pkill9>use the profile in /var/guix/profiles/system <pkill9>e.g. /bar/guix/profiles/system/profile/bin <nckx>Copenhagen_Bram: Yep. And mount some kernel file systems like /proc and /dev to make it work. <nckx>Seems like you're finding your way pretty easily though, so you might have done that already. <nckx>pkill9: I've had an init-gone-wrong where that directory didn't exist (yet?). <nckx>Copenhagen_Bram: I just (from outside the chroot) bind-mount them: mount -o rbind /dev /mnt/dev, etc. <nckx>(Yes, bind is technically overkill here, I know folks.) <nckx>mount -t devsomethingfs /mnt/dev? <nckx>I bind because I'm lazy and can't ever remember the thingies. <pkill9>oh yeah, that directory would only be made once the init process is complete <Copenhagen_Bram>nckx: Btw, why wouldn't `guix system reconfigure /mnt/etc/config.scm /mnt` work? <nckx>Copenhagen_Bram: Basically, because ‘reconfigure’ assumes it's reconfiguring the currently running system, and can restart services etc. <nckx>I'm not sure if that functionality better belongs in reconfigure or init (I see it more as ‘guix system init --dont-nuke-whats-there’, which might raise purity concerns), but it's a valid point. <nckx>Copenhagen_Bram: Once you're running GuixSD proper it wouldn't have been a problem. <vagrantcish>i've had a number of arm boards where i had to run "guix system init" numerous times to get the right modules in the initrd ... would've been nice to be able to distinguish the generations <nckx>guix would have re-used all installed packages and just tweaked a few settings. It's just that ‘init’ assumes it's a one-way data blast to a new installation and doesn't re-use anything. <nckx>You're absolutely right that this isn't ideal. <nckx>Copenhagen_Bram: guix-devel@gnu.org <Copenhagen_Bram>alright... Should I try guix system init even though it might be messy? <nckx>Or no, bug-guix@gnu.org. <nckx>(The former is more for discussion, the latter for closeable concrete things.) <vagrantcish>on a related note ... when i guix system init, i'm always stuck with guix 0.14.0, and the first "guix pull" is has to redownload and/or rebuild all the inputs for "guix pull" ... would really *love* to be able to copy the whole of /gnu/store, or at the very least all of the available inputs for the system, so the initial "guix pull" on the booted system wouldn't be so slow <nckx>Copenhagen_Bram: If reconfiguring from within the chroot isn't possible (or is too much trouble, which I totally understand), ‘guix system init’ is the fire-and-forget-and-wait option. <vagrantcish>it also seems like --fallback doesn't work with "guix pull" or "guix reconfigure" ... <nckx>I just seem to remember you were on a 50kbps connexion or such painfulness. <nckx>ACTION has a very skewed perspective on things since they mostly install GuixSD to servers with very fat pipes :-/ <nckx>vagrantcish: That would make a nice bug report ;-) <CornBurglar>Trying to install GuixSD, guix system init gives the error "no target of type 'dbus' for service 'network-manager'. Any clue why/how to fix? <Copenhagen_Bram>CornBurglar: Hmmm. Are you installing from a live GuixSD or another live operating system? <nckx>Copenhagen_Bram: ‘guix system init’ is the safe and documented option, and much easier than mucking about with daemons-within-chroots. But I'm sorry it's such a bad fit for your bandwidth situation. <CornBurglar>From the standard installation media, 0.14 x86_64-linux <Copenhagen_Bram>It would be nice if guix had some ways of recycling downloads. If I let guix download a few packages, ctrl-C, then run it again, will it have to download those packages again? <nckx>Copenhagen_Bram: Not if they've been fully downloaded. <Copenhagen_Bram>CornBurglar: I don't think networkmanager is on GuixSD by default. And possibly not dbus either. There are excellent instructions on how to connect to the internet without a network manager in the Guix manual, why don't you try that? <efraim>i think the 0.14 image has wicd, and since then it's switched to network manager <nckx>Copenhagen_Bram: Your re-download troubles at the moment are just shortcomings of the ’installer’ (guix system init) and are handled a lot more sanely once the system is up and running. <CornBurglar>It produces the same error with wpa_supplicant if I comment out the network-manager portion <nckx>Copenhagen_Bram: That said, you'll still be downloading more with Guix than with most other distros because of the purely functional model. It has many advantages but ‘minimal downloading’ ain't one of them. <Copenhagen_Bram>nckx: Ah well, I guess if I want minimal downloading I'll stick to pacman. <vagrantcish>Copenhagen_Bram: a big part that casuses downloads is not assuming that packages built against library version x.y.z can also use x.y.z+1 ... or a compiler version ... or anything else in the toolchain <vagrantcish>so any time anything changes at an earlier part of the toolchain, anything that was built using it has to be re-built and/or re-downloaded <vagrantcish>at least, that's my limited understanding of the crux of the issue <vagrantcish>heh. apparently specifying /dev/disk/by-uuid/ for the /boot/efi partition didn't go so well .. it wants to fsck it, but doesn't have the appropriate fsck available <efraim>i didn't think there was a fsck.fat <vagrantcish>efraim: maybe there isn't ... but it's trying real hard and failing <vagrantcish>so, i've got half-a-dozen systems with guixSD now ... <vagrantcish>they each have small variations in their system config.scm ... how can i make one that sets the defaults, and then include that into another config.scm that just sets the differences ? <pkill9>vagrantcish: you could make the others inherit the main config <pkill9>i assume you can use 'inherit' with system configurations <pkill9>try doing (operating-system (inherit <main-operating-system-config>) (name blah blah ... <pkill9>is it possible to make your own 'build system' for use with the 'build-system' function? perhaps using the trivial-build-system? <vagrantc>pkill9: and they need to live side-by-side or something? <pkill9>so something like (define main-config (operating-system ... <pkill9>then (operating-system (inherit main-config) ... <pkill9>but thinking about it, i don't think you can specify which operating system config to use, so basically `guix system reconfigure` is similar to doing `guix build -f` <vagrantc>ACTION always does "guix system reconfigure /path/to/FOO.scm" <pkill9>yeah, you can only point it to a file, i don't think you can tell it which config to use within that file <pkill9>but you could probably split the configs up into files, as long as you add a use-modules part for the main one <vagrantc>i'll try to blunder through it at some point :) <vagrantc>it'd be kind of cool to have a git repository with config.scm that then defaults to pulling in, say, HOSTNAME.scm ... then i could have them all in one repository <nckx>Copenhagen_Bram: Ouch. I hope you sync'ed before that. Did it boot? <nckx>The new system. Or did you not reboot into GuixSD. <vagrantc>apparently, (device (uuid "F776-908E" 'fat)) is what i needed for /boot/efi <Copenhagen_Bram>...I did guix system init, right? And then it booted, but it couldn't find the device 'guix-root' which is what I thought I had labeled the root partition, or thought guix would use that label to find it <Copenhagen_Bram>Since then I haven't done anything else to it except chroot and mount /dev to /mnt/dev <nckx>@ hard-resetting. Though I guess it doesn't matter if you didn't reinstall after all. <vagrantc>ACTION just realized that grub-efi-bootloader could actually install a new bootloader for each system version in case the bootloader was borked <vagrantc>ACTION wonders how many bootloaders EFI can handle <vagrantc>guixsd basically doesn't support a separate /boot from /gnu/store <vagrantc>it would need to copy the kernel, initrd, etc. into the /boot partition <nckx>vagrantc: Considering the track record of UEFI implementations, the only safe real-world answer is probably ‘exactly one, and it has to be named WINDOWS.EFI’. :-/ <vagrantc>Copenhagen_Bram: it's not technically impossible to implement /boot, but it requires some code that doesn't yet exist. <nckx>Copenhagen_Bram: Unfortunately, /boot won't work. It's not a hard limitiation, but GuixSD's GRUB setup currently loads the kernel + initrd straight from the /gnu/store partition. <nckx>What vagrantc just said. Someone *points away from self* just needs to make it happen. <vagrantc>Copenhagen_Bram: i've used a split /boot on some machines, but i had to manually copy the relevent files over, which is highly error-prone <Copenhagen_Bram>Huh. Would just one partition across the whole drive work, even if it was LUKS encrypted? <Copenhagen_Bram>Also, is GuixSD going to rapidly consume the drive space with versions and rollbacks? <vagrantc>yes, grub can support luks encrypted partitions <nckx>Copenhagen_Bram: Yes! This is what I do. But that in turn means you'll have to enter your LUKS passphrase twice at boot. That's not even a GuixSD limitiation, but a GRUB+Linux one. An unencrypted /boot would solve that. <pkill9>yes to the drive space consumption i mean <vagrantc>(alternately, the initrd could contain a luks key that's used to decrypt the rootfs <pkill9>yep, remove symlinks of /var/guix/profiles/system-<number> <nckx>M-hm. I meant in Guix and ideally Guile. <vagrantc>fwiw, grub is astoundingly slow at decrypting the partition, in my experience ... so if you typo the passphrase, it takes a good long while before it fails <pkill9>also do another `guix system reconfigure` so it reewrites the grub config,so you don't have a bunch of dead system profiles in the grub menu <nckx>It's supposed to be slow, but not slower than Linux. <Copenhagen_Bram>unless someone managed to steal the hard drive and run it through their quantum computer <vagrantc>it is at least an order of magnitude slower on the machines where i have grub decrypting a partition than linux <vagrantc>Copenhagen_Bram: steal the hard-drive and feed it a clock that allows you to brute-force it as fast as you can generate passphrases... <nckx>vagrantc: Maybe Linux uses CPU features like AVX? I don't know. We discussed this on the ML once but no-one really knew enough about GRUB to tell. <vagrantc>nckx: it's not like the hard disk has a built-in clock <vagrantc>nckx: so grub gets it's time from the system somehow ... e.g. "bad passphrase, waiting N seconds till i let you try again" is only as reliable as your clock source <Copenhagen_Bram>vagrantc: hmm, that's great but I'd rather not have to type the password twice and have it take forever. <nckx>vagrantc: No. It's a hard computational limit, not a sleep(n). <vagrantc>Copenhagen_Bram: in my experience, only grub is slow, once it's in linux it's very reasonably fast <nckx>i.e. You'll need a faster computer or many of them to actually increase your chances. <vagrantc>Copenhagen_Bram: and at least with debian or guixsd, it allows you to try again when it fails <vagrantc>nckx: i guess you'd have to replace grub, then :) <vagrantc>or just mount it on a system that uses CPU extensions... <efraim>What about using something like u-boot —> rEFInd -> grub-efi? <Copenhagen_Bram>So if I have one partition, i will have to type the password twice, and slowly. But GuixSD doesn't support a separate /boot partition. <nckx>vagrantc: I'm not an expert on PKBDF2. I'm sure it's possible to accelerate it with ASICs (not sure about CPU extensions) or your friendly neighbourhood NSA datacentre, but the point is they can't just run a modified copy of GRUB with the sleeps commented out. <vagrantc>nckx: i get that ... but somehow linux is able to mount the disk in under a second, and grub takes at least 5 <vagrantc>so clearly grub has some limitation that isn't technically required to access the encrypted data <vagrantc>limitation, or lacking optimization, or whatever <pkill9>is there an ebook reader in guix other than calibre? (since Pyqt is unable to be built atm) <efraim>How much is qtwebkit needed by pyqt's dependants? That's the part that's failing now <pkill9>hmm i think calibre relies on it <pkill9>found a solution: pandoc, although i'm not sure if it's packaged in guix, but they do provide a bundle download <pkill9>does ghc-pandoc provide the pandoc binary? <rekado_>yes, ghc-pandoc provides the library and the executable. <rekado_>efraim: I don’t know how important it is to all packages using pyqt, but I’d bet it’s not used by the majority. <rekado_>so having a buildable pyqt *without* qtwebkit support would still be much better than the current situation. <rekado_>we really need it fixed for matplotlib, which is used by lots of other packages. <civodul>are there initial patches floating around? <vagrantc>is there a list of gpg keys with commit access to guix publicly available? <rekado_>has anyone else tested core-updates yet? <rekado_>I’m getting locale errors on core-updates. <rekado_>GUIX_LOCPATH is set to /run/current-system/locale <rekado_>this contains a directory for 2.27, which is the current version of glibc in core-updates <rekado_>I see this: guile: warning: failed to install locale <rekado_>warning: failed to install locale: Invalid argument <rekado_>I also see a lot of perl noise, which is also locale-related. <pkill9>how stable is the core-updates branch? <rekado_>it is currently “frozen”, so no big changes are pushed to it at the moment. <rekado_>this means that the build farm has some time to build substitutes. <rekado_>it’s just for upgrades that are “expensive”. <rekado_>sometimes these upgrades can have unintended consequences. <rekado_>but at this point I would like to encourage every contributor to test their system with the packages that are on core-updates. <rekado_>if there are no blockers it will be merged into the master branch some time during the next three days. <vagrantc>are there other keys that don't have direct commit access but are considered valid? <rekado_>but I have no statically compiled applications. <kmicu>rekado_: do you have only glibc 2.27 in store (and your active profiles)?