IRC channel logs


back to list of logs

<sapientech>going to add some guile modules, should i add them to guile-libs, or directly to guix?
<davexunit>jeaye: a nixops equivalent is still on the TODO list
<davexunit>I'm *very* interested in such a thing, and did some very preliminary work studying the nixops source and making a basic framework for Guix, but that was awhile ago and I haven't had time to hack on it since.
<jeaye>Thanks for the followup.
<catonano>In the node-type record, in (guix graph), I don't understand what the "convert" field is for :-/
<habs>When I try to guix pull today I get this "failed to unpack source code" error: But I don't think it's a network problem because I can unpack the ...j58j9x-guix-latest.tar.gz just fine manually with tar. How can I debug / fix this?
<lfam>habs: I just did the unpack part of `guix pull` successfully. Is this Guix on another distro or GuixSD? What processor architecture?
<habs>lfam: This is on GuixSD, on x86_64. I was able to guix pull yesterday fine, but now this happens every time I try today
<lfam>habs: It works for me on that platform. Hm.
<lfam>habs: What's the value of `realpath $(which tar)` for you?
<lfam>And, can you use that tar to create and extract an archive locally?
<balduin>if I want to create a new Guix package definition in which directory should I place it to be able to build it with Guix
<habs>lfam: Output is "/gnu/store/ggmmcw327ny831gqd7zvi3hpl5fm23mn-tar-1.28/bin/tar". I can use it to create and extract tars fine.
<lfam>habs: I'm stumped. Please send a report to
<lfam>habs: You're not out of disk space, right?
<mark_weaver>balduin: read about the GUIX_PACKAGE_PATH environment variable in section 7.5 (Package Modules) of the guix manual
<balduin>@mark_weaver "Users can invoke commands such as guix package and guix build with the -e option so that they know where to find the package." what argument does the -e option wants? A path? A module name?
<habs>lfam: No, still have plenty of disk space. I'll report it to the list some time soon, thanks for the help
<lfam>balduin: It takes a Scheme expression
<lfam>For example: guix build -e '(@@ (gnu packages tex) texlive-texmf)'
<lfam>balduin: By the way, that was probably a bad example for me to show you. That package will take several gigabytes if you build it. I chose it because I could copy it out of my shell history
<lfam>balduin: This is a more appropriate example: guix build -e '(@@ (gnu packages base) hello)'
<balduin>@lfam okay thanks, but this does not really help me
<lfam>balduin: What do you need help with?
<balduin>I want to create a hello package which uses version 2.9 instead of 2.10
<OrangeShark>balduin: if you want to have like your own personal packages, you can set an environment path to a directory with your own package definitions
<balduin>what I currently try to do is: guix build myhello -L /home/user/Packages/
<balduin>I want to build myhello which is the hello package with version 2.9
<OrangeShark>in my .bash_profile, I have: export GUIX_PACKAGE_PATH=$HOME/guix-packages
<balduin>in the /home/user/Packages I have a myhello.scm
<balduin>@OrangeShark thanks, but I want to keep it simple for now, without modifying my .bash_profile
<lfam>balduin: You can do `GUIX_PACKAGE_PATH=~/Packages guix build hello@2.9` if you don't want to modify your ~/.bash_profile
<OrangeShark>okay, so the problem is it not finding the package defined in myhello.scm?
<balduin>yes, I get the following error messages:
<balduin>guix build: warning: failed to load '(myhello)':
<balduin>ERROR: no code for module (myhello)
<balduin>guix build: error: myhello: unknown package
<balduin>in the myhello.scm I used: (define-module (gnu packages myhello)
<balduin>and (define-public myhello...
<lfam>balduin: Try changing (gnu packages myhello) to (Packages myhello) and then setting GUIX_PACKAGE_PATH to ~/Packages
<OrangeShark>you can name the module just myhello
<lfam>Oh, OrangeShark is correct
<lfam>My suggestion won't work
<OrangeShark>module named (gnu packages myhello) means it in the directory gnu/packages/myhello
<balduin>I exported the package path: $ echo $GUIX_PACKAGE_PATH
<balduin>I tryed this one: (define-module (Packages myhello)
<mark_weaver>make it (define-module (myhello)
<mark_weaver>and make the filename /home/user/Pacakges/myhello.scm
<balduin>@mark_weaver thanks that works
<sapientech>trying to create a trival build, and i need to chdir to the source dir, but (source (assoc-ref %build-inputs "source")) is not producing the right dir
<mark_weaver>that's good :)
<balduin>now, I have a problem with the sha256 value
<sapientech>the wildcard values are different
<balduin>(sha256 "ecbb7a2214196c57ff9340aa71458e1559abd38f6d8d169666846935df191ea7")))
<balduin>I changed it to that
<sapientech>balduin: it should show you what it should be, just change it to that
<sapientech>when you build
<mark_weaver>balduin: replace that string with the output of "guix hash hello-2.9.tar.??"
<mark_weaver>where ?? is the appropriate extension
<sapientech>ah cool, thats a better way :)
<OrangeShark>there is also "guix download" to download the tar ball and then give you the hash :)
<balduin>I did: $ guix hash ~/Downloads/hello-2.9.tar.gz
<OrangeShark>it typically (sha256 (base32 "hash"))
<OrangeShark>I think that the default for guix hash
<balduin>okay, it worked
<balduin>I did the following command: $ guix build myhello
<balduin>but it starts to download binutils, findutils, readline even linux-libre. I think it does the bootstrap process, but why?
<balduin>I already have a guix environment build yesterday and I am running guix on archlinux, therefor I do not want to have packages like linux libre
<balduin>the same goes with: $ guix package -i myhello
<lfam>Is this the first Guix package you've had to build from source?
<lfam>balduin ^
<balduin>I was building the hello and bc package before
<lfam>And they were compiled, as opposed to substituted with a binary from our build farm?
<balduin>no, I compiled them on my machine
<lfam>I'm not an expert on the low-level internal dependencies... I think it's harmless though. If you are downloading them, they are required by what you are trying to do
<balduin>that is a little bit an overhead
<balduin>I was running `guix gc` today. I am not sure if this has something to do with it
<mark_weaver>guix doesn't use anything from the host OS when compiling things. in fact, the compilations are done in an isolated container where it can only access guix store items.
<mark_weaver>you need the toolchain and compilation environment to compile hello
<balduin>@mark_weaver yes, I know that, but I build the complete toolchain and environment before.
<mark_weaver>and yes, "guix gc" would have deleted anything that is not a run-time dependency of things accessible from a GC root, which are things like profiles, and so one
<mark_weaver>*and so on
<mark_weaver>so it will delete mere build dependencies
<balduin>okay, make sense
<mark_weaver>you can add more GC roots by adding symlinks to /var/guix/gcroots
<mark_weaver>so I'm afraid you'll need to rebuild your toolchain and core libraries again, unless you use binary substitutes
<mark_weaver>I have one machine where I never use substitutes, for improved confidence in the security, and I need to be very careful about "guix gc" on that machine
<balduin>@mark_waver: okay, that is not that great. There should be a warning in the documentation.
<mark_weaver>linux-libre is needed for its headers. you shouldn't need to compile the kernel itself
<mark_weaver>an extra word of warning in the "guix gc" docs might be appropriate. would you like to email about it, so we don't forget?
<balduin>@mark_weaver yes, I will do that
<balduin>@mark_weaver how do you work more with substitutes (binary packages) instead of allways compiling packages?
<balduin>I read this:
<mark_weaver>I'm not sure I understand the question
<mark_weaver>are you asking how to enable them on your system?
<balduin>yes, exactly
<mark_weaver>it's explains how on that page. "guix archive --authorize <" is the key command
<balduin>okay, so I did it right.
<mark_weaver>but it's not working?
<mark_weaver>maybe it's because you're using an old version of guix, for which substitutes are no longer available on
<mark_weaver>the usual way to use the latest package definitions is to run "guix pull", although the way I much prefer is to build guix from a git checkout and use that directly
<balduin>Hmmm....I used:
<mark_weaver>(note that "guix pull" only updates guix for the user who runs it, by setting the symlink ~/.config/guix/latest
<mark_weaver>balduin: what is the output of "guix --version" ?
<balduin>$ guix --version
<balduin>guix (GNU Guix) 0.11.0
<balduin>should be the newest or?
<mark_weaver>that's the newest, released very recently. should have all the substitutes for that one.
<mark_weaver>when you compile things, do you see messages about substitutes?
<balduin>I use mostly: guix package -i vim
<balduin>or something to install the software
<mark_weaver>maybe something is wrong with the archlinux package
<mark_weaver>can you tell me the .drv filename of what will be built when you run "guix build -n hello" ?
<mark_weaver>the /gnu/store/...-hello-2.10.drv file? I need the full filename, with has
<mark_weaver>*with hash
<balduin>@makr_weaver I would love to, the only problem is gcc compiling right now, which will take a while.
<mark_weaver>you can run that command from another shell
<mark_weaver>without interrupting the gcc compile
<mark_weaver>if we can solve this problem, you won't have to compile gcc
<mark_weaver>my guess is that the archlinux package is slightly different from our release, e.g. that the bootstrap binaries aren't the same, maybe different execute flag or something
<mark_weaver>and that causes all of the derivations to be different, so it doesn't match what we offer substitutes for
<balduin>okay, this is what happens if I issue the command: $ guix build -n hello
<balduin>;;; note: source file /usr/share/guile/2.0/sxml/ssax/input-parse.scm
<balduin>;;; newer than compiled /usr/lib/guile/2.0/ccache/sxml/ssax/input-parse.go
<balduin>but hello is already installed: $ guix package --list-installed
<mark_weaver>it didn't output anything else?
<mark_weaver>okay, let's pick something you don't already have
<mark_weaver>how about "guix build -n maxima" ?
<mark_weaver>and tell me the /gnu/store/*-maxima-5.36.1.drv filename
<mark_weaver>actually, I can already tell that output filename hash you pasted doesn't match what we have for version 0.11.0
<mark_weaver>my guess is that something is badly wrong with the archlinux package
<balduin>okay, here is the output for di:
<mark_weaver> blocks tor users, so I can't access that link. can you use something else? is one option
<balduin>di: Advanced df like disk information utility:
<mark_weaver>ACTION looks
<mark_weaver>which architecture are you on? x86_64, i686, or something else?
<mark_weaver>okay, I need a few minutes
<balduin>@mark_weaver, sure thanks for helping me.
<mark_weaver>I don't normally use guix on an x86_64 machine, so I need to compile 0.11.0 for it, first, to compare.
<mark_weaver>so it'll be a few minutes
<mark_weaver>it would be good to get to the bottom of this, to find out what's wrong with the archlinux package and fix it.
<mark_weaver>but, if you just want to get guix working sooner rather than later, I can recommend using our binary installer.
<mark_weaver>my main development machines are i686 and mips64el
<balduin>@mark_weaver, I first wanted to test GuixSD in a virtualbox vm, but sadly the guix project does not provide one.
<lfam>balduin: It is possible to install GuixSD in a QEMU vm
<lfam>And the GuixSD installer is itself a GuixSD system
<mark_weaver>we favor qemu over virtualbox because there's a crucial component of virtualbox that requires a non-free compiler to compile it
<mark_weaver>the BIOS maybe? I've forgotten the details
<mark_weaver>okay, I've built guix-0.11.0 on x86_64, and have the output of "guix build -n di" on that machine. the .drv file for di I have matches what was built by, and mismatches what you have on archlinux.. now to trace the mismatch down the dependency graph, to find the culprit
<balduin>@mark_weaver: nice work. I am impressed.
<mark_weaver>balduin: what's the output of: guix build -e '(@@ (gnu packages bootstrap) %bootstrap-guile)'
<balduin>$ guix build -e '(@@ (gnu packages bootstrap) %bootstrap-guile)'
<mark_weaver>okay, that's a mismatch
<mark_weaver>can you find the file named "guile-2.0.11.tar.xz" in the archlinux package? (not in /gnu/store)
<balduin># find / -name "guile-2.0.11.tar.xz"
<mark_weaver>what's the output of "sha256sum /usr/share/guile/site/2.0/gnu/packages/bootstrap/armhf-linux/guile-2.0.11.tar.xz" ?
<mark_weaver>oh, wait, sorry
<mark_weaver>what's the output of "sha256sum /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz" ?
<mark_weaver>forget the first one
<balduin>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0 /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz
<mark_weaver>is the file executable?
<mark_weaver>what is the mode?
<balduin>-rw-r--r-- 1 root root 2885996 Aug 6 11:33 guile-2.0.9.tar.xz
<balduin>it is not executable
<balduin>but, there are some executables in the same directory:
<balduin>$ ls -al
<balduin>total 7240
<balduin>drwxr-xr-x 1 root root 64 Aug 6 11:33 .
<balduin>drwxr-xr-x 1 root root 94 Aug 6 11:33 ..
<balduin>-rwxr-xr-x 1 root root 1425560 Aug 6 11:33 bash
<balduin>-rw-r--r-- 1 root root 2885996 Aug 6 11:33 guile-2.0.9.tar.xz
<balduin>-rwxr-xr-x 1 root root 792448 Aug 6 11:33 mkdir
<balduin>-rwxr-xr-x 1 root root 1369912 Aug 6 11:33 tar
<balduin>-rwxr-xr-x 1 root root 927264 Aug 6 11:33 xz
<balduin>executable are bash, mkdir, tar and xz
<mark_weaver>that's as it should be
<balduin>@lfam: I did not use qemu before and was a little bit confused on how to use and install GuixSD.
<mark_weaver>balduin: what's the output of: guix build --log-file /gnu/store/zbv64d1m6qg8rh53n6kzg0lxcnlb3r8b-guile-bootstrap-2.0
<balduin>$ guix build --log-file /gnu/store/zbv64d1m6qg8rh53n6kzg0lxcnlb3r8b-guile-bootstrap-2.0
<mark_weaver>balduin: can you paste the contents of /gnu/store/59wi50shyr3a5p1h75i6jb4hc50z1jkc-guile-bootstrap-2.0.drv for me to see?
<balduin>$ cat /gnu/store/59wi50shyr3a5p1h75i6jb4hc50z1jkc-guile-bootstrap-2.0.drv
<mark_weaver>balduin: what's the output of: guix hash /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<balduin>$ guix hash /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<mark_weaver>ah, a mismatch!
<mark_weaver>and what about: sha256sum /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<balduin>@mark_weaver is the boostrap process bit-by-bit reproducible for each architecture?
<balduin>the output for the sha256sum: 46950f235cd30d28226c4b61f010bc12df586abd3fd1a3120b73efc6d2d656b2 /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<mark_weaver>guix is designed for that, but not all of our builds are reproducible yet. most notably, guile's build process is non-deterministic. we're working on it, but it's tricky.
<mark_weaver>balduin: okay, so your bootstrap 'bash' is different from ours, and everything else depends on it.
<mark_weaver>balduin: can you verify that it's what archlinux is distributing, and not corrupted on your system?
<mark_weaver>it should match what's in gnu/packages/bootstrap/x86_64/bash, in our git repo or any of our recent releases.
<mark_weaver>(these bootstrap binaries are very rarely changed)
<balduin>it is an archlinux aur package, therefor it was compiled on my system
<balduin>archlinux aur packages are inofficiel packages
<mark_weaver>if the archlinux package replaced our bootstrap binaries, then archlinux users will never be able to use our binary subtitutes, nor compare their builds with other users' builds.
<mark_weaver>well, users of the archlinux aur guix package, anyway.
<mark_weaver>I recommend using our binary installer instead, and ditching this archlinux package
<mark_weaver>it's interesting, though, that the size in bytes of your bootstrap 'bash' matches ours, which makes me suspect that it was not compiled by archlinux, but simply corrupted. can you verify where that 'bash' file came from?
<mark_weaver>can you show me the archlinux package description?
<lfam>A same-size hash mismatch could easily be caused by timestamps. It's worth investigating
<mark_weaver>yeah, but if it was compiled with archlinux's toolchain, it's unlikely that the file size would match. this is a static binary.
<mark_weaver>our bootstrap binaries for x86_64 and i686 were compiled in 2013
<mark_weaver>compiled using guix itself at that time
<mark_weaver>it seems unlikely that the size would match unless archlinux and guix in 2013 happened to use the same version of gcc and libc, for starters
<mark_weaver>this all seems very fishy to me
<mark_weaver>it would also need to be the same version of bash
<mark_weaver>very unlikely
<mark_weaver>balduin: that 'bash' binary should have been copied directly from us. those binaries are included in our source tarballs and git repo, and are never built by 'make'
<mark_weaver>they are literally considered part of the source code
<mark_weaver>in a sense
<mark_weaver>ditto for the other files in that directory
<mark_weaver>I don't see how this could happen, unless it was corrupted somehow
<mark_weaver>the archlinux packager(s) would have needed to go *way* out of their way to recompile those binaries, and if they did, it's unlikely that the size would match
<balduin>@mark_weaver, here is the pkgbuild for the guix archlinux aur package:
<balduin>I am not sure if this has anything to do with it, but this line has drawn my attention: bash_completion_dir="`pkg-config --variable=completionsdir bash-completion`"
<balduin>could this be the reason?
<mark_weaver>balduin: no
<mark_weaver>balduin: I don't see anything in that package definition that could explain this. it looks like the bootstrap bash was simply corrupted (hopefully not deliberately). it would be interesting to use 'diffoscope' to compare the one you have with ours
<mark_weaver>to find out exactly how they diffe
<mark_weaver>I'd also be curious to see what other files in the bootstrap directory differ from ours
<mark_weaver>you can get copies of ours from any recent guix source tarball, or our git repo
<mark_weaver>in the gnu/packages/bootstrap directory
<mark_weaver>balduin: can you please email a copy of that 'bash' to ?
<mark_weaver>specifically: /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<balduin>okay, so how should I do the binary bit-by-bit comparision?
<mark_weaver>diffoscope is a good tool for it
<mark_weaver>balduin: did you build this archlinux aur package locally from that package definition, or did you download a pre-built binary version of this archlinux package?
<mark_weaver>if the latter, can you tell me where to find the same binary package file that you downloaded?
<balduin>all aur packages are compiled.
<balduin>sorry, all aur packages have to be compiled. There is no pre-built binary.
<mark_weaver>very interesting
<balduin>the aur package downloads:, extracts the contents and compiles it on my system.
<mark_weaver>balduin: can you download it, and check the sha256sum of guix-0.11.0/gnu/packages/bootstrap/x86_64/bash in that tarball ?
<mark_weaver>I just did, and I get what it should be, not what you have
<mark_weaver>does archlinux do some automatic processing of installed binaries, or something? like iterating over the filesystem and stripping them?
<balduin>265d2f633a5ab35747fc4836b5e3ca32bf56ad44cc24f3bd358f1ff6cf0779a5 guix-0.11.0/gnu/packages/bootstrap/x86_64-linux/bash
<mark_weaver>that is what it should be
<mark_weaver>which doesn't match what's in /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash
<balduin>@mark_weaver here the diffoscope difference:
<balduin>I am not sure if I used the tool correct. I assume: diffoscope file1 file2
<mark_weaver>we use the 'install' program to install these bootstrap binaries. I wonder if archlinux somehow rigs that program to post-process executable binaries somehow. looks like it.
<mark_weaver>balduin: thanks. looks like you used it correctly.
<mark_weaver>balduin: can you send a copy of /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash to please?
<mark_weaver>(that's me)
<mark_weaver>balduin: can you try running: "install guix-0.11.0/gnu/packages/bootstrap/x86_64-linux/bash /tmp/bash" and then use "cmp" to compare those files to see if 'install' modified it?
<mark_weaver>ACTION curious if archlinux's 'install' program does some magic
<balduin>@mark_weaver: I will send you the bash binary later. I am currently not on my main system.
<balduin>$ cmp guix-0.11.0/gnu/packages/bootstrap/x86_64-linux/bash /tmp/bash
<balduin>$ echo "$?"
<mark_weaver>hmm, okay. well, somewhere along the way it got modified. our Makefile certainly didn't do it.
<mark_weaver>balduin: it's getting late here, so I can't continue this much longer, but for now I would recommend using our binary installer
<balduin>@mark_weaver I completely understand that. Thank you very much for your help.
<mark_weaver>no problem, thanks for helping me investigate this!
<balduin>it was enjoyable :-)
<mark_weaver>balduin: I tried running "strip bash", and found that it made almost the same change that it did on your copy. so I suspect that something ran "strip" on that executable.
<mark_weaver>maybe some automatic part of the archlinux build process, not specified in this individual package definition.
<mark_weaver>balduin: I just asked on the #archlinux channel here, and have been told that 'makepkg' does indeed automatically strip installed binaries.
<mark_weaver>balduin: they tell me that this automatic 'strip' behavior can be disabled within an individual pkgbuild. so a bug should be filed against the guix package. that flag needs to be added.
<mark_weaver>it should be filed against the guix package in AUR, I mean.
<mark_weaver>balduin: now that I understand what's going on, no need to email me that binary
<mark_weaver>balduin: see the 'strip' flag of the OPTIONS array, specified in
<mark_weaver>that man page talks about /etc/makepkg.conf, which specifies the default options for packages, but alludes to the fact that those default options can also be specified within PKGBUILD files.
<mark_weaver>balduin: so, it looks like a line "options=(!strip)" needs to be added to the PKGBUILD for Guix, but that's just a guess. I've never used archlinux before, so I'm not sure.
<mark_weaver>sneek: later tell balduin: it looks like a line "options=(!strip)" needs to be added to the Guix PKGBUILD file, or something along those lines.
<mark_weaver>sneek: botsnack
<mark_weaver>sneek: later tell balduin: I'd be grateful if you could test that change, and if it works, try to get that change added to the Guix PKGBUILD in AUR
<sneek>Will do.
<janneke>l /var/log
<balduin>@mark_weaver, thanks. That is awsome.
<sneek>balduin, you have 2 messages.
<sneek>balduin, mark_weaver says: it looks like a line "options=(!strip)" needs to be added to the Guix PKGBUILD file, or something along those lines.
<sneek>balduin, mark_weaver says: I'd be grateful if you could test that change, and if it works, try to get that change added to the Guix PKGBUILD in AUR
<balduin>@sneek: thanks, I am testing it.
<balduin>@sneek: now, it works
<balduin>@mark_weaver: thanks, after adding: options=(!strip) guix downloads almost everything while using substitutes
***jluttine_ is now known as jluttine
<efraim> when booting into enlightenment
<Sleep_Walker>hm, helper binary does not have suid bit
<popelevi>anyone on?
<popelevi>need some newbie help with setting up wpa_supplicant with shepherd :/
<einarele`>Hello folks! I messed up when doing my guixsd installation and didnt change the home folder part of the config.scm file so now my user is stuck with the /home/bob/ folder. I haven't been able to figure out how to remedy this, could someone around here help me out?
<iyzsong>einarele`: as root, you can install 'shadow' and then run 'usermod' to change the home directory.
<einarele`>And this wouldnt change upon reboot?
<iyzsong>yes, if I read the source (modify-user of activation.scm) correctly, it doesn't handle HOME.
<einarele`>Wonderful, Ill try right away :) Thanks
<einarele`>Guess living forever with /home/bob wouldnt be the worst thing ever but still
<iyzsong>welcome :-)
<efraim>i have the setuid code half-written, but %current-target-system is hanging me up, so since chmod doesn't return a value i'm just going to overwrite for all values I think :/
<jlicht>hello guix
<jlicht>is anyone using a guix-installed emacs with one of the starter kits?
***contrapumpkin is now known as copumpkin
<mark_weaver>jlicht: what do you mean by "one of the starter kits"? most of the guix developers, including me, use the guix-installed emacs
<jlicht>mark_weaver: spacemacs, prelude, the actual emacs 'starter kit', oh-my-emacs etc
<jlicht>basically, stuff that tries to install emacs packages on its own :-)
<mark_weaver>oh, I'm not familiar with those, sorry.
<mark_weaver>as I recall, some GuixSD users use ELPA, but I've never done so.
<mark_weaver>I'm one of those rare people who do almost everything in emacs, and yet am satisfied with very few external emacs add-ons. magit, paredit, and that's about it.
<jlicht>mark_weaver: more power to you!
<mark_weaver>everyone else seems to have their emacs massively customized :)
<jlicht>I kind of 'grew up' in the sweaty embrace of some full featured IDEs
<jlicht>so I kind of expect more than 'just an editor', while still enjoying cusomizability
<brendyn>I hear Guix does not support LVM? Can I install guix on an encryted drive?
<mark_weaver>oh, I expect more than an editor too. I use eww, gnus, erc, comint, etc.
<mark_weaver>brendyn: we support luks-encrypted partitions (including the root partition), but last I knew we didn't yet support the root partition being on LVM.
<mark_weaver>if you use Libreboot (or coreboot with GRUB on the boot flash), then the drive can really be fully encrypted, including /boot where GuixSD stores GRUB. a few Libreboot+GuixSD users do that.
<brendyn>I don't know if I can use libreboot or not. I have a system76 computer which I guess has a proprietary bios
<mark_weaver>brendyn: here's the (short) list of hardware currently supported by Libreboot:
<mark_weaver>coreboot supports a much wider set of hardware
<mark_weaver>almost all hardware nowadays requires proprietary software in the boot firmware, and that's why Libreboot (which is a deblobbed, and more user-friendly distribution of coreboot) supports so few systems.
<brendyn>I think I won't touch it since I'll break my computer :p
<mark_weaver>as you wish
<brendyn>The next computer I buy will have free firmware
<mark_weaver>brendyn: that would be great!
<jlicht>brendyn: You can check out if you are not into DIY
<jlicht>in my case, DIY stuff usually ends of meaning Destroy it yourself :)
<brendyn>I bought a raspberry pi and then found out it is full of proprietary software. I'd assumed it was an entirely libre project
<mark_weaver>brendyn: the Raspberry Pi is actually one of the worst offenders in that category of small computer. it has a very strange boot process, where the GPU boots first, and the GPU is running a proprietary OS.
<brendyn>who wrote that OS?
<mark_weaver>brendyn: the BeagleBone Black is much better.
<mark_weaver>I don't know
<jlicht>mark_weaver: do those not require a blob for the gpu?
<mark_weaver>yes, but it can be run without blobs
<mark_weaver>(the BBB can, I mean)
<brendyn>Does it break functionality?
<mark_weaver>yes, as I recall, some functionality on the BBB won't work without non-free software
<mark_weaver>the GPU situation on ARM is pretty bad for free software
<mark_weaver>I only use BBBs for SPI programming, and for serial consoles and remote power switching on servers
<mark_weaver>*SPI flash
<mark_weaver>last I checked, the best thing we have for GPUs on ARM is the Vivante GPU, used in the Freescale iMX6, which is the SoC used by the Novena laptop. they funded some work to create a free driver for it, although it's not complete.
<suitsmeveryfine>Hi! I don't quite understand this part of the manual: "Re-run the 'configure' script passing it the option '--localstatedir=/somewhere', where '/somewhere' is the 'localstatedir' value of the currently installed Guix"
<suitsmeveryfine>I've got my guix git repository in ~/git/guix. Should I replace "somewhere" with "/home/myself/git/guix"?
<davexunit>suitsmeveryfine: do you already have a guix installation?
<davexunit>if so, then you need to use the same localstatedir
<suitsmeveryfine>davexunit: yes, I accidentally forced deleted the repo though
<suitsmeveryfine>I just recloned
<davexunit>I don't understand what that means
<mark_weaver>suitsmeveryfine: almost certainly, you want --localstatedir=/var
<suitsmeveryfine>mark_weaver: yes, thanks. That's what you suggested to me the last time also!
<suitsmeveryfine>mark_weaver: maybe that could be included in the manual?
<mark_weaver>suitsmeveryfine: possibly, but I have to go afk now, no time to look into it.
<mark_weaver>good luck!
<suitsmeveryfine>thanks again
<brendyn>Does guix intend to make other distros redundant? It seems guix is for defining complete OS's, so could other distros like Scientific Linux port all there different-from-source stuff into their own guix package definitions, making guix turn into Scientific Guix?
<davexunit>brendyn: in the sense that every distro makes every other distro redundant
<davexunit>we're yet another distro
<brendyn>So not especially so?
<brendyn>Just yet another distro?
<davexunit>I don't really know what you're getting at
<brendyn>What style of distro does it intent to be?
<davexunit>what does style mean?
<davexunit>we provide a framework for users to choose the software and services that they would like to run
<brendyn>I was under the impression you could make whole new scheme files defining any system you wanted, switching back and forth as needed?
<brendyn>style as in, more like Parabola, which basically installs packages from source, leaving users to configure there own system, or more like trisquel which works out of the box?
<davexunit>parabola is binary-based, not source-based
<brendyn>Does guix not have binaries too?
<davexunit>yes, we have pre-built binaries, but you don't need to use them.
<davexunit>guix is a source-based package manager that can download pre-built binaries from a trusted source as an optimization
<brendyn>I figured one could do the same with parabola too from PKGBUILDS
<davexunit>yes but it's different
<davexunit>there are no pre-built binaries available for those
<davexunit>there are for core packages
<davexunit>there is a single point of trust
<brendyn>My main curiosity is that just packaging things and handing them to the user provides a system lacking a lot of configuration, for say setting up computers in schools
<brendyn>or the main target, most computer users
<davexunit>again, we provide a framework for the user to define the system of their liking
<brendyn>Just trying to understand the philosophy of this project over others
<davexunit>right now it's best if users are already knowledgable about GNU/Linux
<davexunit>but of course we'd like to include everyone
<brendyn>It seems that the spectrum of possible users might require more than one common repo of package definitions
<brendyn>plain packages vs pre configured packaged set to auto-start services
<davexunit>services and packages are different
<davexunit>you're conflating Guix the package manager and GuixSD the distro.
<brendyn>hmm ok
<davexunit>this is my os config, it's very short:
<davexunit>Adding the result of (gnome-desktop-service) to the set of default desktop services list is all I need to do in order to have a fully functional GNOME environment.
<davexunit>pretty easy.
<brendyn>That script will format your drives and setup GuixSD?
<davexunit>it's not a script
<davexunit>formatting is done prior to installation
<davexunit>guix has tools for turning this OS declaration into the currently running system
<brendyn>So if I wanted to make my system GuixSD I would install Guix and then make it rewrite my system, or install GuixSD onto a usb, boot to it and then follow some install procedure?
<sneek>ng0, you have 1 message.
<sneek>ng0, Sleep_Walker says: @gnu is prefered for this project, thanks
<ng0>okay, that's in the unnamed patch on the list i think.
<ng0>i don't understand why sic is problematicto package. is sic a guile function name or otherwise reserved? i tried to name it suckless-sic but the problem remains
<ng0>weak-key-hash-table .. etc
<ng0>i probably post the patch + error to the list. i don't understand it
<ng0>test from sic
<ng0>so simple, it does not even implement /me or :me
<ng0>now how to quit
<R0B_ROD>So did you use a standard like nix or just made a fresh algo all together?
<R0B_ROD>of course self expression and standards are not in FOSS atm but perhaps this declerative nature of system should be a new for of OS management and deployment
<CompanionCube>I believe GuixSD shares exactly one component with Nix
<adqm>quick question about SLiM configuration in Guix. I installed openbox as my (only) WM, but it seems to come with .desktop files for GNOME-Openbox and KDE-Openbox sessions. Right now, SLiM uses GNOME-Openbox as the default session, and that is never what I want. I can't change the SLiM config file directly because it is read-only, and I don't see a clear way to modify this given the options that slim-service takes. Any ideas?
<davexunit>adqm: you would need to improve the implementation of slim-service
<efraim>i don't believe anyone using guixsd uses openbox as their main WM so it hasn't gotten a lot of love for fixes like that
<davexunit>it's not actually openbox related.
<davexunit>adqm: does slim have a configuration switch for the default session?
<adqm>ah, i see.
<adqm>davexunit: i know it used to, but looking now, it looks like that may have been disabled. from the arch wiki: "Note: SLiM no longer supports a 'default' session where multiple sessions have been enabled. This is most noticable where attempting to log out and back in again to the same session."
<davexunit>ah, bummer.
<davexunit>if it helps, I don't think slim is our ideal choice for display manager
<davexunit>it was just the easiest to get working
<efraim>well, in /gnu/store/...openbox/share/xsessions there is openbox{,-kde,-gnome}.desktop
<davexunit>so hopefully soon enough we can just offer better display managers
<adqm>efraim: right; i'm trying to figure out where those come from (or if there is an easy way to disable/remove them). looks like there isn't anything special in the openbox package definition to put them there, so they must be coming from the make install
<adqm>adqm: it might be possible to do some kind of conditional patch (?) where those only get put in if GNOME or KDE are actually installed? but maybe that's overcomplicating things
<adqm>davexunit: that might be the right answer in the end :)
<efraim>or multiple outputs
<adqm>i might poke around and see if there's an easy way to configure slim to do what i want in modern versions, and if so, if slim-service can be patched to do that. i can maybe handle hitting "F1" twice to get to the right session in the meantime
<adqm>ah, it looks like we can kill the "sessiondir" variable in the slim configuration to make slim honor .xinitrc. so maybe that would be the right patch to slim-service, at least in the short term
<efraim>from my (very) limited testing of openbox on guixsd recently it looks like its missing some inputs that i'm going to test out in a vm
<efraim>and we're also missing obconf
<efraim>connman might also need sysconfdir=/var set, and tilda errors out at start :/
<adqm>i've just started poking around, so i'm not at all familiar with how the guile-based config stuff works (this might be good motivation to figure it out). openbox seems to be working fine; it's just a little bit of a pain to get to it because of the slim config. obconf might be nice (can maybe be "guix import"ed from the nix package?)
<efraim>oh, and someone double-check me, it looks like prank is 64-bit only
<alezost>efraim: re "i don't believe anyone using guixsd uses openbox as their main WM" I use openbox sometimes (but I don' use slim :-))
<adqm>alezost: i wouldn't normally use slim; on my day-to-day machines, I just startx from the console. tried that here, but i didn't have any luck (couldn't get the X server to start with xinit or startx). what's your secret?
<efraim>it looks like enlightenment might need a similar reboot/suspend/etc substitution to what xfce has
<alezost>adqm: I use shepherd to start X server, WM and other stuff, but it's not simple; my shepherd config is here:
<alezost>adqm: btw using "xinit" is possible but also not simple; I seem to recall Kooda uses "xinit" to start X server
<Kooda>I do :)
<adqm>well at least it's _actually hard and not just me being stoopid
<adqm>thanks for sharing the config
<alezost>adqm: for xinit you can specify X server binary
<adqm>oh, that might just do the trick
<Kooda>adqm: if you want a config where you start X with xinit, mine is here:
<Kooda>The X server binary has to be setuid, sadly.
<Kooda>I also had to put some links in /etc/X11:
<alezost>why sadly? I don't see how it can be avoided
<Kooda>Maybe with finer permissions.
<adqm>Kooda: thanks a bunch!
<adqm>and bonus wpa_supplicant service stuff I was going to try to figure out later :)
<rekado>got ibus to work again, but it’s not pretty. Needed to set an environment variable that’s not safe across different GTK versions.
<rekado>the result is that GTK3 applications work fine, but GTK2 applications crash :-/
<rekado>this might need another of these GUIX_GTK2/GUIX_GTK3 environment variable splits.
<rekado>another ugly part is that this must be run in a profile hook. An immodules.cache must be generated and installed to the profile.
<rekado>I don’t like how ibus (and GTK in general) resists our functional package management efforts. Makes it really hard to get this done right.
<CompanionCube>efraim, doesn't Enlightenment come with it's own mechanism for halt/shutdown/reboot
<CompanionCube>something involving enlightenment_sys or similar
<rekado>How are you all using pulseaudio? Does it need to run as a user server?
<rekado>when I try to start it as a user I get this error:
<rekado>E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
<rekado>and this one related to bluetooth:
<rekado>E: [pulseaudio] bluez4-util.c: org.bluez.Manager.GetProperties() failed: org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.bluez.Manager" doesn't exist
<rekado>(I have the shepherd service “bluetooth” running)
<lfam>rekado: Pulseaudio "just works" for me on GuixSD while running %base-services.
<rekado>I’m trying to get my notebook to use a bluetooth-enabled speaker via pulseaudio.
<lfam>Later I can look at my GuixSD system and see which user it runs as
<lfam>I think it starts "on demand" when my user starts the MPD daemon
<rekado>lfam: I’m actually using %desktop-services (with slight modifications)
<rekado>are you sure it’s not just using alsa directly?
<lfam>Nope, not sure :) I don't have remote access to that system. I'll look at it when I get home
<rekado>thanks, no hurry.
<cbaines>How do people normally run ./pre-inst-env guix system reconfigure?
<cbaines>When running without sudo, I get a permission denied error when trying to change /var/guix/profiles/system-30-link
<rekado>cbaines: I do “sudo -E ./pre-inst-env guix system reconfigure /etc/config.scm”
<cbaines>Ah, that seems to have got it working :)
<cbaines>without -E I was getting guile errors...
<cbaines>thanks rekado
<cbaines>I'm having problems with guix system reconfigure again
<cbaines>Now it seems to just report lots of "note: source file ... newer than compiled ...", and then exit with status 1
<cbaines>I can't see any suggestions of what the problem is
<cbaines>This happens when using sudo -E and without
<cbaines>any suggestions?
<jlicht>Node includes source for the C-ares library, and statically links this. Is it preferable to have Node be dynamically linked to our packaged C-ares libarary?
<adqm>cbaines: i have a similar problem; for me, the hardward clock seems to be resetting to the epoch on every reboot
<adqm>if you run date, does it show the current time?
<adqm>might be a different issue, but i've had a whole bunch of time-related problems :)
<cbaines>I think I remember seeing something in a log about time, but date gives the correct time