<atw>wr: hello! If I were you, I would put lxde in the (packages ...) section of your operating-system. That way, sddm/slim/gdm should be able to find lxde and offer it to you as a choice at graphical login
<wr>atw, i installed the guix with no DE, now i need to put something
<atw>did you install GuixSD, or did you install Guix as a package manager on another distribution ("foreign distro" installation)?
<wr>atw, what distro would you say is most likely similar to guix?
<atw>I would say Nix, but that's a bit of a cheap answer; Guix is based on Nix and uses Nix's build daemon (and for the record, I haven't used Nix)
<atw>personal opinion: I think that Guix as a package manager has a bit in common with Homebrew as both use a general-purpose programming language to define packages, and I /think/ that's rare-ish. I'd love to hear the opinion of some more experienced people in the channel :)
<oneness>Hello there, I am using the guided installer to install but got this error: .../grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi exited with status 1 error message is failed to get canonical path of '/boot/efit'? Anyone had similar issues? I assume the the bios not get detected and defaulted to efi?
<boogerlad>guix package --roll-back goes back a generation for the packages, but the guix version itself is still the same. I know you can access old guix versions in ~/.config/guix/, but if I wanted to remove some generations, how would I do that?
<brendyyn>I think it may not have been implemented yet, but i think you may be able to do it using --profile and treating guix its self as a profile
<boogerlad>I see "guix package -p ~/.config/guix/current --delete-generations=1" from "invoking guix pull" in the manual
<boogerlad>if this is the suggested way, it seems pretty trivial - are there any edge cases that are preventing this from being implemented?
<brendyyn>-p is --profile. That's what I was thinking of
<boogerlad>if not, maybe it'll be my first contribution to guix =P
<brendyyn>I'm not sure. It may be a simple matter of people being busy with all the other things they want to work on.
<atw>I do not know offhand about the build error you ran into there. could you paste the build log (from /var/log/guix/drvs/pv/457...-lightdm-1.24.0.drv.bz2) with a paste service? https://paste.debian.net is liked
<atw>please bear with me as I continue to make mistakes and not know things :)
<atw>and heads up, I have to go to sleep at some point here
<atw>sneek_: later tell crab1 could you post your operating-system config and talk a bit about how you're installing?
<donofrio_>so ifI am compiling I need all these dependancies compiled into my /app directory I take it or can I just get these dependencies installed by os folks and keep within our /app directory for normal use (package updates and etc for /app is what I want/need)
<donofrio_>also will this work on non-sse2 hardware (aka power8)
<efraim>Work is ongoing to get powerpc64le support into Guix
<efraim>If you're on power8 it you don't have to worry about using a different prefix than /gnu/store since we likely won't have any substitutes for a bit
<dftxbs3e>efraim - donofrio_: https://gitlab.com/lle-bout/guix - powerpc64le (version 1 patched for powerpc64le support, /!\ you are trusting my bootstrap binaries) - powerpc64le-bootstrap (version 0.13.0 + some cherry-picked commits to cross compile bootstrap binaries, use this if you don't want to trust my bootstrap binaries, and then patch them in the powerpc64le branch)
***MinceR_ is now known as MinceR
<PotentialUser-41>Hello, Guix people! I've heard about the release of 1.0 and wanted to try it out on my minifree X200T, but I'm having some network issues after the successful install. When connecting to a WPA2 secured WiFi it keeps asking for the password without ever connecting. Open WiFis work. Could someone give me a pointer of where to start searching? Used gr
<g_bor[m]>Just an idea, what do you think about an extract-and-copy-build-system, that would extract the source like gnu-build-system, and then copy the exctracted source to the output? I believe this might be useful when we have something that can be used as is, without any further transformation. The idea came from trying to get a static website configured. This could be done very easily with what we have in place, but I feel it a bit
<g_bor[m]>I have noticed a small thing with the way we are starting services on guix system. It would be nice if we could benefit from the possibility provided by some servers that allow live updating their configuration. One example is nginx. We could implement a reload action, that performs that, but currently the config file is referred as the absolute store path generated at system reconfigure time. I believe that using a link
<g_bor[m]>instead of that, and pointing to the store item would work. The link could be updated on reconfigure, and then reload would be simply sending a SIGHUP. Wdyt?
<cbaines>Is there any way to run a single srfi-64 test? I've got something kinda working with Geiser, but the error doesn't appear in the buffer geiser pops up
<g_bor[m]>afther a bit more thought, we might not be able to update the symlink on reconfigure, but then it could be done in the start, restart and reload actions...
<cbaines>I'm still fighting srfi-64, I think the only way to get the default test runner to tell you what the failure is for a single test is to wrap it in a group, and set the aux-value for the runner to a port which you'll see the output to
<cbaines>If anyone knows of a simpler way, I'd love to know!
<apteryx>cbaines: FWIW, when I have to debug tests, I rename the test module so that it fits the Guile nomenclature, and then I can eval the module/run single tests with Geiser.
<str1ngs>nly: I have resolved this ICU but I might need you to test something.
<rekado>we’ll get new disks within a day and hardware replacements without having to argue all the time
<dftxbs3e>rekado: regarding the powerpc64le port, I think waiting for gcc-7+ stable support is needed.
<rekado>(I think for public service purchases extended warranty is a requirement anyway.)
<dftxbs3e>even though, the bootstrap binaries worked, the later commencement.scm stuff compiles glibc 2.28 which runs into the same problems
<dftxbs3e>I have been trying to patch that for glibc 2.25 but I think it's the wrong route to take.
<rekado>dftxbs3e: our best hope is getting the needed changes into core-updates and fixing the problems in other packages that this change might trigger.
<dftxbs3e>rekado: Yes, I think when these changes are made, bootstrapping powerpc64le will Just Work (TM)
<rekado>I just installed “guile-opengl” to play with computing on a GPU node on the cluster and I saw that it’s compiling the Scheme files. Something wrong with the installation location of the .go files?
<inaimathi`>Cool. So I'm trying to run `guix pack` to set up a basic `hello` pack. I run `guix pack -RR -S /bin/hello=hello hello`. After unpacking the resulting tarball, I get a `bin` and `gnu` directory, but when I try `./bin/hello`, I get the bash error of `No such file or directory`.
<inaimathi`>The desired end state is a pack that I can use to run `hello` regardless of whether the target system has `guix` available; am I fundamentally misunderstanding the `-S` and `-RR` flags here?
<cbaines>apteryx, what renaming do you do? I don't know what the Guile nomenclature is.
<Blackbeard[m]>Tarballs, the ultimate container image format — 2018 — Blog — GNU Guix
<apteryx>cbaines: I meant the name of the guile module should follow the layout of the file system (e.g. the name of tests/pypi.scm should be (tests pypi) rather than (test-pypi) in the define-module directive.
<apteryx>otherwise Guile cannot evaluate the module as-is, which is a shame.
<cbaines>apteryx, geiser seemed to make a go at compiling the module
<cbaines>and I can actually run an individual test
<apteryx>brendyyn: regarding the question "is jami using the TURN server or not", AmarOk from #jami answered to me that you can grep for "ice_transport.cpp.*connection pairs" in the "dring -cdp" daemon output.
<sirgazil>cbaines: As far as I know, the default test runner does not print the complete information of failed tests, but the log files do contain details. I had to write a test runner for my own projects because I didn't like that.
<cbaines>sirgazil, yep, that's indeed the problem I'm coming up against
<cbaines>I think I've found that build-aux/test-driver.scm does contain a different test runner implementation, so I'm currently trying to work that out...
<civodul>what i do in Geiser is that i C-M-x the 'define-module' form and top-level definitions, and then i evaluate the expressions i care about
<civodul>it's pretty manual because you can't evaluate a whole test-assert expression, for instance
<cbaines>evaluating a test-assert does work for me with Geiser, it just doesn't say why the test failed (if it failed)
<apteryx>civodul: if I rename the module as (tests module-name), I seem to be able to eval test-equal or test-assert
<apteryx>I also load the module in Geiser with C-c C-a before doing that
<apteryx>any reason we can't stick with the normal module naming? Is the (test-modulename) style something that srfi-64 cares about?
<cbaines>civodul, I think the biggest issue with Docker containers is running the build-daemon though. Having guix install ... start the build-daemon if it's not running, so you can just invoke guix install in a Dockerfile, and it works would be pretty convinient I think
<g_bor[m]>civodul: I believe that something like docker run -ti bash would work...
<bandali>what's the general etiquette for requesting being added to the guix group?
<bandali>i've made a few simple contributions so far
<rekado>bandali: usually it’s not needed to be a member of the Guix group on Savannah because of our patch-based workflow.
<rekado>you can contribute by sending patches and one of the people who have push access should review the patches and push them.
<bandali>rekado: i do understand that :) but i thought it'd be nice if i could commit trivial changes myself without having to bother others
<bandali>like bumping package versions or updating the pubkey file name in the installer script
<rekado>people with push access are usually long term contributors and “with great powers comes great responsibility” :) so generally we only ask people to become a member when they’ve contributed for a while and have done patch reviews etc.