IRC channel logs


back to list of logs

<CharlieBrown>It works!
<CharlieBrown>OK, now to back up all the garbage on my disk.
<Petter>ACTION zzz
<grillon_>ACTION is gone
<reepca>woops wrong buffer
<OriansJ>bavier: You just made my day :D I am glad someone else have made use of stage0
<buenouanq>soon to [again] attempt installing guixsd on a macbook
<buenouanq>it says # deco start cow-store /mnt
<buenouanq>which in the normal guide is herd not deco
<buenouanq>what is the difference?
<methalo_>buenouanq: deco was previously
<buenouanq>oh, ok
<buenouanq>anything else in that link that is out dated?
<methalo_>see more,
<paroneayea>hello *
<mekeor>hello paroneayea :)
<buenouanq>ok, have booted to the flashdrive
<buenouanq>I'm going to leave the OSX partition for now incase something goes wrong.
<paroneayea>hi mekeor
<buenouanq>had to start over with --fallback but it's looking like the installation is finishing up
<buenouanq>next step is the only bit I'm concerned about, manually editing the refind config
<buenouanq> has a better way been found to do what it describes near the end?
<buenouanq>I actually didn't give my root partition a label, is this not going to work with refind, or can I do /dev/sdXN as per normal?
<buenouanq> my question really is, is the bottom one what I want?
<buenouanq>I was wrong about it being close to finishing I guess.
<coiel>hi there
<coiel>1) Emacs packages: melpa or guix?
<coiel>2) how to install EXWM in guix?
<buenouanq>things should not have their own package managers
<buenouanq>in the past this might have been necessary due to the inadequacies of previous generation package management,
<buenouanq>this is no longer true with guix
<buenouanq>$ guix package install emacs-exwm
<Apteryx>What's all the fuss about exwm? I've never heard about it.
<Apteryx>Does someone else has issue when trying to play videos fullscreen in IceCat? I'm thinking it might be caused by ratpoison, but for me the video doesn't maximize, and IceCat becomes unresponsive (high CPU load).
<CharlieBrown>Apteryx: Emacs. As Window Manager.
<Apteryx>How does that work? Sounds interesting.
<Apteryx>Completely implemented in elisp?
<buenouanq>wait, so like
<buenouanq>what do you add to you x init then?
<CharlieBrown>echo exec emacs >~/.xinitrc
<buenouanq>this might be everything I've always wanted キタ━━━━(゚∀゚)━━━━ッ!!
<CharlieBrown>Guix doesn't have .xinitrc, though, right? Nix doesn't even have it.
<buenouanq>I think .xSession or whatever is what you're supposed to use
<Apteryx>Has anyone experience with modern AMD gpu & guix or libre-linux in general?
<Apteryx>I'm wondering if an AMD R9 285 would be supported.
<DoublePlusGood23>Apteryx: I'm pretty sure modern amd gpus require firmware blobs
<DoublePlusGood23>amdgpu will help, but I think the gpu checks the firmware when it initializes and whatnot.
<DoublePlusGood23>CharileBrown: smh, should be wayland
<balduin>how can I add guix packages to the path?
<CharlieBrown>DoublePlusGood23: Wayland sucks.
<balduin>sorry, the build output to the path?
<DoublePlusGood23>CharlieBrown: less than X
<Apteryx>DoublePlusGood23: Right... Thanks for remembering me about that. It would require the Tonga firmware, which is deblobbed in linux-libre.
<DoublePlusGood23>Apteryx: It doesn't need to be signed?
<CharlieBrown>DoublePlusGood23: My push to talk key doesn't work in Mumble, and Alt+Space and Alt+F don't work in GNOME anymore.
<DoublePlusGood23>Apteryx: Ah nevermind. I missread
<CharlieBrown>No more Alt+Space+X? Forget that.
<DoublePlusGood23>CharlieBrown: I can't use LVM in GuixSD. It's still better than different package managers.
<CharlieBrown>Or Alt+Space+N.
<CharlieBrown>Nothing was broken in my workflow in X. If it ain't broken, don't fix it.
<DoublePlusGood23>CharlieBrown: If you were designing a new (niche) WM, it doesn't make much sense to target X
<CharlieBrown>exwm isn't that new.
<Apteryx>Is anyone else using ratpoison??
<CharlieBrown>I was, but not anymroe.
<Apteryx>Moved to exwm?
<Apteryx>I'm wondering if anyone else has that issue in IceCat where cliking on the 'maximize' button of the media player doesn't take effect and freezes IceCat.
<Apteryx>Intel AMT has security issue revealed:
<CharlieBrown>Apteryx: Moved to JWM.
<CharlieBrown>Apteryx: Getting GuixSD soon. Will probably be using Xfce.
<Apteryx>OK! Cool.
<Apteryx>When you were using ratpoison, you did not noticed that problem about IceCat fullscreen videos locking it up?
<CharlieBrown>Apteryx: I think it happened, yes.
<Apteryx>Another strange thing is Ctrl + Mouse button 1 kills the current frame. Haven't seen this documented in the manual so I'm not sure if it's intended or not, but I find it a bit dangerous.
<Apteryx>Maybe it's to remind us that the 'rat' should be banished ;)
<coiel>Q 3) is there something like wifi-menu (don't want to use NetworkManager / Gnome etc)
<CharlieBrown>Apteryx: Does the source code say anything about Ctrl+Mouse1?
<coiel>Apteryx: EXWM is coolest thing in XXI (after EMACS itself)
<Petter>Apteryx: I don't have any issue witch IceCat videos fullscreen on Xfce.
<Apteryx>Petter: OK. Confirms my doubts that it might occur only with ratpoison. Thanks!
<Apteryx>coiel: Ehe! Looks like I'll have to try it out. I'm also curious about guilewm.
<Petter>Yeah, smells like it.
<Apteryx>CharlieBrown: I'm trying to find reference to shortcuts... Not sure where to look for. There's action.c which defines some "commands", but these look like the primitives action I can do and not related to the keymaps.
<CharlieBrown>Backup archive created! :D :D
<CharlieBrown>In the command line, how do I get a progress bar while copying a file?
<CharlieBrown>Is it hard to edit Lisp in Vim?
<lfam>CharlieBrown: I use the paredit plugin in Vim for editing Lisp-y things. It works okay, but it's not perfect
<Apteryx>CharlieBrown: I think I found where the default shortcuts are defined! It's a function called `initialize_default_keybindings' in actions.c (line 920).
<CharlieBrown>Apteryx: There's your answer, then. :)
<Apteryx>Looks like a bug; only C-t (C-) k or C-t (C-) K should terminate/kill frames based on the source.
<Apteryx>At least my short study of the keymaps.
<CharlieBrown>Will I be able to "cryptsetup luksOpen /dev/sdc3 ToshibaHD" on GuixSD?
<CharlieBrown>I don't think it's LVM.
<Apteryx>marusich: Thanks for offering help regarding Japanese fonts. I've been meaning to reply, but I thought I'd wait until my 'guix package -u' finishes. It' been like 24 hours now ;)
<buenouanq>I have yet to get ibus-anthy working.
<buenouanq>Haven't tried in a while though.
<Apteryx>Is this the only choice when it comes to japanese input?
<buenouanq>If you've gotten moon input working Apteryx, I would love to hear how or what you used.
<Apteryx>moon input?
<buenouanq>ibus-anthy is what I got used to on debian
<Apteryx>Yes, that's what I was using on Ubuntu as well.
<CharlieBrown>Oh yeah, I'll need to be able to type CJK, Russian, Hebrew and Arabic.
<Apteryx>Good collection.
<CharlieBrown>I need to get back into languages.
<CharlieBrown>So I can actually use them.
<CharlieBrown>Maybe I can translate documentation and put that in my portfolio.
<Apteryx>I keep learning computer languages instead; they're just so much easier ;)
<CharlieBrown>That way, I can have enough skills to be able to apply to jobs by email instead of by bad web interfaces running proprietary software.
<CharlieBrown>Apteryx: I also wanna get into Cobol.
<rekado>sneek: later tell lfam I cannot reproduce the hurd problems locally. I built the libc for hurd with “./pre-inst-env guix build --fallback --target=i586-pc-gnu glibc-hurd”
<marusich>Apteryx, OMG tell me about it.
<marusich>I spent over 24 hours waiting for "make check-system" to fail to run a single test.
<marusich>On the topic of Japanese language input, I was actually writing a section of the manual about precisely that.
<CharlieBrown>marusich: Yay! :D
<CharlieBrown>Thank you!
<rekado>did any of you get Arabic input to work?
<marusich>Long story short, these steps are sufficient, but I was hoping to summarize it a little more clealy in the manual:
<rekado>it used to work and then it broke
<rekado>since then I couldn’t fix it anymore.
<marusich>I have not tried Arabic.
<marusich>Also, CharlieBrown you should thank rekado; he's the one that did the hard work to get it working :)
<CharlieBrown>domo, rekado
<marusich>Also, another thing you might not know: if you just want to type in emacs, emacs actually provides an input method all its own for Japanese input
<marusich>I was surprised to discover that. It works even if ibus isn't installed
<CharlieBrown>but sometimes i need to type elsewhere
<marusich>Well, the method in that email thread works for me for every application I've tried so far.
<CharlieBrown>The Japanese government wrote it.
<marusich>Anyway, goodnight!
<buenouanq>ok, it finally finished building
<buenouanq>how many hours was that?
<buenouanq>now I get to ruin everything by mussing with refind
<buenouanq>k so this is what happened to me last time
<buenouanq>I'm getting `Invalid loader file! Error: Not Found while loading bzImage'
<buenouanq> here is the refind menuentry
<buenouanq>I hate when projects/programs don't have official IRC rooms.
<CharlieBrown>I am now fully ready to install GuixSD. Here comes a wild ride.
<buenouanq>Anyone here familiar with efi or refind that could maybe help me?
<civodul>Hello Guix!
<Petter>I'm having trouble adding modules to perl.scm and I have no idea why. Whenever I do I get this error when I try to build f.ex. perl-scala-list-utils: guix build: error: perl-scalar-list-utils: unknown package
<Petter>Goes from build success to error with a change like this,
<Petter>I can add modules to other packages, just not perl.scm...
<snape>Petter: so perl-scala-list-utils is a package you want to add, right?
<Petter>snape: No, it's a test. This package is already in perl.scm
<snape>:) it's scalar
<snape>not scala
<Petter>Sorry, I typed wrong in IRC.
<snape>yes I thought that was the problem, but I was wrong
<Petter>I'm running: `~/guix/pre-inst-env guix build perl-scalar-list-utils`
<snape>that would be great to see the change that causes the problem to perl.scm
<Petter>First unmodified from master, success. Then add package, error.
<snape>could you share it?
<Petter>The change is as I linked, just adding a module.
<snape>oh I see
<Petter>I've added modules in other files without problem.
<Petter>I've tried with other modules as well, always error.
<janneke>welcome back civodul!
<Petter>Are you able to build any package in perl.scm after adding a module?
<Petter>I'm not sure if it's a problem for everyone or just me.
<civodul>Petter: probably #:use-module (gnu packages web) rendered perl.scm unloadable for some reason
<civodul>yeah that's probably why we have perl-web.scm
<Petter>Hm, I see.
<civodul>well, the root of the problem is that tls.scm has top-level references to 'perl'
<civodul>via (package-license perl)
<Petter>Should we aim to fix this you think? I'm having problems organizing new perl modules.
<civodul>yes we could/should
<civodul>an easy fix is to (define perl-license gpl1+) in (guix licenses)
<civodul>and then use 'perl-license' instead of (package-license perl) in tls.scm
<civodul>Petter: do you want to try that?
<Petter>Cool, yes I'll try that.
<Petter>At least I can get the perl modules where they belong.
<Petter>(Not saying easy fixes can't be good fixes :P)
<civodul>just send the thing to guix-patches when you're done!
<Petter>(I'm packaging parcimonie, currently counting 58 new packages x.x)
<Petter>Is this whole (license (package-license ... )) an antipattern?
<civodul>Petter: not really, but it causes problems in this case
<civodul>because to load tls.scm you first need to resolve 'perl' in perl.scm
<civodul>and to load perl.scm, you first need to load tls.scm
<Petter>Ok, circular dependency.
<civodul>yeah, in a sense a limitation of Guile's current module system
<Petter>It may be more like this. I've created perl-license and updated tls.scm,
<Petter>But I still can't add a module to perl.scm.
<Petter>I see 19 files with (package-license perl). Was there a trick to figure out circular dependency? Or is this a manual job?
<civodul>mostly manual :-/
<Petter>I'll try replacing that with license:perl-license in all the files.
<rekado>Hi Guix.
<rekado>Today I’m playing with cuirass again
<rekado>I’ve been trying to set it up such that it will regularly update and build *two* repositories.
<rekado>i.e. Guix upstream + a custom repository
<rekado>but it seems very difficult to accomplish this, especially with the very limited output cuirass provides
<civodul>heya rekado!
<civodul>rekado: what's the problem exactly? :-)
<civodul>i've never tried it
<rekado>civodul: the problem appears to be with the load path
<rekado>the first thing that’s confusing is that both the cuirass service and the specifications that one feeds to cuirass have a load-path field
<rekado>the former is a list, the latter is a string
<rekado>so I thought I’d set up two specifications: one for the guix upstream repo, the other for the custom packages
<rekado>these are out of sync, but they depend on one another
<rekado>so I thought that maybe it would be better to have just one specification (for guix upstream) and add my custom repo to the load path
<civodul>rekado: hmm yeah, that load-path story is weird
<rekado>but anything I do to the load path just results in unexpected errors
<civodul>error handling is terrible in Cuirass
<rekado>like: it’s trying to load mcron modules, but there is no mcron anywhere
<rekado>or it tries and fails to load gnutls
<civodul>perhaps you could ping the list and Mathieu O.
<rekado>the fact that it doesn’t print what it’s doing makes it pretty hard to debug this
<rekado>(I’m trying all of this on GuixSD, and I’m not using cuirass on the command line)
<civodul>you did check /var/log/cuirass.log, right?
<rekado>I’ll fiddle some more and contact the list when I’m ready to give up
<rekado>yes, I’m looking at the log, but it’s barely useful
<rekado>when there are no errors and it should just build “hello” I only see the output of git
<rekado>any of my trace commands that I put in the file that defines the cuirass jobs don’t appear anywhere
<Petter>YES! I can add a module to perl.scm :D
<Petter>Only had to do this,
<efraim>I need to fix building guix on aarch64, still have a test failure
<rekado>ah, cuirass does not output anything when a build has already been successful.
<rekado>needed to take a look at the database to see that.
<Petter>Hm, do I need to add myself to copyright with these changes?
<rekado>tried running cuirass from the command line
<rekado>the errors aren’t good
<rekado>ERROR: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure %glibc-bootstrap-tarball ()>
<rekado>doesn’t tell me where
<rekado>and due to this error the evaluation of the job file fails, which leads to “scm-error wrong-type-arg ‘map’ ‘Not a list: ~S’ (#<eof>) #F
<rekado>I’ll see if I can make this fail more gracefully
<civodul>rekado: the glibc wrong-type-arg is due to the outdated job file in Cuirass
<civodul>check cuirass-jobs.scm in guix-maintenance.git
<civodul>basically Cuirass duplicated gnu-system.scm, but then it bitrotted
<rekado>oh, thanks for the hint!
<rekado>hmm, boost fails to build on i686-linux, so ‘guix environment guix’ fails
<az`>hi there! Help! Why when I try to install wpa_supplicant (from emacs-guix): " Throw to key `srfi-34' with args `(#<condition &message [message: "icu4c-CVE-2017-7867-CVE-2017-7868.patch: patch not found"] 45829c0>)'."
<az`>and Question 2: why I lose my change in /etc/sudoers ?!
<davexunit>az`: those files are immutable
<davexunit>you edited it manually? never do that in guix.
<az`>ok, thanks, remember that. But where I can find docs about sudoers format in config.scm or something?
<davexunit>az`: see sudoers-file in the manual
<davexunit>you can look it up in the index and it will take you to the docs
<az`>your mean <M-x>info-apropos?
<az`>"man sudoers" take me standard sudoers manual of course, not guixSD specific
<davexunit>in the guixsd manual
<davexunit>in emacs I press 'i' to search the index once I have the guix manual open
<jlicht>hi guix!
<jlicht>Is anyone using ansible on GuixSD currently? Not voluntarily, of course ;)
<jlicht>I am running into some issues with the renamed binaries (IE .ansible-real)
<civodul>jlicht: oh does it rely on $0?
<davexunit>ACTION wishes we could get Chef packaged, but is much more complicated than Ansible
<az`>There is any cases, when we need "sudo guix" instead of user-wide "guix"?
<davexunit>az`: applying system updates
<davexunit>only root can do that
<az`>davexunit: thanks!
<jlicht>civodul: it seems so ;-)
<jlicht>It has something to do with how they support ansible sub-commands
<jlicht>davexunit: what are the current problems in getting Chef to work?
<civodul>jlicht: could you report the details to bug-guix?
<civodul>i'm also tired of seeing those .foo-real things in 'ps' :-)
<jlicht>civodul: Will do once I get back from work
<civodul>perhaps we'll have to generate native-code wrappers
<civodul>so they get the right argv[0]
<az`>sorry, can't understand why: " guix package -i wpa_supplicant
<az`>guix package: error: wpa_supplicant: unknown package"
<jlicht>az`: try wpa-supplicant perhaps?
<az`>wow, it works! 2 last hours )))
<brendyn>Schemers love hyphens too much to call it wpa_supplicant
<jlicht>always my first instinct when I see _ as well ;-)
<az`>where is right place to set PATH in guix?
<wingo>civodul: i think guile wrappers could do it, no? you can pass argv[0] explicitly i think
<wingo>maybe that's too-high overhead tho :)
<jlicht>az`: For my own stuff, I add an `export PATH="$PATH/...";` to my ~/.bash_profile
<jlicht>* `export PATH="$PATH:...";`
<civodul>wingo: i think you lose when there's a shebang
<wingo>civodul: why would that be?
<wingo>the shebang args don't go to the shell, after all
<wingo>it's just like having a dynamically linked library in a way
<wingo>like the kernel has to read to find the ELF interpreter, then exec the interpreter
<wingo>same thing: kernel reads to find sheband, execs guile instead
<civodul>i *think* the problem is when you have foo that wraps .foo-real that wraps .foo-real-real
<wingo>or sh or whatever
<civodul>i forgot the details
<wingo>ACTION nod
<az`>eh... not too fast young guix user: "which wpa_supplicant
<az`>which: no wpa_supplicant in (/home/az/.guix-profile/bin:/home/az/.guix-profile/sbin:/home/az/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin)"
<civodul>wingo: more specifically, bin/ansible has #!/bin/sh (with $0 = "ansible") and bin/.ansible-real has #!/bin/python (with $0 = ".ansible-real")
<jlicht>az`: How did you install wpa-supplicant? Did you perhaps install it in the root profile?
<civodul>my understanding is that the second $0 will always be ".ansible-real"
<davexunit>it would be nice if we had a way to avoid that .ansible-real situation
<wingo>certainly would be possible to create a different store prefix that applies the wrapping
<civodul>so in fact a native-code wrapper wouldn't help here
<davexunit>other applications do things like print the program name in the --help output and that looks ugly
<wingo>so that /gnu/store/a-ansible/bin/ansible has a wrapper that invokes /gnu/store/b-ansible/bin/ansible
<davexunit>the eye-of-gnome image viewer also prints it in the window title IIRC
<civodul>wingo: oh right, so that'd involve a second derivation and all
<wingo>yeah i guess so yeah
<civodul>but maybe we could change #!/bin/python to #!/bin/wrapping-python
<civodul>which would preserve the shebang
<wingo>or you could of course instead of going to .ansible-real you could go to .real/ansible
<civodul>err, would preserve $0
<civodul>sounds easier
<civodul>we should do that
<az`>jlicht: from user: "~ $ guix package -i wpa-supplicant --fallback
<az`>The following package will be upgraded:
<az`>nothing to be done"
<az`>~ $ which wpa_supplicant
<az`>which: no wpa_supplicant in (/home/az/.guix-profile/bin:/home/az/.guix-profile/sbin:/home/az/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin)
<rekado>az`: I cannot reproduce this.
<az`>maybe eshell?
<rekado>wpa_supplicant is installed to the sbin directory of the output.
<wingo>civodul: the only downside of .real/ansible would be things that do $(dirname $0)
<wingo>which might be many things
<az`>rekado: I'll try to reboot
<rekado>az`: that shouldn’t be necessary
<rekado>what do you see in /home/az/.guix-profile/sbin
<az`>maybe some PATH settings?
<wingo>but i guess we could patch those packages
<az`>ls /home/az/.guix-profile/sbin
<az`> ls /home/az/.guix-profile/sbin
<az`>wpa_cli wpa_passphrase wpa_supplicant
<az`>yes it here!
<az`>something wron with PATH setting
<az`>but why:
<az`>~ $ which wpa_supplicant
<az`>which: no wpa_supplicant in (/home/az/.guix-profile/bin:/home/az/.guix-profile/sbin:/home/az/.guix-profile/bin:
<civodul>wingo: good point
<rekado>az`: have you tried a different shell?
<az`>in default xterm bash, there is not .guix-profile/sbin in $PATH
<jlicht>az`: Did you overwrite $PATH in one of your startup files?
<az`>I'm on my first, clean guix installation
<wingo>how could you have a foo that wraps .foo-real that wraps .foo-real-real tho :P
<civodul>actually that no longer happens :-)
<civodul>earlier that could happen if you had several 'wrap-program' calls
<wingo>good, that would be silly then :)
<wingo>in that case maybe you don't need to move them at all then, you can just execv and pass the wrapped path as argv[0]
<wingo>i.e. you can keep the file at .real-whatever; it doesn't matter where it goes actually
<DoublePlusGood23>woohoo. I have a desktop!
<Petter>Nice! :)
<rekado>to make LDAP authentication work with logins on this GuixSD server it seems that I need to preload a library
<rekado>is there a way to preload the library in the global environment, so that all services inherit from it?
<rekado>all binaries that do user discovery need to preload nss-pam-ldapd’s
<rekado>or else they won’t look for accounts in LDAP
<civodul>i would guess something needs to be added to nsswitch.conf, no?
<rekado>that too
<civodul>then nscd will dlopen it on behalf of clients
<rekado>I’ve already added ‘ldap’ to the name-service-switch configuration
<rekado>I also added nss-pam-ldapd to the ‘name-services’ field of the nscd-configuration
<civodul>maybe make sure that /etc/nsswitch.conf looks good and that nscd actually loaded the .so
<rekado>how can I check that nscd loaded the .so/
<balduin>what do I have to do to contribute a package?
<rekado>balduin: please take a look at the section entitled ‘Contributing’ in the Guix manual
<DoublePlusGood23>so I just run guix pull and everything will be updated?
<rekado>DoublePlusGood23: no, ‘guix pull’ only updates the ‘package database’
<rekado>DoublePlusGood23: to actually update your installation you need to run ‘guix package -u’ and ‘sudo -i guix system reconfigure /etc/config.scm’ (if you’re using GuixSD).
<DoublePlusGood23>Is it possible to flash a new libreboot frub.cfg on GuixSD?
<mbakke>DoublePlusGood23: you may be able to simply copy the generated grub.cfg to /boot/grub/libreboot_grub.cfg
<mbakke>see this thread:
<snape>DoublePlusGood23: mbakke: it's probably better to symlink it, so it remains the same as grub.cfg after guix system upgrades
<mbakke>snape: the post in question was using --no-grub, but it may be possible to let grub do its job each reconfigure and symlink /boot/grub/grub.cfg
<snape>grub.cfg is built even if --no-grub is passed
<snape>which is what we want, because we want libreboot to use the Guix-generated grub.cfg
<mbakke>yes, but the store location changes each reconfigure
<snape>grub.cfg will be in /boot/grub/grub.cfg
<snape>which does not change
<mbakke>unless you have --no-grub, then that file will not be updated
<snape>ah, maybe :) Then you should not use --no-grub...
<DoublePlusGood23>mbakke: encrypted / makes that hard
<mbakke>DoublePlusGood23: makes what hard? I think Stephen from that thread used FDE.
<DoublePlusGood23>mbakke: libreboot can't read something encrypted without mounting it first.
<mbakke>but it can unlock the disk before reading grub.cfg, no?
<DoublePlusGood23>mbakke: I'm not sure how it would. It's using grub to do that, which would require some sort of cfg file
<mbakke>right. maybe the libreboot payload needs to know which disk to read from?
<mbakke>there are a couple of people around here with FDE and libreboot, I'm unfortunately not yet among them :P
<snape>DoublePlusGood23: when you are in libreboot's GRUB, you type 'c', then 'cryptomount ahci0,gpt3' (for example), that will ask for a passphrase and mount the encrypted disk
<snape>there is probably a way to automate this by changing the payload
<snape>but this works
<snape>I believe libreboot is supposed to auto-detect the disk, it tries lots of them
<snape>but it's a bit slow
<DoublePlusGood23>snape: yes, that's how I'm currently booting. But I can't use flashrom under GuixSD to change the embedded grub.cfg to just skip all that
<DoublePlusGood23>It fails to mmap /dev/mem or something
<snape>which flashroom do you use? the Guix one or the libreboot one?
<DoublePlusGood23>snap: libreboot one
<snape>oh... then I don't know
<DoublePlusGood23>wasn't aware of a guix one
<snape>I didn't change the embedded grub.cfg, actually
<DoublePlusGood23>worst case I'll just need to boot a live parabola system and modify it there
<snape>yep, that should do the job :) But that would be nice to understand why it doesn't work with Guix
<snape>do other flashroom commands work?
<balduin>I get an CVE warning while using guix lint. The error has something to do with some X.509 certificate problems with ''. Have a look at this: for more information. Can I ignore that warning?
<DoublePlusGood23>snape: installing guix flashrom
<DoublePlusGood23>snape: I think I found something of note
<DoublePlusGood23>NOTE: if running flashrom -p internal for software based flashing, and you get an error related to /dev/mem access, you should reboot with iomem=relaxed kernel parameter before running flashrom, or use a kernel that has CONFIG_STRICT_DEVMEM not enabled.
<DoublePlusGood23>from the libreboot install
<barabaz>Hi, I'm on guix sd with full disk encryption. It's nice that it worked right away, just needed to adapt the snippet from manual
<barabaz>the other day I was laughing at a friend because his windows 10 would keep bumbling along for 2 minutes after logging in, doing nothing
<barabaz>now with grub and full disk encryption, my grin is washed away, because it spends 10 - 30 seconds seemingly doing nothing, after taking the disk password
<barabaz>do you also experience this issue?
<lfam>balduin: Does it work if you run `guix lint` inside of a shell created by `guix environment guix`? You might also need to set some variables, as described here:
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, rekado says: I cannot reproduce the hurd problems locally. I built the libc for hurd with “./pre-inst-env guix build --fallback --target=i586-pc-gnu glibc-hurd”
<lfam>balduin: The first suggestion assumes you're missing gnutls-guile (the TLS client we use), but I don't think you are, because you got a specific error message. The second suggestion assumes that gnutls-guile can't find any TLS certificates to validate the server certificate against.
<bavier>yay gcc 7.1!
<efraim>Its mot on the mirror I checked yet so I'm downloading it painfully slowly from the main ftp
<DoublePlusGood23>bavier: how many packages will break with it?
<efraim>Master and core-updates are built with 5.4.0
<lfam>We'll have to clean up the breakage from GCC-6 before we get to experience GCC-7's breakage ;)
<bavier>DoublePlusGood23: Fedora reported only about %1 of their packages FTBFS with a gcc 7 release candidate
<lfam>Any GNOME user want to try patching this vulnerability in gnome-shell?
<bavier>DoublePlusGood23: but yeah, like efraim says we probably won't be rebuilding the world with gcc 7 for a while yet
<DoublePlusGood23>lfam: oh darn
<DoublePlusGood23>bavier: that's good news at least
<efraim>I want to put together a package recipe that creates bootstrap tarballs for the current architecture and then uses those to build back to 'hello'
<DoublePlusGood23>FDE libreboot working :)
<efraim>Seems like the best automated way to test some of our package updates to core updates
<balduin>@ifam: thanks for the hint it worked. My only problem was I had to compile groff, because the Hdydra Substitute package did not work. The --fallback option solved the problem.
<efraim>Is xfce4-battery-plugin the latest version? Its FTBFS on aarch64
<balduin>what does FTBFS mean?
<bavier>balduin: "Fails To Build From Source"
<balduin>@bavier: thanks
<balduin>is there now aarch64 support?
<efraim>Partial, everything has to be built from source, including installing guix
<balduin>@efraim: but it is possible to build guix for aarch64. I mean just the minimal boostrap. Is this correct?
<efraim>there's no guixsd support yet but I have guix running on one of my aarch64 boards
<balduin>@efraim: thanks. Good to know. I would be happy to run Ripi 3 on GuixSD :-)
<balduin>@efraim: what aarch64 board do you use?
<efraim>Right now I'm using an odroid c2 but I also have a hikey 96 board and the firefly 3399 board
<balduin>nice :-) what are you gonna do with the MALI graphics card on the HiKey board? There are no official open source driver available.
<balduin>Or any unofficial stable graphics card driver.
<efraim>I was going to worry about it later
<methalo>lfam , I can try install the patch!
<CalAndroid>I can't get the system to initialize.
<CalAndroid>guix package: error: build failed: some substitutes for the outputs of derivation '/gnu/store/...-weechat-1.6.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<lfam>CalAndroid: Did you try running the command again with '--fallback'?
<CalAndroid>Even if I can ping
<lfam>I would try running it with --fallback. That will build the package from source if substitution fails
<lfam>Yes, even if you can ping
<CalAndroid>It's too bad I can't get an IRC client on the live system right now.
<CalAndroid>./configure: hostname: command not found
<CalAndroid>It's still going, though.
<CalAndroid>is this going to build xfce from source?
<lfam>Only if it fails to download a substitute
<balduin>is there a possibility to run and have my own substitute server?
<snape>balduin: yes, with cuirass
<lfam>snape, balduin: You can also run a substitute mirror, by using the nginx configuration 'mirror.conf', from here:
<CalAndroid>This will take forever.
<snape>lfam: nice! I didn't know that
<balduin>@snape: thanks, but what is curiass?
<snape>balduin: it is a build automation server, for Guix
<snape>or rather
<snape>(new url)
<wingo>oh good, i was wondering if we would have a new url
<balduin>@snape: thanks
<wingo>maybe we can rename it too ;) i find the name a little weird
<wingo>maybe that's just me tho
<grillon>hi there
<snape>hi grillon
<balduin>can I use cuirass to create something PPA like. Where I have a few packages, but take the rest from hydra?
<snape>balduin: yes, you can build your own custom packages with cuirass
<snape>and you can have many substitute servers, so when one package is not found from, say, hydra, another server will be looked at
<m-o`>balduin: you will find a small tuto here:
<balduin>@snape: nice. That is good to know.
<buenouanq>Can anyone here help me with efi and refind?
<buenouanq> this throws an error
<platoxia>How long does an installation usually take? I booted the USB key and started the install but it has been compiling for over 12 hours now...
<wingo>did you enable substitutes?
<platoxia>I followed the guide exactly so if it was in the instructions I did...
<platoxia>I remember seeing the text scrolling by for it
<platoxia>I had some network issues and had to do --fallback
<m-o`>you remember running this "guix archive --authorize <" ?
<platoxia>I don't remember doing that but I definately say a lot of text scrolling by about hydra
<m-o`>without this your daemon won't use substitutes from hydra and rebuild everything
<platoxia>so you mean it WILL rebuild everything without that daemon?
<CalAndroid>I should have skipped xfce until install was done
<CalAndroid>idk how I will even boot the thing
<wingo>civodul: any thoughts on the potluck stuff? i tried to make wip-potluck comprehensible fwiw
<platoxia>its fine if that is the case, I just wasn't sure if it should take this long...gentoo never took this long
<m-o`>platoxia: this command allows the use of package substitutes from the build server hydra
<CalAndroid>do I need to use --no-grub on libreboot
<snape>CalAndroid: no
<wingo>civodul: if you want me to just commit it, lmk ;)
<platoxia>m-o`: okay, I'll keep that in mind but for now it has been going for so long already I'll just let it finish.
<CalAndroid>it's still going. is this what gentoo is like?
<m-o`>platoxia: ok but it may be really long :)
<platoxia>m-o`: over 12 hours so far...but meh, wasn't doing anything important anyways
<wingo>platoxia: better to stop it, auth the substitues, & continue
<wingo>it is doing many small steps; the builds you have done are not lost
<CalAndroid>I can't back out now. I only have one SD card, and I have no working computer to write Trisquel to it
<wingo>maybe we need to warn by default if people haven't done the auth phase
<wingo>i.e. cause people to do guix archive --disable-substitutes if they really want to build all the things
<CalAndroid>wait, it's not working because I did not auth subs? I remember doing that in the past. but it was not in the guide. I feel dumb
<wingo>without warnings i mean
<wingo>CalAndroid: i don't know about your case, i was just reading platoxia's thing
<wingo>anyway, good evening to all, i think i go read now :)
<bavier>I think we do warn if substitutes are not authorized
<apteryx[m]>m-o`: I think is authorized by default, at least for GuixSD.
<bavier>CalAndroid: local builds due to --fallback are different from substitutes not being authorized
<bavier>apteryx[m]: yes, on the installation image they are
<platoxia>Yes, I am using GuixSD and remember all the Hydrastuff...and yes, I had to do --fallback so I think that is what is going on.
<CalAndroid>oh ok
<CalAndroid>what's grafting
<apteryx[m]>And that doesn't seem to help much in preventing rebuilding the world at the moment. I think Hydra is just lagging behind or something.
<CalAndroid>bavier what do you want me to read? im on a small screen
<bavier>CalAndroid: that section of the manual explains grafts
<bavier>could be read in the info manual too of course
<CalAndroid>test runpy
<CalAndroid>more configure, more compiling. this is taking forever
<balduin>are there some issues with the hydra substitute server? I had several issues installing packages today.
<platoxia>CalAndroid: I was compiling for ~14 hours from doing --fallback and decided to stop and start again without --fallback and the hydra servers seem to be chugging along for me right now.
<platoxia>If you have to do --fallback its probably best to try restarting without --fallback every hour or so.
<reepca>Sounds like it'd be nice to have a "fallback-if-necessary" option
<platoxia>I was thinking the same thing. Or just have the script stop and restart periodically if it has to invoke --fallback.
<platoxia>It seems I compiled the vast majority of my install before restarting without --fallback...but it is finally finished.
<platoxia>time to reboot and see what I get
<CalAndroid>wait how did platoxia get on irc? I couldnt
<bavier>CalAndroid: you can install an irc client once booted into the install image
<bavier>CalAndroid: e.g. 'guix package -i weechat'
<CalAndroid>that gave me similar errors to tge one in my screenshot
<CalAndroid>not enough ram?
<CalAndroid>guix takes up lots of space
<CalAndroid>bavier do I cancel with ^C then redo the command without fallback?
<bavier>CalAndroid: that can be done, yes
<CalAndroid>it keeps doing gzip and stuff just for weechat
<CalAndroid>oh! it works now!
***CharlieBrownSD is now known as CalGuixSD
<CalGuixSD>OK, doing C-c.
<bavier>CalAndroid: substitutes are gzipped
<CalGuixSD>Got WeeChat, Tor, Links.
<CalGuixSD>Hm, it seems I can't use Tor on the live system, because that would require changing the system declaration, and surely you can't change the system declaration on the live system.
<CalGuixSD>bavier: I did ^C and did "guix system init /mnt/etc/leela.scm /mnt". It still failed and asked me to do --fallback.
<CalGuixSD>I guess I have to wait fourteen hours...
<CalGuixSD>System declaration, and results of system init:
<CalGuixSD>Trying with --fallback agian... :-(