<payphone>So, I have a question, but first some context.
<payphone>When running `guix system reconfigure` I get an error that gst-plugins-base cannot be built. This is due to a bug in the package causing a segfault on i686 systems. The bug has already been reported, but there isn't a fix yet.
<payphone>The problem was found when running through the package's test suite. Would it be a taboo to disable the test suite for this package in this case? And if so, how would I go about doing it?
<payphone>I've tried using a package override with an argument being `#:tests? #f` which will then build fine as my user, but I haven't been able to do the same for `guix system reconfigure`.
<payphone>I tried using `guix system reconfigure -L ~/packages` where ~/packages contains my override, but no dice.
<mange>payphone: If it's just on your machine, I don't think there's any problem disabling tests. I would have expected it to work with the -L flag, but I've never actually tried using it myself. How were you building it as your user?
<mange>I would usually suggest grafting a package that you want, but in this case I don't think that would work (because I think it will still try to build the old version of the package, then the new one).
<mange>But you should be able to do (set! (@ (gnu packages gstreamer) gst-plugins-base) ...) before your operating-system definition. Replace the ... with the (package ...) form that you want it to have.
<mange>I'm sure there's a better way to do this, but I don't have time right now to find it.
<payphone>Ha! That's certainly a hacky way to do it, I'll give it a shot.
<mange>It's pretty much the hackiest way I could think of to do it. :P
<janneke>adding `(setq epa-pinentry-mode 'loopback)' to my .emacs.d/init.el
<jlicht>janneke: NB, I have it working without loopback though
<janneke>the advised `(pinentry-start)' gives a backtrace
<janneke>how can all this silently change...this is *so* uncomfortable
<jlicht>with a 'allow-emacs-pinentry' in ~/.gnupg/gpg-agent.conf, a '(setenv "INSIDE_EMACS" (format "%s,comint" emacs-version)) (pinentry-start)' in my emacs config, and 'emacs-pinentry' in my (guix) profile, everything Just Works for me
<janneke>jlicht: oh, i'm just pasting all this blindly...no idea what loopback etc really means
<janneke>phew...i have a working system again...and with a 4.15 kernel so that i can run i386 images again, to work on the GuixSD bootstrap
<pkill9>i think you can put microsd cards in? not sure
<vagrantc>having recently added support for a handful of arm boards to guixsd... that's pretty much a bare-minimum
<ng0>Guix itself to some limit can already serve as what it spoke out in the original paper. the limits are only reached depending on how far you want to modify it (I should really write about my findings). I think we will never be able to run on *really* small embedded hardware, but these casual devices could get an improvement by somehow getting to less than 512MB RAM compiling
<vagrantc>even guix pull with 2GB of ram would hit swap at times
<minieggs40>a bit confused on the install manual. Specifically for uefi systems, `This partition should be mounted at /boot/efi and must have the esp flag set. E.g., for parted:` This means i should run something similar to `mkdir -p /boot/efi && mount /dev/sda1 /boot/efi` right?
<minieggs40>Or am I misunderstanding that portion and should just run `parted /dev/sda set 1 esp on` /
<g_bor[m]>minieggs40: Actually this should go like that:
<g_bor[m]>1. create a for example 300 MB fat32 partiton using parted, and (give that it is sda1) set esp on on /dev/sda1 using parted.
<g_bor[m]>Then create /boot/efi, and mount /dev/sda1 there.
<minieggs40>Okay, another Q for that then: I run cfdisk and set all my partitions up, I run `parted /dev/sda set 1 esp on`, do I then use the mount command? If I do it now then the next step, `mkfs.fat -F32 /dev/sda1` I'm presented with an error/warning (can't remember exactly what I got but it was something similar to `this has already been mounted`),
<minieggs40>I'm pretty newbie when it comes to all the partitioning w/r/t uefi
<davidl>minieggs40: create /mnt/boot/efi and mount efi partition there during guix system init
<davidl>then after first reboot you need to switch target to just /boot/efi
<davidl>and yes, first create the filesystem before mounting the partition
<davidl>Im not sure it's even possible to mount "a partition" before you have create the filesystem.
<davidl>with "target" I mean, the target that's mentioned in config.scm
<g_bor[m]>minieggs40: opps, yes, I've forgot to add to create the fs before mounting.
<g_bor[m]>You can actually do it using /boot/efi, there is a patch to make it easier to use /mnt/boot/efi, letting you specify the target as /boot/efi, but I guess it didn't make to master yet.
<vagrantc>janneke: if it's basically ./configure && make ... then i might have some hope :)
<j3kyl_>well, time to help yall, translating the manual to my native languge before 1.0
<janneke>vagrantc: yes, that should be it -- and i just added $DESTDIR on my wip-gnu branch
<janneke>if it's more difficult, i consider it a bug :-)
<OriansJ>vagrantc: M2-Planet is a proto-C compiler with support for Structs, unions, inline assembly and enough functionality to build real bootstrap programs, The goal of which is to build mes.c and complete the bootstrap loop from Hex0-monitor to Full GCC
<janneke>vagrantc: there are two ways to build Mes: as a regular package (./configure; make; make install), depending on gcc and such
<janneke>and the other way to build Mes is as part of the bootstrap process
<vagrantc>janneke: well, the former should be pretty straightforward
<janneke>that one much more difficult and would involve bootstrapping people to get involved
<janneke>only in the bootstrapping variant, M2-Planet will be a dependency: M2-Planet is an amazingly small C compiler that will build mes.c -- this is a work in progress
<cehteh>well .. this installation (in a KVM) may be f*cked up, actually i was thinking about testing a fresh 0.15 install from scratch to see how it works, but just stomped on my old test-vm and thought "lets pull and see what happens
<rekado>I guess that’s what happens when you are using Guix through the ~/.config/guix/latest method, but before ~/.config/guix/current is available (i.e. after a pull from before the switch to “current”).
<cehteh>so dont worry too much, might be not reproducible and some local problem here
<rekado>am I correct in the assumption that ~/.config/guix/current does not exist yet?