<happy_gnu[m]>basically selinux doesn't allow me to run that command either ***mbowcutt_ is now known as mbowcutt
<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? <payphone>`guix package --install-from-file=gstreamer.scm` <mange>Ah, but I guess that `guix build -L ~/packages gst-plugins-base` builds the wrong one? <mange>Okay, well, I know how to get it to work easily if you're on a git checkout, but given I assume you're not running from a git checkout I'll need a few minutes to check something. <payphone>You're correct in your assumption, I'm not on a git checkout. No worries, thank you for your time. <mange>I don't know what the right solution is, but I can give you a hacky solution that I think will work. <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 <mange>I'd believe that. I assume it depends on gst-plugins-base? <efraim>sneek: later tell civodul your key's authorized now <divansantana_>for the life of me cant get this new dell to boot guixsd via efi <divansantana_>will try legacy/mbr next. Any ideas why the "bios" wouldn't see the hdd as a uefi boot option? Even though install completed successful? <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, efraim says: your key's authorized now <divansantana_>Adding it manually in the "bios" and trying to boot it fails too. <civodul>divansantana_: does /sys/firmware/efi/ exist on your system? <divansantana_>civodul: I booted the iso and yes that dir exists and has contents <divansantana_>I can try switch to mbr and legacy. Though that's a whole new install. And the net here is slow. Quite unsure why it doesn't boot though. <civodul>so i think you have to do a UEFI install, with 'grub-efi-bootloader' <divansantana_>so I boot, decrypt the drive mount all in correct location then run grub-efi-bootloader? <divansantana_>oh I already have this in my scm (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi"))) <divansantana_>ACTION I wonder should that be /mnt/boot/efi for the install? <efraim>wow it takes forever to check all the keys before pushing a new branch to savannah <civodul>divansantana_: i think both work (with and without /mnt) <civodul>efraim: could you run 'guix publish' temporarily on the overdrive? <civodul>turns out offloading is slower than publish/substitute when there are lots of things to build <efraim>civodul: think it'd be a problem to publish on 52522 also? <civodul>wait, actually we're getting to guix-0.15.0.drv <civodul>the aarch64 binary tarball is the last file i'm missing for the release <efraim>civodul: I have it up and running on port 3000 <civodul>efraim: thanks, i don't really need it anymore, but other might try and use it <civodul>for the record, i had qemu-binfmt as a backup <efraim>civodul: hopefully not for long if it works well enough for berlin to offload to it <civodul>but... building GCC for aarch64 on a 24-core x86_64 machine is incredibly slow <civodul>i hope we can solve the IP blacklisting issue with berlin <civodul>incidentally, i hope i can put "my" OverDrive back on-line, too <efraim>vagrant managed to get his overdrive running guixsd, I'd love to switch the ones we have over <efraim>they said it was a simple grub-efi setup <civodul>yeah i saw that, i'd really like to switch <civodul>same for my Olimex A20, though that one is relatively resource-constrained <rekado>happy_gnu[m]: thanks for giving it a try. I don’t understand what you mean by “selinux doesn't allow me to run that command”, though. <rekado>As root you should be able to relabel any file on the system. <rekado>you can use “ls -Zl” on the file to show its labels. <rekado>happy_gnu[m]: if I can find some time today I’ll give this a try on one of the Fedora workstations at work, see how far I get. <rekado>would be nice if we could get this fixed for 0.15.0. <jonsger>rekado: do we have already a release date? <jonsger>rekado: depending on when the release is, I'll test selinux on opensue <civodul>rekado: my bad, we should have synchronized better :-/ <rekado>I was preoccupied and the SELinux stuff has been around for a long time with few people testing it. <roptat>civodul: did we fix the "manual is in French" issue? <civodul>we did have reports when you initially contributed it, though? <civodul>i was naively assuming it just worked <rekado>civodul: yes, but people didn’t get back to me, unfortunately, so it fell by the wayside. <civodul>well hopefully jonsger can take whatever patch is needed in openSuSE, and others will follow suite <roptat>the page should be in French though ;) <civodul>right, but let's consider it transitional :-) <civodul>i think the next step is web site i18n <jonsger>civodul: yes thats no problem :) opensuse uses apparmor per default :( <roptat>ouch, I clicked on a random page and the first thing I saw was a missing word ^^' <rekado>roptat: how did you see… a missing word? <roptat>civodul: by the way, the manual generated by guix pull says "This document describes GNU Guix version 0.0-git)" <civodul>oops i've pushed lots of unrelated tags <civodul>does "git push :TAG" remove the tag? <civodul>i'm afraid we'll get lots of useless messages on guix-commits, sorry about that <snape>civodul: re tags removing: yeah very intuitive syntax :p <janneke>with version-0.15.0 i get a graphical pinentry (pinentry-gtk?), although i have ~/.gpg-agent.conf/gpp-agent.conf: allow-emacs-pinentry <janneke>how do i get my emacs minibuffer pinentry back? <janneke>it's not just a popup-annoyance -- the gtk popup is frozen; it disappears after half a minute or so but i'm unable to do anything that involves gpg-agent atm <janneke>trying to figure-out how to manually inject my password into the agent...why is this so hard? <g_bor2>janneke: couldn't you overwrite your pinentry using pinenty-program in your config file? <janneke>g_bor2: i think i tried everything... <janneke>pinentry-program /home/janneke/.guix-profile/bin/pinentry <janneke>ie, leave it out, use pinentry-tty, pinentry-curses <janneke>either with: prolem with the agent: No pinentry <g_bor2>strange. I'm on a mobile now, so I can't test this... <janneke>or if i specify pinentry-tty or pinentry-curses instead, i get: Invalid IPC response -- <janneke>this is really annoying, i cannot even connect to irc or email from my main machine <rekado>janneke: I have a similar problem (frozen popup), but *only* when following a link to a gpg-encrypted file from within an org-mode buffer. It’s fine when decrypting things on the command line. <rekado>(I did not have this problem before switching to EXWM) <janneke>rekado: hmm, i need to open ~/.authinfo.gpg and do that from within emacs <janneke>i always just entered my passphrase in minibuffer <divansantana_>trying mbr install now, results in grub-install: error: ... modinfo.sh doesn't exist. Please specify --target or --directory <divansantana_>my config.scm has (bootloader (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sda"))) <efraim>how do I push a new branch to savannah? it wants to check all the commits for signatures <efraim>should i push master -> qtupdates and then push qtupdates->qtupdates? <rekado>I cannot reproduce the SELinux problems here. <rekado>the files under /var/guix/profiles are labelled properly. <rekado>a future GSoC / Outreachy project could be to extend Guix with a full SELinux policy framework. <rekado>system services and extensions could be used to label files, define types, specify policy fragments, etc <divansantana_>anyone know what /gnu/store/...-grub-2.02/sbin/grub-install: error: /gnu/store/...-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory means <rekado>the only downside would be that this would probably be a rather boring project, because SELinux is pretty boring technology. <divansantana_>during install this is what it fails with when trying mbr like install... <rekado>divansantana_: this sounds like GRUB thinks that this should be an efi installation. I think I had a similar problem before, but I don’t understand this well enough to help you. <divansantana_>yeah thats what I think I recall ludo saying before when I tried a mbr install on another laptop. There I was fortunate enough to get efi to work there. <rekado>there are people here who understand this much better than I do. I hope they’ll come by and help you debug this. <divansantana_>rekado: thats. Let me try the efi method again and see. thanks <jlicht>Does anyone else use the AR9285 wireless network adapter /w GuixSD, and get only ~1.2mbps speeds at the best of times? <jlicht>or rather, does anyone else use that a card with that chipset, but reach higher speeds ;-) <brendyn>muahaha I got 1 patch in to 0.15 since 0.14 <rekado>jlicht: I have the AR9462. I don’t know about the speeds I get. How do you check that? <jlicht>believe me, you would have noticed <1.2mbps while doing anything worthwile ;). I just ran some several speedtests online, but they have been pretty consistent <rekado>(I do a lot of things while offline…) <jlicht>ah, ok. While doing some normal browsing, I already notice a degradation in the quality of a simple ssh connection to a machine on the same WLAN :/ <janneke>i'm getting really, really frustrated...please bear with me <janneke>i suspect that `pinentry' and emacs-26.1 are incompatible...so i try to revert back to emacs 25.3.1 <rekado>janneke: does SLIM succeed in starting Emacs/EXWM even when .xsession is moved out of the way? <rekado>if it does, then maybe Emacs is started via a service, e.g. some emacs daemon service? <rekado>then you’d have to check that either this service is disabled or modified to use your preferred emacs package variant. ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.15.0 is out! https://gnu.org/s/guix/blog/2018/gnu-guix-and-guixsd-0.15.0-released | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://hpc.guixsd.org'
<janneke>rekado: moving .xsession out of the way breaks the login entirely <rekado>janneke: is emacs running in the background, though? <payphone>mange: Reporting back, I was successfully able to complete a `guix system reconfigure` after making those changes to the system config. Thanks! <janneke>rekado: when i herd stop xorg-server, emacs is not running <janneke>herd start xorg-server tries to start emacs 26.1 but that hangs now <rekado>I don’t know why xorg-server would try to start Emacs. (Is it installed globally and does it provide an xsession file or something?) <janneke>rekado: i'm using (auto-login-session (file-append emacs-exwm "/bin/exwm")) <rekado>this emacs-exwm package is built with the latest version of the “emacs” package, though, no? <rekado>I don’t use bin/exwm; I leave that up to the ~/.xsession file which ends on exec exwm. <janneke>i spent the whole morning to make my exwm-x compatible with 1.8.1, that worked and then came the pinentry issue <janneke>i reverted exmw-x from my user profile to 1.7.2 <rekado>I’m glad we could sort this out! <janneke>and emacs-25.3.1 gives me pinentry in the minibuffer <janneke>not sure if/how to report this as a bug--there seems to be something incompatible in emacs 26.1 wrt pinentry <jlicht>janneke: I have a (afaik) working pintentry + emacs26 <janneke>snape, jlicht, rekado: this fixes it! <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 <happy_gnu[m]>rekado: i kid you not, I can't do it while SELinux is on <rekado>happy_gnu[m]: so after setting SELinux to permissive you were able to relabel the files? <happy_gnu[m]>i agree it is kind of infuriating not being able to run stuff as root <happy_gnu[m]>it starts(of course as selinux is off) then I turn selinux back on <rekado>happy_gnu[m]: “back on” means in permissive mode? <rekado>while debugging this it should be in permissive mode so that we can see messages in the output of sealert <janneke>civodul: i'm *very* impressed with guix pull <civodul>thanks; there's still work to be done, but it's getting better! <janneke>i've done away with the `latest' symlink, just ran guix pull, and just use ./pre-inst-env on specific git branches <rekado>civodul: I can’t remember much interesting activity in the bioinfo area, I’m afraid. <rekado>there have been package updates and additions, but nothing groundbreaking. <civodul>rekado: maybe reproducibility things for the paper? <rekado>happy_gnu[m]: are the files under /var/guix/profiles labeled correctly now (check with ls -lZ)? If so, what messages does sealert report now when running the daemon? <rekado>(Guix 0.15.0 is on the HN front page, 2nd place) <rekado>civodul: reproducibility fixes were applied not to bioinfo packages directly, but to python-build-system and other packages; those affect the reproducibility of bioinfo packages as well. <rekado>(some of these fixes will be obsoleted by the switch to Python 3.7) <civodul>rekado: so, how many bioinfo packages do we really have? :-) <civodul>bio{informatics,conductor}.scm weigh in at 334 packages <rekado>parts of statistics.scm would probably also count. <snape>ACTION didn't have any Cuirass fail since the Guile fix <snape>ACTION got pinentry-emacs to work for the first time too <rekado>good wording for the bioinfo updates; thank you! <pkill9>i don't suppose it's possible to find out the git commit of guix used to build a particular store path? <rekado>happy_gnu[m]: the SELinux stuff has not changed. <rekado>pkill9: no, that’s not possible yet, but I’d very much like to have a tool that hooks into the daemon to collect this information. <rekado>the problem is a bit more difficult than just recording the git commit of Guix, because GUIX_PACKAGE_PATH exists. <jlicht>lol, I just read the manual entry regarding all the CUPS configuration options. Nice one, whoever wrote that part :) <snape>pkill9: Also, store files aren't necessarily linked to Guix git commits, when 'guix pull' isn't used. <pkill9>snape: what i really want is a dependency graph of a given store path <pkill9>basically a software doesn't work since updating it's dependencies, but i only have it's store path <pkill9>so i can't work out which dependency/ies might have been updated <pkill9>but it's very neat that i can still use it like any other software due to guix <rekado>pkill9: you can show the dependencies with “guix gc -R /gnu/store/…-foo” <snape>pkill9: and there is 'guix graph' <pkill9>can `guix graph` take a store path? <civodul>should be "Référence de package", because "package" is part of the API <pkill9>ah neat, i knew about `guix graph` but didn't know it can take a store path <pkill9>and it doesn't say in the help about how to give it a store path <civodul>"guix graph -t references" is probably what you want <janneke>configure: error: A recent Guile-SQLite3 could not be found; please install it <janneke>i said: guix environment guix --ad-hoc guile-sqlite3 <janneke>ACTION tries copying guile-sqlite3 from master to older git branch <janneke>yay, adding a 'bootstrap phase that seems to work! <janneke>i think i "discovered" again that for offloading, guile-ssh needs to be in the /run/current-system/profile/ <janneke>i'm not 100% sure yet, but if this is the case i think this needs to be documented more clearly <janneke>it could also be that having guile-ssh in root profile is good enough <janneke>offload tests such as: ssh offload-box guile -c "'(use-modules (guix))'" <janneke>and ssh offload-box env | grep GUILE_LOAD_PATH <janneke>seem OK, but guix offload test still failed <rekado>janneke: make sure to kill the remote guile process that was started with the wrong GUILE_LOAD_PATH <rekado>also: you may need to add GUILE_LOAD_PATH and GUILE_COMPILED_LOAD_PATH to /etc/environment on the remote. <rekado>using “ssh” as a user can result in some env vars to be set up that are not set up when using guile-ssh. <janneke>we figured this all out for guix on ubuntu--previously it "just worked" for guixsd <rekado>I remember I had to modify /etc/environment on GuixSD when setting up berlin.guixsd.org. <janneke>"we" really should make sure it works ootb, or worst case document it <rekado>yes. I don’t know if this is still required, though. Just thought I’d mention up front that I had problems back then and what the solution was. <janneke>OK--i'm sure it worked ootb with guix-0.13 <pkill9>is anyone gonna test GuixSD on the eoma68? <pkill9>well, the libre tea/etc, to be pedantic lol <vagrantc>i don't think the hardware differs; i think the names were only which OS came with it by default <pkill9>yeah it's just which OS is preinstalled <pkill9>but the card itself is separate from EOMA68 since EOMA68 is a standard <vagrantc>i don't imagine it's a great target for guixsd, given the slow processor and limited storage <brendyn>Seems like a bit of a shame that Guix wouldn't be able to run on it <brendyn>I'm hoping that Guix can become the goto package manager for building distros so working on making it lighter is important. <vagrantc>i think for that to be realistic, it would need some sort of non-rolling release branch or something ... or a massive upgrade of the sustitute server build farms <vagrantc>and some mechanisms to autoremove older profiles and garbage collect them automatically <vagrantc>with offloading, i did manage to get GuixSD installed on a Wandboard Solo ... single-core with 512MB of ram ... but it was still painfully slow even with offloading <pkill9>the EOMA68 cards will be dual core 1.2ghz with 2GB of RAM so it might be able to run Guix <pkill9>i think the RAM may be the biggest bottleneck though, idk <pkill9>oh yeah, need a decent amount of storage <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 <ng0>I only get to 1GB usage again <ng0>iirc we were even back to 512 MB now? <vagrantc>i've seen highly variable results over the last few months <davidl>Im trying to reconfigure my system which leads to overheating all the time and my computer auto-shutsdown because of it. <davidl>Is there a way to limit processes spawned by a guix system reconfigure? <davidl>since the guixbuilder processes is what causes overheating <davidl>since these are forked processes Im not sure if doing cpulimit --pid --include-children can work? <jlicht>Is there a specific and/or important reason that the binary guix installer bails on armhf platforms? <davidl>so a way to avoid overheating from build-processes is to put guix-daemon process in cpulimit and loop over pgrep gcc for input to cpulimit. <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. <rekado>kmicu: these are temporary redirects to avoid broken links due to the new translation. <rekado>kmicu: these should become proper server-side redirects soon. <pkill9>davidl: you can set the number of CPU cores that guix uses by default <vagrantc>janneke: pretty much comes down to finding people able to maintain it and do the work of uploading it to debian <janneke>ACTION should have become a debian maintainer :-) <vagrantc>janneke: still could; the process is a lot simpler than it used to be <janneke>vagrantc: i like that thinking -- already dismissed that option because oh, when i read the maint-guide and thought about it, 20y ago, i had soooo much free time :-D <OriansJ>Just a stupid thought but what if we made our source bootstrap just depend on bash and gcc. That way we can avoid the Source bootstrap problem on Debian or any other linux systems? <vagrantc>janneke: i'd be happy to help with packaging mes for debian, but have little experience in C and scheme ... <pkill9>what format does `guix archive --export` output as? <vagrantc>janneke: how does M2-Planet fit into the picture? <cehteh>root@guixfarm ~# guix system --help <janneke>M2-Planet is a work in progress, wrt mes <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 <roptat>cehteh: you have to run guix pull once more <OriansJ>M2-Planet is currently self-hosting and can be built with only mescc-tools <vagrantc>janneke: but at least getting mes in debian will allow mes to be built with both guix and debian, and then see if you get reproducibility from that? <janneke>yes, and it will help experimenting with it <janneke>it's been as a regular package in Guix for about a year, and it's only now that we're working to get it into the bootstrap process <OriansJ>vagrantc: actually the M2-Planet extends beyound DDC by making the results independent from the host system entirely and bit identical results on even arbitrary hardware platforms <rekado>cehteh: this has come up a couple of times during the past weeks. If you’re using “guix pull” another “guix pull” should fix this. <rekado>cehteh: this is a bad error message for the case where a recent version of “guile-sqlite3” is not available. <cehteh>its an old install i didnt care for a long time, i'll try to pull a few times :D <rekado>cehteh: you should not have this problem after using “guix pull” <cehteh>because i think i already pulled 4 times <rekado>cehteh: also note the change to “guix pull”! It installs a full Guix to ~/.config/guix/current/bin. Use that executable. <rekado>the old ways of installing just Guile modules to ~/.config/guix/latest is finally gone <cehteh>guix pull -l throws a backtrace, but there is still another job goin on, i give it some time <cehteh>well i'd expect that updates are atomic <rekado>could you please paste it. Obviously this should not happen. <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? <davidl>pkill9: thank you. I will try that. <cehteh>i thought the compiling would be faster now? <cehteh>by faster i hoped for much faster, this is no slow machine and its still unbearable slow <rekado>cehteh: we are building substitutes for these “guix pull” derivations. <rekado>cehteh: you can still be unlucky and not get substitutes for the particular version you are pulling. <cehteh>anyway, i just wait and try to pull again if it still fails <rekado>cehteh: so, compilation itself is not faster (that’s up for Guile developers to improve), but we can offer a fast path for “guix pull” in many cases now. <OriansJ>vagrantc: and rather trivial by design. <cehteh>some blazing fast -O0 for guile would be nice <rekado>yeah. I’m sure wingo has great things in store for the next releases of Guile. <OriansJ>vagrantc: the best part is when built by gcc, M2-Planet compiles C at 6+MLoc/S <cehteh> ~/.config/guix/current there and works <kmicu>That makes sense. Thank you rekado ( ^_^)／ <vagrantc>janneke: seems like debian is missing a lot of the dependencies: Missing dependencies [nyacc, M1, hex2, blood-elf, guile-tools], run <OriansJ>vagrantc: M1, hex2 and blood-elf are all part of mescc-tools <OriansJ>mescc-tools also provides kaem for those who don't want to depend on bash or make <OriansJ>It is functioning as a placeholder, until I or someone else takes the time to replace them with Handwritten equivelents. <davidl>my wayland SDDM is now only blackscreen after upgrade, but I can start gnome through XDG_SESSION_TYPE=wayland ..