IRC channel logs


back to list of logs

<paroneayea>davexunit: "OH: our ci server continues to run out of inodes because each web site uses ~140,000 files in node_modules"
<Apteryx>Here's the result of what I tried earlier today: Still some strange errors that seem to be related to gnutls in guix git.
<Apteryx>albertoefg: hi!
<albertoefg>Apteryx: hi
<Apteryx>How is your Friday going?
<albertoefg>good :)
<Apteryx>Great! Working on something in particular?
<albertoefg>I'll play libre game night later wanna join :)
<albertoefg>we only play libre games
<Apteryx>My laptop is too crappy for games :/
<albertoefg>tonight will play the mana world
<albertoefg>but every Friday we play a different game
<albertoefg>and we usually like hedgewars i bet your laptop support it
<albertoefg>i joined #guix to ask how can i help :)
<albertoefg>i speak Spanish i am from Mexico
<Apteryx>OK! Sorry I'm not much into gaming. But I just read the page about mana world, it looks interesting. I'll try it at some point!
<albertoefg>you can join us in #lgn if u want :)
<Apteryx>albertoefg: The channel has been very quiet today! But if you are into gaming and you don't find your favorite (libre) game on Guix you could help by trying to package it!
<albertoefg>oh i see
<albertoefg>that seems fun
<Apteryx>I know on the Guix website it seems like packaging is one of the area where they need the most help.
<albertoefg>i had trouble when installing guix
<albertoefg>it took too long
<albertoefg>i installed it on fedora
<Apteryx>I installed using the GuixSD image (on USB drive).
<Apteryx>It took a while but not terribly long. I chose lightweight desktop config, so if you opted for a full desktop config it would be longer I guess.
<albertoefg>oh i see
<albertoefg>it seems easier than a virtual machine
<jmd>Mornin' all
<Apteryx>jmd: In Berlin, maybe? ;)
<Apteryx>It takes forever to build the kernel on my machine :o
<Apteryx>The Libre-Linux kernel, I should say.
<alezost>Apteryx: re guix-daemon and gnutls error: it looks like you start guix-daemon in the environment that does not contain GUILE_LOAD_PATH with gnutls modules
<alezost>run "guile" in that environment and try ",use(gnutls)" there
<alezost>Apteryx albertoefg: btw "manaplus" (the client for "The Mana World") is packaged for Guix
<albertoefg>great :)
<albertoefg>if i screwed guix installation (not guixsd ) is there a way to start again or something
<albertoefg>or to remove guix completely
<alezost>albertoefg: to remove it, you need to remove /gnu, /var/guix and ~/.guix-profile link
<albertoefg>and what about systemd daemon?
<albertoefg>i mean i just want to reinstall
<albertoefg>but not sure what i did wrong
<alezost>if you are going to reinstall guix, then I think you need it still, no?
<albertoefg>so i use fedora
<albertoefg>and fedora 24 has not gnash
<albertoefg>i need flash for a few government websites
<albertoefg>if i install gnash with guix that means i can use it with icecat that was installed with fedora repos?
<albertoefg>or I'll need to install icecat with guix
<alezost>gnash is not packaged for guix :-(
<albertoefg>oh i see
<albertoefg>sadly gnash is losing development
<albertoefg>i know flash sucks
<albertoefg>but my government sucks more and requires to use flash on many sites
<albertoefg>some websites can only be used with internet explorer
<albertoefg>federal goverment!
<albertoefg>not some crappy local website
<albertoefg>it bothers me so much that u have to use internet explorer to use a government web site
<albertoefg>but i know why
<albertoefg>because they make arrangements with Microsoft no use certain software
<albertoefg>and if Microsoft doesn't offer then politicians demand a part of te money's deal
<albertoefg>thats why they dont like libre software
<albertoefg>they can steal by "buying" proprietary
<albertoefg>i live in Mexico btw
<albertoefg>any way that was not the point.. I'll reinstall Guix in the morning :)
<rekado>albertoefg: I’m working on packaging hedgewars
<rekado>not so easy because it depends on Free Pascal, which cannot be bootstrapped without Free Pascal.
<rekado>trying to build the ancient GNU Pascal in hopes to then build a version of Free Pascal.
<albertoefg>wich i new how to package
<albertoefg>i am learning how to program
<rekado>most applications are easier to package.
<civodul>Hello Guix!
<kmicu>( ^_^)/
<civodul>funding for 5 devs
<janneke>and Guix is mentioned too
<janneke> if only my Guile build reproduces
<jmd>janneke: Git it neutered. Then it can't!
<civodul>janneke: yup, we need to get the attention of wingo and mark_weaver!
<janneke>civodul: i should be almost there...
<janneke>now only having trouble with 2 .go files so it seems...but finding/bisecting down to the problem is a time-wise nontrivial task
<civodul>janneke: you mean the patch leads to miscompilation issues?
<janneke>no, some files still are nondeterministic...i tried understanding and then commentting-out bits...but all of guile needs to be rebuild to find the nondeterminism
<janneke>when i make changes and run guild by hand, it's always deterministic. i'm at loss at how nondeterminism enters in some cases
<civodul>were you able to diff them?
<janneke>yes, i can diff the build and the -check disasseblies
<janneke>now just trying with two whole files commented-out...see where that goes
<civodul>so how do those two .go files differ?
<civodul>generated identifiers or something else?
<janneke>civodul: it looks like generated identifiers...but i find it hard to tell from the disassembly
<Apteryx>Anyone else getting the following error: "X.509 certificate of '' could not be verified" after upgrading their guix?
<Apteryx>nss-certs is part of my config.scm.
<Apteryx>I could use "--no-check-certificate" but I'd rather understand why this happens?
<rekado>Apteryx: I had this too. Is the daemon running in an environment in which SSL_CERT_DIR is set?
<Apteryx>rekado: It was started automatically, how can I verify that?
<rekado>(maybe we should update the systemd unit file for the daemon such that SSL_CERT_DIR is set.)
<rekado>Apteryx: how did you start it?
<rekado>are you using systemd?
<Apteryx>I just rebooted.
<Apteryx>No systemd. Shepherd?
<Apteryx>I have no idea how services are start, haven't investigated that part of the system yet :) But I'm using the lightweight desktop base config, which I believe only manage services with Shepherd, AFAIU.
<Apteryx>s/start/started, s/manage/manages/
<rekado>oh, so you’re using GuixSD?
<rekado>I haven’t tried using the daemon with SSL_CERT_DIR on GuixSD yet (haven’t upgraded).
<Apteryx>rekado: Yes, I'm on GuixSD
<Apteryx>Could it simply be that the cert for "" truly is invalid (expired, maybe?) How would I check that?
<rekado>you may have to install nss-certs into the root user’s profile
<rekado>but I’m not sure about this as I haven’t tried it myself
<rekado>ACTION needs to go back to studying
<Apteryx>rekado: OK. Good luck with the sudies!
<jmd>albertoefg: hi
<albertoefg>in website it says guixsd doesn't support some packages for example kde applications
<albertoefg>hi jmd
<albertoefg>but you guys are packaging everyday
<albertoefg>so i guess that is constantly changing
<jmd>I think some kde things have been packaged.
<jmd>albertoefg: Can you give me a reference to that statement?
<albertoefg>yes give a minute
<albertoefg>GNOME, Xfce, and Enlightenment are available (see Desktop Services), as well as a number of X11 window managers. However, some graphical applications may be missing, as well as KDE.
<jmd>I think that is refering to the display managers.
<jmd>The applications have been packaged (at least many of them have). But you can't actually log in to a kde-desktop-environment.
<jmd>... at least not out of the box.
<albertoefg>ah i see :)
<albertoefg>i use gnome anyway
<Apteryx>jmd: studies :D
<jmd>Yeah I think most people here prefer Gnome over Kde. That's why not it's had more attention.
<albertoefg>the thing is i found guixsd installation really complicated :(
<albertoefg>when i saw i thought oh man is like parabola
<jmd>albertoefg: Really? Can you elaborate on what you found difficult.
<albertoefg>i tryed installing parabola on gnome boxes
<albertoefg>haven't been successful
<jmd>What did you find complicated about GuixSD installation?
<albertoefg>so it is really similar to parabola
<jmd>I'm afraid I'm not familiar with parabola, so you will have to enlighten me.
<albertoefg>parabola is arch but FSF apprr
<albertoefg>only free software
<jmd>I don't know arch either :(
<albertoefg>arch Linux?
<jmd>I've heard of it, but never used it.
<albertoefg>oh i see
<jmd>What did you find difficult about installing GuixSD?
<albertoefg>well i have my hard drive encrypted with lvm or not sure what so i cant install another distribution
<albertoefg>whan i do is try them with gnome boxes
<jmd>GuixSD doesn't support booting from LVM (yet).
<albertoefg>and when i tryed installed parabola i could not make it work
<albertoefg>so i am not sure what i did wrong
<albertoefg>that is what i think is hard
<albertoefg>i am not able to know if i did right or not
<jmd>I'm confused. I asked you about GuixSD but you keep on talking about parabola.
<albertoefg>yes because installation is really similar
<albertoefg>and the hard part is as only terminal is used
<albertoefg>with commands i don't know
<jmd>Tell parabola to change their installation procedures. then it won't be similar. So then you will find GuixSD easy.
<albertoefg>i am not sure if i did right or wrong
<albertoefg>lol jmd :)
<jmd>As it happens, I'm working on a graphical installer for GuixSD.
<albertoefg>oh great :D
<jmd>So I'd be interested to know *specifically* what you found hard.
<albertoefg>oh just that is not graphical :)
<albertoefg>and not exactly that but
<albertoefg>not to know what to expect
<albertoefg>let me give u an exa.
<jmd>yes please
<albertoefg>With the target partitions ready and the target root mounted on /mnt, we’re ready to go. First, run:
<albertoefg>herd start cow-store /mnt
<albertoefg>This makes /gnu/store copy-on-write, such that packages added to it during the installation phase are written to the target disk on /mnt rather than
<albertoefg>Now there is nothing wrong with that
<albertoefg>but for me is difficult as i dont know what to expect or how long will it take
<albertoefg>and also i don't know if something is not right
<albertoefg>i understand i am the problem
<albertoefg>because i lack the knowledge
<jmd>They general convention in operating system design, is that if everything is correct, then the command will silently succeed.
<jmd>However if there is a problem, then a warning/error message will be emitted.
<albertoefg>and thats why i say i found installation complicated
<albertoefg>oh i see jmd
<albertoefg>for example yesterday i faced this problem
<albertoefg>Create a disk image that will hold the installed system. To make a qcow2-formatted disk image, use the qemu-img command:
<albertoefg>qemu-img create -f qcow2 guixsd.img 5G
<albertoefg>This will create a 5GB file.
<albertoefg>i did that my terminal was in the same folder as guix
<albertoefg>but i didn't know how to tell to use guixsd-usb-install-0.11.0.system.xz’
<albertoefg>so file was blank
<jmd>Actually, I have never tried installing in a VM, so I don't actually know either.
<albertoefg>it is okay
<albertoefg>i know is my fault trying things before understand how they work :)
<jmd>I don't think it's your "fault".
<albertoefg>i was just trying to explain you what i meant for difficult
<jmd>The only way to understand something is to try it.
<albertoefg>i don't think is guixSD fault
<albertoefg>is not software for home users
<jmd>Well it is supposed to be simple for everyone. So if you have any suggestions how to make it easier I'd be interested to hear.
<albertoefg>oh i normally found video tutorials easy so u can see exactly what happens in terminal and the person explains what is going on :)
<Apteryx>jmd: I for one found the GuixSD install procedure enlighting and empowering (thanks to the good info manual). But command line is not for everyone. I have coworkers, programmers, mind you, that are horrified at the idea of having to use a terminal.
<albertoefg>:( ok i am sorry i wasn't trying to speak bad of anyone nor guix
<Apteryx>albertoefg: Didn't get it that way! It's nice to get feedback, whatever it is!
<Apteryx>If GuixSD is to appeal to larger demographics it will need to become easier to install for sure.
<albertoefg>i will try to installation again after breakfast
<Apteryx>albertoefg: OK! The manual is your friend, and don't hesitate to ask questions here as well.
<jmd>The manual is your friend, and the terminal is your servant. You tell it what to do and it does it.
<Apteryx>Is there a way I can list the applications installed *globally* rather than in my user profile?
<Apteryx>I'd like te verify that nss-certs is well installed.
<rekado>Apteryx: in GuixSD you can add packages to the system profile.
<Apteryx>rekado: The system profile is this: /run/current-system/profile? Is it only modifiable through a "guix system reconfigure" ?
<albertoefg>is wayland available on guixsd
<Apteryx>albertoefg: A "guix package --list-available=wayland" tells me that it is.
<albertoefg>oh let me use that
<Apteryx>You can get a summary of all the packages command by doing a "guix package --help".
<Apteryx>"package commands"*
<Apteryx>rekado: I was looking for the equivalent of "guix package --list-installed", but for the system profile rather than my user profile. Is this possible?
<jmd>albertoefg: So if I understand your correctly, you prefer an interface where you get an *explicit* confirmation of the success of each command as you issue it?
<albertoefg>i think that it might be too much
<Apteryx>Found my answer: guix package -p /run/current-system/profile/ -I :)
<albertoefg>maybe in documentation could be a you can expect something like this
<albertoefg>or u can check u did right by running
<albertoefg>u told me u were working on a graphics installer so
<albertoefg>is probably unnecessary also
<Apteryx>hmm, nevermind, the /run/current-system/profile is *my* profile.
<rekado>Apteryx: no, this is the system profile.
<Apteryx>Arg, sorry for the confusion, but /run/current-system/profile is the system profile.
<jmd>albertoefg: Right.
<rekado>Apteryx: you change it by modifying your operating system configuration.
<Apteryx>rekado: yes! Got my output confused.
<rekado>Apteryx: to make the changes take effect you have to reconfigure.
<jmd>albertoefg: Graphical user interfaces a finicky things.
<jmd>They can easily annoy users.
<Apteryx>rekado: Thanks! And sorry for interrupting your studies :D
<jmd>Whenever I use one I'm constantly bombarded with yes/no questions.
<jmd>and I always find myself worring: "I wonder what it's actually going to do if I say yes?"
<jmd>For that reason I think most people prefer a command like interface where the *user* explicitly says what should be done.
<jmd>However some people have expressed interest in a gui - so I want to know exactly what they expect in one. What would you expect?
<rekado>I find command line interfaces difficult to explore. ‘--help’ isn’t always helpful as the scope of commands grows. In my opinion, a GUI should help users to assemble a series of commands by initially hiding complexity and revealing it step-wise in a controlled fashion.
<rekado>Apteryx: no problem. I’m not very successful right now anyway :)
<Apteryx>Ah. What is it that you are studying?
<Apteryx>Still struggling with this "" cert problem: Should I file a bug?
<Apteryx>Maybe one thing that I did before this problem occured was to point my /root/.config/guix/latest to ~/.config/guix/latest as recommended in the manual ("If you are the sole user of your system, you may also
<Apteryx>consider pointing the ‘/root/.config/guix/latest’ symlink to point to
<Apteryx>‘~/.config/guix/latest’; this way it will always use the same ‘guix’ as
<Apteryx>your user does.
<jmd>rekado: I agree that some commands have poorly designed command sets.
<jmd>rsync is a classic example.
<jmd>Part of the problem is, that as an application grows, its organisation of its commands needs to be reorganised.
<jmd>But developers of a command line interfaces are reluctant to do that because of backward compatibility.
<jmd>Whereas gui developers usually don't care. and will radically change the interface on each release.
<albertoefg1>ok so i deleted /gnu and /var/guix
<jmd>Both approaches have advantages and disadvantages.
<albertoefg1>what else should i delete to reinstall completely?
<albertoefg1>i remember it was somethting about a profile
<Apteryx>albertoefg1: What kind of install are you doing? Guix over an existing system?
<albertoefg1> yes
<jmd>Apteryx: He said on a VM.
<albertoefg1>sorry i forgot to explain that
<albertoefg1>i will reinstall guix on fedora
<albertoefg1>and later install guixsd on VM
<Apteryx>I'm not familiar with installing Guix on a foreign distro, but glancing over the installation section of the manual, it seems that you'd have to remove /gnu/store, /var/guix and ~/.guix-profile to undo the actions there, +++ PATH, services, etc.
<albertoefg1>ok :) Apteryx thanks
<jmd>From what I recall about foreign distro installation, the biggest hassle is getting the build daemon set up
<albertoefg1>ok so i did erased everything
<albertoefg1>now i did
<albertoefg1> tar --warning=no-timestamp -xf \\
<albertoefg1>> guix-binary-0.11.0.x86_64-linux.tar.xz
<albertoefg1>and then i did mv var/guix /var/ && mv gnu /
<albertoefg1>then i did number 3
<albertoefg1>3.- Make root’s profile available under ~/.guix-profile:# ln -sf /var/guix/profiles/per-user/root/guix-profile \\ ~root/.guix-profile
<albertoefg1>nothing showed on my terminal. So far so good right?
<albertoefg1>number 4 is what i am not sure i understand
<albertoefg1>it links here
<Apteryx>Oh, looks like a regression which affected substitute, which was fixed in master 8 hours ago by Ludovic: 166ba5b * substitute: Disable HTTPS certificate verification.
<albertoefg1>only I use my pc so only don't need 10 build users
<Apteryx>I'll try rebuilding my guix
<jmd>albertoefg: It's not a question of how many people use the machine.
<albertoefg1>my question is: should i just do the command like that any way? do i have to do it as a root?
<albertoefg1>this command
<albertoefg1># groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \\ -d /var/empty -s `which nologin` \\ -c "Guix build user $i" --system \\ guixbuilder$i; done
<jmd>Having more than one build users has optimisation advantages.
<jmd>yes it must be done as root.
<albertoefg1>i understand jmd, so basically don't touch it and do it as root ok give me a second
<albertoefg1>ok now i have guixbuilder10 and guixbuilder9 and so on
<albertoefg1>what do i do next? go back to installation page or continue on this page and do # guix-daemon --build-users-group=guixbuild
<jmd>I can't remember. What do the instructions say?
<albertoefg1>the instructions say: 4.- Create the group and user accounts for build users as explained below (see Build Environment Setup).
<jmd>So you have done that.
<albertoefg1>so i don't have to do
<albertoefg1>this The guix-daemon program may then be run as root with the following command: # guix-daemon --build-users-group=guixbuild
<albertoefg1>oh sorry i do
<albertoefg1>5. Run the daemon, and set it to automatically start on boot.
<albertoefg1>so my problem is number 7
<albertoefg1>To use substitutes from or one of its mirrors (see Substitutes), authorize them:
<albertoefg1># guix archive --authorize < ~root/.guix-profile/share/guix/
<albertoefg1>[root@despacho info]# guix archive --authorize < ~root/.guix-profile/share/guix/
<albertoefg1>warning: failed to install locale: Invalid argument
<albertoefg1>what is going on :/
<alezost>albertoefg1: warning is not an error, you can ignore it for now; it is explained later in the manual how to get rid of this locale warning
<albertoefg1>oh thanks!
<albertoefg1>but then i do:
<albertoefg1>[root@despacho info]# guix package -i hello
<albertoefg1>warning: failed to install locale: Invalid argument
<albertoefg1>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<Apteryx>Is the guix-daemon running?
<albertoefg1>i did this
<albertoefg1># guix-daemon --build-users-group=guixbuild
<albertoefg1>and this
<albertoefg1># cp ~root/.guix-profile/lib/systemd/system/guix-daemon.service \\ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon
<albertoefg1>but as u asked i did this manually: Otherwise, you can still start the daemon manually with:# ~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild
<alezost>albertoefg1: I think guix-daemon is not running, look at the output of "systemctl status guix-daemon"
<albertoefg1>and when i did it manually nothing happened terminal just stayed like working
<alezost>albertoefg1: you need to start guix-daemon before using "guix ..." commands, either manually or with systemd
<Apteryx>albertoefg1: Did you run it with "#" as you showed us? if so you didn't run anything as this is the comment symbol
<Apteryx>albertoefg1: Also the manual says you should run this command as root
<albertoefg1>i know it coments
<albertoefg1>i am as root
<albertoefg1>systemctl status guix-daemo
<albertoefg1>● guix-daemo.service
<albertoefg1> Loaded: not-found (Reason: No such file or directory)
<albertoefg1> Active: inactive (dead)
<albertoefg1>is dead
<albertoefg1>should i reboot so it starts?
<alezost>albertoefg1: "terminal just stayed like working" ← this is normal; the daemon does not quit, it just stays running
<albertoefg1>so alezost start it as root on one terminal and continue installation as root an another terminal?
<alezost>albertoefg1: yes, or start it with systemd: "systemctl start guix-daemo"
<alezost>assuming you called it "guix-daemo", not "guix-daemon"
<alezost>but you probably didn't, and it was just a typo
<albertoefg1>oh right my mistake
<albertoefg1>this is the output
<Apteryx>(use for that :))
<albertoefg1>systemctl status guix-daemon
<albertoefg1>● guix-daemon.service - Build daemon for GNU Guix
<albertoefg1> Loaded: loaded (/etc/systemd/system/guix-daemon.service; enabled; vendor pres
<albertoefg1> Active: active (exited) (Result: exit-code) since sáb 2016-11-12 13:00:14 CST
<albertoefg1> Main PID: 1089 (code=exited, status=203/EXEC)
<albertoefg1> CGroup: /system.slice/guix-daemon.service
<albertoefg1>nov 12 13:00:14 despacho.despacho systemd[1]: Started Build daemon for GNU Guix.
<albertoefg1>nov 12 13:00:14 despacho.despacho systemd[1]: guix-daemon.service: Main process
<albertoefg1>nov 12 13:43:33 despacho.despacho systemd[1]: Started Build daemon for GNU Guix
<albertoefg1>i dont know how to use give me a minute :)
<alezost>so it exited for some reason
<alezost>does it run after "systemctl restart guix-daemon"?
<albertoefg1>so i am on fedora and got this
<albertoefg1>SELinux is preventing (x-daemon) from execute access on the file guix-daemon.
<Apteryx>I'm facing the regression that my guix cannot uses substitute from because of the HTTPS regression that has already been fixed in master; As a result, I can't even update my guix using the usual "guix pull" (fails with the invalid cert error). Can I get out of this catch22 situation using my git checkout?
<albertoefg1>should i disable selinux?
<alezost>Apteryx: by "./pre-inst-env guix pull", but actually if you use a git checkout, you don't need to "guix pull", just update your checkout (git pull) and "make" it
<alezost>albertoefg1: I know nothing about selinux, is it started if you run it manually? (guix-daemon --build-users-group=guixbuild)
<Apteryx>alezost: Yes, I was not yet comfortable using git checkout as my ~/.config/guix/latest. I remember someone running "guix gc" and borked its system.
<Apteryx>Thanks, I'll try the "./pre-inst-env guix pull" :)
<alezost>Apteryx: "guix gc" problem does not relate to the way you run guix (from a checkout or from a "guix pull"-ed code)
<alezost>"guix pull" is really not needed if you use a git checkout
<albertoefg1>~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild
<albertoefg1>yes it starts :)
<alezost>albertoefg1: ok, now you can try "guix build --dry-run hello"
<Apteryx>alezost: OK. I'll just point my ~/.config/guix/latest to it then :). I thought there was something special about a git checkout that if I ran "guix gc" it would collect stuff which guix rely on, such as guile, and break the system.
<alezost>Apteryx: no, it doesn't matter, both "guix pull" and latest git checkout have the same code
<albertoefg1>yes it worked!
<Apteryx>Not sure about the exact details of that issue as I remember it though. I'm happy to be mistaken about it!
<Apteryx>albertoefg1: Nice!
<albertoefg1>this was the output:
<albertoefg1>[root@despacho alberto]# guix build --dry-run hello
<albertoefg1>warning: failed to install locale: Invalid argument
<albertoefg1>substitute: warning: failed to install locale: Invalid argument
<albertoefg1>substitute: warning: 'https_proxy' is ignored
<albertoefg1>and then a lot of this:
<albertoefg1>substitute: updating list of substitutes from ''...
<albertoefg1>and finally
<albertoefg1>substitute: updating list of substitutes from ''... 100.0%
<albertoefg1>The following file would be downloaded:
<albertoefg1> /gnu/store/zy5aanymkq37l91yhq0xa6rddv1skl6s-hello-2.10
<alezost>albertoefg1: it is explained in the manual (info "(guix) Application Setup") how to solve the locale warning; as for the https_proxy thing, I've never seen it, the rest is ok. So now you can try to install something
<albertoefg1>great :)
<albertoefg1>it will dowload a lot of stuff right?
<albertoefg1>it works!!!
<albertoefg1>i succesfully installed hello !
<albertoefg1>hi len__
<len__>I am trying to get my guixSD to some basic functionality :)
<len__>but I had to flash bios of my thinkpad before I could change wifi card from intel to atheros
<len__>atheros wifi was not white listed on bios
<len__>intel wifi does not have libre drivers
<alezost>albertoefg1: great! as for the problem with guix-daemon, systemd and selinux, I can't help :-(
<albertoefg1>it is okay alezost :)
<albertoefg1>now to use it with emacs :)
<alezost>albertoefg1: do you mean you wish to try "M-x guix-..." commands?
<albertoefg1>yes it seems from this video
<albertoefg1>emacs is really good for guix
<alezost>for that you need to install both emacs and guix to your profile
<albertoefg1>i have emacs
<albertoefg1>but i should installed from guix
<len__>I can not install wpa_supplicant it says that it is unrecognised package
<alezost>albertoefg1: well, fedora's emacs will not find *.el files inside ~/.guix-profile, so you need to use guix's emacs if you want to use emacs packages from guix (including emacs interface for guix itself)
<alezost>for example, if you do "guix package -i magit", and start fedora's emacs, you will not "M-x magit-status" command
<alezost>*will not get
<albertoefg1>oh thats ok :)
<alezost>but if you also install emacs, and run it, it will find magit files
<albertoefg1>so everything should be installed and used from guix
<alezost>no, but if you want to use emacs packages from guix you have to use guix's emacs
<albertoefg1>that was kind of what i meant :)
<albertoefg1>i have to go :)
<albertoefg1>thanks for the help
<alezost>len__: in guix it's name is "wpa-supplicant", not "wpa_supplicant"
<alezost>in Guix (more generally Guile/Scheme/Lisp) world it's a convention to use "-" instead of "_"
<alezost>actually wpa_supplicant should be available in the installation image
<alezost>albertoefg: Guix's Emacs is not worse than your Fedora's Emacs; it is a usual Emacs, and it will also find your (M)ELPA packages, if that's your concern
<len__>alezost: lol
<len__>one more qustion, what is the best way to learn guix
<rekado>len__: the manual.
<len__>i did wget it ...
<alezost>len__: wget? but you already have it if you use guix; just run "info guix" (or "M-x info" if you use Emacs)
<len__>forgot about it ...
<len__>It lasted more than a month since installation and than flashing new bios ...
<rekado>for work I now must publish status updates to Google docs each week. Does anyone know of a tool that allows me to do this a) without a google account and b) from the command line / within Emacs?
<necrophcodr>I've install Guix on a non-GuixSD system, and I'm wondering if it's possible to take my user-profile with me to another location?
<necrophcodr>But without all the files and folders and structures
<necrophcodr>Just a general file that can recall the exact generation on a different platform
<rekado>necrophcodr: this can be achieved with manifests
<rekado>a manifest is a file in which you declare the contents of your profile
<rekado>you can instantiate a manifest with ‘guix package --manifest=/path/to/manifest.scm’
<rekado>alternatively, you can export the closure of your profile and import the exact same binaries on another Guix system.
<rekado>here’s an example of a manifest:
<rekado>and here’s how to export the closure of your profile:
<rekado>guix archive --export --recursive \\
<rekado> $(readlink -f /path/to/.guix-profile) | \\
<rekado> gzip --stdout - > my-profile.nar.gz
<rekado>that will take a while but in the end you’ll have everything in one gzipped file which you can import on the target.
<jje>got a problem with guix pull fails with signer-not-found invalid for the X.509 cert. how does one fix this?
<rekado>jje: are you using GuixSD or Guix on top of some other distribution?
<superflip>I am trying to run gnome on Debian stable using guix. So I ran "guix package -i gnome". When I try to run gnome using "DISPLAY=:1 gnome-session", I get "dbus-update-activation-environment: error: unable to connect to D-Bus: /gnu/store/3s8ifq6vpdykaw695k4b083xwrsvc3k5-dbus-1.10.8/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed." and "** (gnome-session-failed:3532): WARNING *
<superflip>What am I doing wrong? Thanks.
<Apteryx>Just to be sure about one thing: When I use a git checkout as my ~/.config/guix/latest, to update, I just run
<Apteryx>git pull... Then I need to rebuild guix if I want the new guix version using "guix environment guix", "make -j3 check"?
<Apteryx>Not sure I need the "guix environment guix" part.
<necrophcodr>rekado, oh my god, that was amazing. thank you so much for the explanation of how it works, and the links for me to read on about it. i surely will too! this will help me be a lot more productive at work, thanks!
<Apteryx>This means I'd never need to issue "git pull" anymore.
<Apteryx>err, "guix pull".
<Apteryx>jje: This was a regression which was fixed in the master branch.
<rekado>jje: I’m still updating to the latest version, but the problem you face is likely caused by not having a certificate store in a place where guix-daemon can find it.
<rekado>Apteryx: oh, good to know :)
<jje>ok can i amend that some how rekado ?
<Apteryx>jje: The problem is that if your currently installed guix version exhibits the problem, you won't be able to run "guix pull" to refresh it...
<rekado>fixed in 166ba5b
<rekado>jje: one way to do this is to install nss-certs (if you don’t have it yet) and point SSL_CERT_DIR at it in the environment in which guix-daemon runs.
<Apteryx>rekado: Yep, that's the commit.
<jje>thank you i will try that rekado
<Apteryx>rekado: This won't do. The certificates are installed and the envars point to these. I believe the problem is that doesn't have a certificate and it was being validated. The commit you referenced turns validation off for certain situations where it doesn't matter.
<rekado>necrophcodr: I’m glad you found this helpful. That’s the documentation for the Guix deployment at the institute where I work. Note that all instances of ‘guixr’ should be ‘guix’ (unless you’re on one of our institute’s machines.)
<rekado>Apteryx: hmm, I had a problem with cert checking for substitutes on Friday at work and I fixed it by setting SSL_CERT_DIR in the daemon’s environment.
<rekado>can’t check this right now, though.
<necrophcodr>rekado, which i'm not, but i figured as much. i'm using per-user profiles, can the manifest files be used from those directly then? that is, the manifest files in, for instance, $HOME/.guix-profile/manifest ?
<necrophcodr>they appear to, but i wanted to be sure before i test it out and ruin test environments too much ;)
<civodul>Apteryx, rekado: re the TLS error in 'guix substitute', i fixed it earlier today
<civodul>i sent a message today, though i can't find it
<rekado>necrophcodr: I don’t know. I think they are in a different format from what ‘guix package --manifest’ expects, but I haven’t tried this recently.
<rekado>civodul: thanks!
<necrophcodr>rekado, they do appear to be. i'll do my duty and dig deeper. thanks for providing a useful stepping stone to greatness though!
<Apteryx>civodul: Yes I found about it in the log
<Apteryx>Thanks for fixing it!
<civodul>yeah, sorry for messing up with it!
<necrophcodr>rekado, it says in the docs that "file must return a manifest object, which is roughly a list of packages: ", which it appears the `manifest` file does, so it should work :) i'll do a bit of testing, but i've got a good feeling about this guix deal.
<Apteryx>I've linked my ~/.config/guix/latest to ~/src/guix (my git checkout). Does that mean that any guix commands from now on get run from the binaries under ~/src/guix?
<Apteryx>And if I restart the guix-daemon using "sudo hurd guix-daemon restart" it will use binaries from my checkout as well?
<Apteryx>s/hurd/herd ;)
<Apteryx>I just tried "sudo herd restart guix-daemon", then "guix build hello", but I still get the cert error. Maybe I have to logout & back in after pointing ~/.config/guix/latest to my git checkout?
<Apteryx>Because right now, `which guix` returns "/run/current-system/profile/bin/guix", which is a link to a store item.
<Apteryx>(rather than my git checkout)
<civodul>right, but then this 'guix' program sets its load path to ~/.config/guix/latest
<jonsger>oh very nice, the new news section and feed :)
<Apteryx>civodul: OK. Thanks. Not sure why I'm still getting the same error though :( I rebuilt successfully the guix in my checkout like 2 hours ago.
<Apteryx>Maybe I need to do "guix system reconfigure /etc/config.scm"?
<Apteryx>Except I can't :D (same error)
<Apteryx>rekado: Maybe I also need to set this SSL_CERT_DIR like you did. Mine currently points to /etc/ssl/cert. Do you remember the value you had to set it to to resolve your problem?
<rekado>Apteryx: I set it to ~/.guix-profile/etc/ssl/certs after installing the nss-certs package.
<Apteryx>rekado: OK. Tried, but cannot even install nss-certs.
<Apteryx>Here's some debug output:
<Apteryx>AFAIU, my guix should be the one I built from my git checkout, but I somehow doubt that.
<Apteryx>civodul: Just read you message on the mail list, looks like I should use "guix system reconfigure --no-substitute /etc/config.scm". I'll try that.
<civodul>Apteryx: correct
<civodul>you have to use --no-substitutes to work around the bug until you've successfully reconfigured
<necrophcodr>rekado, it didn't work to use the existing one, but rebuilding it from scratch was surprisingly easy to do, so i'll keep a profile.scm file along with me instead, it seems to be a lot more useful anyway. thanks again!