<leungbk>i'm having trouble setting up a decent environment for writing haskell on emacs + guixsd. when i used debian, i used stack and emacs' dante-mode, and everything worked fine; but on guixsd, i'm having a hard time getting even one of dante-mode/intero/ghc-mod to work. does anyone have any suggestions for editor integration?
<reepca>well, that was a good 5 days wasted. python-2.7-site-prefixes.patch hard-codes a /gnu/store, so if you try doing anything with python-2.7 in test-env, it breaks.
<reepca>leungbk: guix import elpa --archive=melpa -r dante will give you package definitions for dante and the packages it depends on. You can put it in a guile module and import the relevant stuff (like (guix) and (guix build-system emacs)) and add that module to your GUIX_PACKAGE_PATH. Then a guix package -i dante will install it.
<reepca>sneek: later tell leungbk: guix import elpa --archive=melpa -r dante will give you package definitions for dante and the packages it depends on. You can put it in a guile module and import the relevant stuff (like (guix) and (guix build-system emacs)) and add that module to your GUIX_PACKAGE_PATH. Then a guix package -i dante will install it.
<sneek>leungbk, reepca says: guix import elpa --archive=melpa -r dante will give you package definitions for dante and the packages it depends on. You can put it in a guile module and import the relevant stuff (like (guix) and (guix build-system emacs)) and add that module to your GUIX_PACKAGE_PATH. Then a guix package -i dante will install it.
<pepa65>Install finished, /mnt now looks properly populated, including /boot/efi -- rebooting.
<pepa65>Weird thing that I am now going to look into. Stuck at EFI boot manager, and the EFI partition has EFI/GuixSD but when I looked at /mnt before rebooting, it had a grub_x64.efi binary there, but that's not there now...
<pepa65>It says volume not properly unmounted. I was almost going to say here before rebooting, it feels wrong not to properly unmount everything...
<pepa65>OK, fsck done, efi binary is visible again, root fs also cleared from many orphaned nodes... :-('
<pepa65>After manually seeding the efi boot manager I reached GRUB and now it's booting!
<reepca>that'll update the packages in the current user's profile. If you want to update the system (kernel, services, etc), 'guix system reconfigure' does that.
<pepa65>OK! That's what I am doing in one tab, while installing git and tmux in the other -- not harmful I hope, doing it in parallel?
<reepca>thanks to guix's transactional properties, installing in parallel *should* never cause any breakage, but there is one annoying thing: 'guix package' stuff operates on the user's profile by looking at the current profile and generating a new one with the new/updated/etc stuff. It then builds the new profile, and finally symlinks your ~/.guix-profile to it atomically. This means if you do guix package -i foo and then switch to another
<reepca>terminal and run guix package -i bar, you will end up with either the new profile produced with foo or the one produced with bar, but not one containing both (since it wasn't told to produce one containing both).
<reepca>this can be annoying if you start installing something and then halfway through remember something else you wanted to install
<reepca>but since reconfiguring only affects the *system* profile and 'guix package' installs stuff into your *user* profile, it shouldn't cause any issues whatsoever
<reepca>Question... do we assume that if the store is in a non-/gnu/store place that NIX_STORE will have to be set by the user accordingly, even if they configured their install with the proper --storedir flag?
<pepa65>Very strange how the `/etc/fstab` file contains a great many entries, but none about the swap, EFI and root partition (the former 2 were not mounted then...)
<pepa65>I guess you have to manually add them, even at the install stage..?
<efraim>my /etc/fstab has UUID=F010-1913 /boot/efi vfat defaults
<roptat>pepa65, you're supposed to declare these fs in your config, then fstab is filled automatically from that. But I don't think grub needs that. Can you share your config so we can try and help you?
<pepa65>I am using the desktop template. In the bootloader part I didn't change anything, it already had grub-efi-bootloader and "/boot/efi" as target.
***rekado_ is now known as rekado
<rekado>reepca: no, NIX_STORE does not need to be set. But Guix should have been configured with the different store location.
<civodul>oh the spinning thread is actually stuck on the resolve-variable mutex, uh
<davidl>Does someone know how to start using guile-bash after having installed it? just running (use-modules (gnu bash)) in the guile REPL doesn't work. I found the /gnu/store path for the package but don't know how to add it the load path correctly.
<davidl>guile-bash seems to only have packages for guile-2.0 - does that mean I must install guile 2.0 instead of 2.2 in order for guile to find it in the default load-path?
<roptat>davidl, most likely yes. Then guix will tell you how to set up environment variables for guile-bash to work
<roptat>you have to install both in the same profile to get the hint
<davidl>roptat: re making a list 2 21: (use-modules (gnu bash)) (display (string-split #$(seq 2 21) \#newline))
<jlicht>I'm playing around with an nginx/php-fpm install on GuixSD atm, but am having trouble getting nginx to allow for leaving off the "/index.php" at the end of URL's. Is this possible using GuixSD services configurations, or do I need to dive into manual nginx-configurations?
<jlicht>nvm, I just needed to restart my nginx service. Everything works wonderfully :-)
<g_bor>It seems to me that I am hitting some kind of resource limit. I got a build where unzip returns 9.
<g_bor>It goes well when I run it in the kept build directory.
<mubarak>does anybody here have an openmailbox.org email, who use it Emacs or Mutt for mailing list? do I need to go to the settings and enable something?
<mubarak>I think I tried Icedove before but it didn't connect
<mubarak>I want to follow some mailing lists, and I don't want to use non-privacy respecting like @gma.. @hotma.. . If anyone have an email in any of emails recommended by the FSF, who able to configure it in Emacs or Mutt, please let me know
<bavier>mubarak: iirc, you need a premium subscription for IMAP access with openmailbox.
<apteryx>what is the entry point for network-manager-openvpn? I'm trying to set up a VPN.
<serichsen>I'm looking for help. I'm trying to install GuixSD on a new laptop. When doing the `guix system init' step, stumwm fails to install. The build log shows that a dependency of the testing library cannot be found. I installed it on the installation system using `guix package -i …', but that changes nothing even though the file now definitely exists.
<lfam>My recommendation is to 'init' a more basic system, without stumpwm, or with some other window manager. It's not efficient to try debugging package build failures before installing the OS
<serichsen>Heh, that would have been my next question, thanks.
<pkill9>if the manual doesn't suggest using a barebones system config for `guix system init` i think it should, because it seems to solve a lot of issues and everyone who comes here with an issue just gets directed to do that anyway
<pkill9>the downloaded guixsd image is quite out of date in terms of software anyway so people will need to update soon after installing anyway
<lfam>It's not that out-of-date, especially compared to other distro installers
<lfam>But yes, people should update after installing
<lfam>Yeah, that's an important bug for all SBCL software
<lfam>But it is a general issue in the sense that the reference scanner could be improved
<serichsen>Where do I find that reference scanner? I also read something about “grafting code”?
<serichsen>I am a bit surprised that it matters how SBCL stores strings internally.
<serichsen>If this is a guix api that is called by SBCL, it should be a simple matter of specifying the external-format.
<ngz>Hello. I have a question about the install script. It "makes guix command available to all users" by putting a link in /usr/local/bin. Isn't that process outdated, since each user can have their own guix command?
<lfam>serichsen: After building a package, Guix scans the result of the build for references to other files in /gnu/store. This information is used for several things, like knowing a package's runtime dependencies, so that they can be downloaded when installing the package. It is also used so that garbage collection of /gnu/store works properly. If the references are obscured somehow, for example by chunking them, or compressing the file that
<lfam>contains them, they will be missed the scanner
<bavier>ngz: the install script is for an initial system-wide install; afterwards each user is free to 'guix pull' their own guix.
<lfam>My understanding is that, currently, the scanner only reads ASCII, since file names in the store are ASCII and that's what most compilers use
<lfam>But, this issue with SBCL highlights the need for something more sophisticated
<bavier>this has been an issue too with gcc doing things with string alignment or vectorized loads of strings (iirc)
<apteryx>is anyone using a VPN with NetworkManager?
<ngz>bavier: I thought putting guix command in /usr/local/bin was discouraged. Nevermind then.
<lfam>serichsen: Check the code in 'nix/libstore/reference.cc'
<lfam>And the grafting mechanism is in 'guix/build/graft.scm'
<serichsen>OK, so maybe one could (as a workaround) add some sort of guix manifest for the dependencies to the build output, in UTF-8?
<lfam>There's a difference between build-time dependencies and run-time dependencies. The build-time dependency graph is explicitly specified in the package definitions. But it's not the same as the graph of software needed at run-time. That can only be determined by something like a post-build reference scanner
<lfam>apteryx: One of them is the reality, the other is more like a prediction :)
<serichsen>It then seems that this is not the problem here, since the dependencies are explicitly noted: stumpwm has native-input fiasco, which in turn has input trivial-gray-streams, and the latter is not found.
<lfam>ArneBab: Are you using any channels or GUIX_PACKAGE_PATH things?
<ArneBab>I tried to add channels, but removed them now
<ArneBab>my channels file only contains %default-channels
<apteryx>strange: I've rebuilt my system multiple times today, on the same Guix revision, and everytime it goes of building something new and unexpected such as "tar", "bash" or "guile". any explanation?
<ArneBab>I now deleted the channels file, but that did not help: guix pull fails
<lfam>apteryx: I mean that the list of 'inputs' is merely a prediction of what we think the software depends on. But, the actual store references in the built software are concretely the actual dependencies. Of course, this breaks down if the reference scanner can't read the references for some reason
<lfam>And propagated-inputs are another complication
<apteryx>lfam: OK, I understand now. I wouldn't expect package A to have B as an input to suddenly refer to C in the store though, that'd be a bug.
<ArneBab>lfam: restarting my computer actually worked …
<ArneBab>sadly I don’t have the time to find out why
<apteryx>lfam: and in fact if we were using content addressed items, we wouldn't need to cache those references, or if only as a sanity check (since they'd be super cheap to find out given a specific Guix commit a package came from).
<lfam>But once the build is complete you see that they are referenced
<apteryx>lfam: OK, that's interesting, I've never scrutinized the binaries produced to see what sorts of thing they actually linked to
<lfam>Ah, I think you are hitting on something discussed in Dolstra's PhD thesis on Nix ideas. I forget the names he chose for these two models: The one used by Guix and Nix, and the one you seem to describe
<cnmne>the dry run went through! and even the real thing compiled fine. grub listed everything as expected, but trying to boot from the non-guix dropped me into an emergency shell after not finding the device. I'll play with this a little bit...
<cnmne>thanks for that easy fix! I think I misunderstood the menu-entry objects to be the menu-entry arguments, and so didn't even consider an explicit list operation