<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. <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: http://sprunge.us/KXXb 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 bug-guix@gnu.org <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>guix build: error: myhello: unknown package <balduin>in the myhello.scm I used: (define-module (gnu packages myhello) <lfam>balduin: Try changing (gnu packages myhello) to (Packages myhello) and then setting GUIX_PACKAGE_PATH to ~/Packages <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>and make the filename /home/user/Pacakges/myhello.scm <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 <balduin>now, I have a problem with the sha256 value <balduin>(sha256 "ecbb7a2214196c57ff9340aa71458e1559abd38f6d8d169666846935df191ea7"))) <sapientech>balduin: it should show you what it should be, just change it to that <mark_weaver>balduin: replace that string with the output of "guix hash hello-2.9.tar.??" <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 <balduin>19qy37gkasc4csb1d3bdiz9snn8mir2p3aj0jgzmfv0r2hi7mfzc <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? <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? <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>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>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 bug-guix@gnu.org about it, so we don't forget? <balduin>@mark_weaver how do you work more with substitutes (binary packages) instead of allways compiling packages? <mark_weaver>it's explains how on that page. "guix archive --authorize < hydra.gnu.org.pub" is the key command <mark_weaver>maybe it's because you're using an old version of guix, for which substitutes are no longer available on hydra.gnu.org? <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 <mark_weaver>(note that "guix pull" only updates guix for the user who runs it, by setting the symlink ~/.config/guix/latest <mark_weaver>that's the newest, released very recently. hydra.gnu.org should have all the substitutes for that one. <mark_weaver>when you compile things, do you see messages about substitutes? <balduin>or something to install the software <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 <balduin>@makr_weaver I would love to, the only problem is gcc compiling right now, which will take a while. <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>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 <mark_weaver>which architecture are you on? x86_64, i686, or something else? <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>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. <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>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 hydra.gnu.org, 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)' <balduin>/gnu/store/zbv64d1m6qg8rh53n6kzg0lxcnlb3r8b-guile-bootstrap-2.0 <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" <balduin>/usr/share/guile/site/2.0/gnu/packages/bootstrap/armhf-linux/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>what's the output of "sha256sum /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz" ? <balduin>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0 /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz <balduin>-rw-r--r-- 1 root root 2885996 Aug 6 11:33 guile-2.0.9.tar.xz <balduin>but, there are some executables in the same directory: <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 <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 <balduin>/var/log/guix/drvs/59/wi50shyr3a5p1h75i6jb4hc50z1jkc-guile-bootstrap-2.0.drv.bz2 <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 <balduin>Derive([("out","/gnu/store/zbv64d1m6qg8rh53n6kzg0lxcnlb3r8b-guile-bootstrap-2.0","","")],[],["/gnu/store/5bznaasd0wbqzk3ahy97nqjif5p06m78-bash","/gnu/store/lhim2ddm5m41hx6f7rdg3gzcgmql80jq-build-bootstrap-guile.sh"],"x86_64-linux","/gnu/store/5bznaasd0wbqzk3ahy97nqjif5p06m78-bash",["/gnu/store/lhim2ddm5m41hx6f7rdg3gzcgmql80jq-build-bootstrap-guile.sh"],[("out","/gnu/store/zbv64d1m6qg8rh53n6kzg0lxcnlb3r8b-guile-bootstrap-2.0")]) <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 <balduin>1cjnsv9cdvvk1c9a7l9zpmm5ipqjph8g0qabdhi2h3fkbhihz5a6 <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. <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? <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>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>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>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>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`" <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>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>balduin: can you please email a copy of that 'bash' to mhw@netris.org ? <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>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>sorry, all aur packages have to be compiled. There is no pre-built binary. <balduin>the aur package downloads: ftp://alpha.gnu.org/gnu/guix/guix-0.11.0.tar.gz, 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>which doesn't match what's in /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash <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: can you send a copy of /usr/share/guile/site/2.0/gnu/packages/bootstrap/x86_64-linux/bash to mhw@netris.org please? <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 <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>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>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: 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 <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>@mark_weaver: thanks, after adding: options=(!strip) guix downloads almost everything while using substitutes ***jluttine_ is now known as jluttine
<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. <iyzsong>yes, if I read the source (modify-user of activation.scm) correctly, it doesn't handle HOME. <einarele`>Guess living forever with /home/bob wouldnt be the worst thing ever but still <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>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>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. <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>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 <brendyn>The next computer I buy will have free firmware <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. <jlicht>mark_weaver: do those not require a blob for the gpu? <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>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 <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! <mark_weaver>suitsmeveryfine: possibly, but I have to go afk now, no time to look into it. <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 <brendyn>What style of distro does it intent to be? <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>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>there are no pre-built binaries available for those <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 <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>you're conflating Guix the package manager and GuixSD the distro. <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. <brendyn>That script will format your drives and setup GuixSD? <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, 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>so simple, it does not even implement /me or :me <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 <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>adqm: does slim have a configuration switch for the default session? <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>if it helps, I don't think slim is our ideal choice for display manager <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 :) <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>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?) <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: btw using "xinit" is possible but also not simple; I seem to recall Kooda uses "xinit" to start X server <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>The X server binary has to be setuid, sadly. <alezost>why sadly? I don't see how it can be avoided <Kooda>Maybe with finer permissions. <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 <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 <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>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 <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 