<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)
<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
<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 ._.
<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.
<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?
<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.
<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
<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>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?
<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.
<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>(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 :-/
<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
<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
<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.
<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.