***jje_ is now known as jje
<cornburglar>I have a directory called my-guix that contains my-packages.scm and config.scm. my-packages starts with (define-module (my-guix my-packages) and config.scm starts with (use-modules (gnu) (my-guix my-packages). I run sudo -E guix system reconfigure config.scm, and I recieve a no-code for module error, I can't figure out why ***jje_ is now known as jje
<leungbk>I'm planning on rewriting the recursive-import function to display the output in topological order. Is there a reason that it's currently written using streams? For my intended patch it seems like traversing with a stack and a while loop would be a bit cleaner. <wdkrnls>Dear Guix, I have been unable to reliably run bulk package updates because certain substitutes download at sub 1 kbyte/s and eventually stall. Is this a widespread problem or only a problem for me? <wdkrnls>Can anyone suggest a substitute mirror service for Guix? <OriansJ>wdkrnls: actually it is trivial to setup your own <roptat>wdkrnls: as you may have noticed, we're not very active during European night time :) <roptat>I think only Chinese have had issues with downloading substitutes before <shrdlu68>roptat: Good morning, I've only seen exaples of gexp's creating symlinks and not regular files. Could you give me some pointers? <roptat>something like #~(begin (mkdir-p (string-append #$output "/.terminfo/...")) (copy-file $#(local-file "kitty-terminfo") (string-append #$output "/.terminfo/..."))) <shrdlu68>Ah, I was mistaken about what exactly a gexp does, then. How does it return a file-like object? <roptat>a gexp is not a file-like object, but you can create a file-like object with one <roptat>when it is evaluated, the content of the gexp is used as a build script in the build environment, where it only has access to the store <roptat>#$ is "ungexp", which is evaluated before creating the build script, and its value is put instead of #$ <roptat>if it is #$output, it is replaced by the output directory, as a string <roptat>if it is #$some-file-like-object, the file-like object is first built (interned in the store), then its output path is substituted, as a string <roptat>if you run with --dry-run, you'll find the .drv file that references a builder script. That script is the content of your gexp, with all its ungexp replaced by the value they represent <shrdlu68>roptat: Thanks for the explanation. Would `(open-file (string-append #$output "/.terminfo/x/xterm-kitty") "w")` suffice in creating the file, followed by `(close-file port)` <roptat>you can use with-output-to-file or call-with-output-file <roptat>that's easier than manipulating ports directly <roptat>you need to put the file inside the computed-file, not as a separate file-like object <roptat>(also, don't use cons for a list and a list, use append instead) <brendyyn>Why does guile-opengl require changing dynamic-link to hard-coded paths? Why can't dynamic-link find the libraries? <shrdlu68>roptat: Yes it does. However, I had to replace /.terminfo... with /x... because it was building .terminfo/.terminfo... <sneek>civodul, you have 1 message. <sneek>civodul, ng0 says: can you moderate Jean Louis on the list? It's already clear Jean won't stop on their own. <olivuser>some days ago I ran guix system reconfigure with a faulty configuration. I left settings to /dev/sdaX even though it should've been /dev/sdbX because of a second harddrive not present during install. <olivuser>now I cant boot to either the /dev/sdaX operating system nor guix (/dev/sdbX). When I try to boot, I immediately enter GRUB rescue. <olivuser>apparently no data was lost. In the case of /dev/sdaX (LVM2 pv) it appears as if LVM has been deactivated (can be activated temporarily with 'modprobe dm-mod' and 'sudo vgchange -ay'). By now, I believe 'the only thing' that happened is that somehow the bootloader got mixed up. <brendyyn>you tried booting in to the right drive from the bios? <olivuser>I unplugged both drives and the sequentially plugged either, to test if both were "affected" <olivuser>strange thing is, at first guix did boot, but after some restarting shenanigans on my part (facepalm), this also stopped working <olivuser>both drives use a separate bootloader(-configuration), if that is of importance <olivuser>brendyyn, or do you mean something specific when you say "booting in to the right drive from the bios"? <brendyyn>olivuser: the other day i also found my self in a grub rescue shell, and it turns out the bios had changed somehow and was booting in to the wrong drive <olivuser>brendyyn, but wouldnt this problem be bypassed if only one drive is plugged at one time? <olivuser>but the idea would then be to plug in both and then try different boot orders? <brendyyn>to just manually select it to make sure its the right one <olivuser>okay, so I plugged both in but deactivated one at a time so only the other is booted from. For the /dev/sdaX drive (not guix), I get the error "no such device: "39sfnae-aef" (etc)" and "unknown filesystem" (it is the lvm2 fs drive). <olivuser>for the /dev/sdbX (guix), I get the "symbol 'grub_file_filter' not found" error. <olivuser>sorry, I have been disconnected... So trying to choose either of the two drives yielded a different error. one related to the name and fs type ('unknown filesystem' and 'no such device') which the other was related to the 'grub_file_filter' symbol. <slyfox>does guix git require guile-ssh package? It fails to build for me as: error: failed to load 'guix/ssh.scm': <slyfox>ice-9/eval.scm:293:34: no code for module (ssh session) <slyfox>./configure did not seem to complain about lack of this module <roptat>slyfox, if you want to make guix, I think you need it, but if you don't run make and just use guix, as long as you don't need a module that loads guile-ssh, you're fine <civodul>i think ./configure checks for Guile-SSH and disables the bits that depend on it if it's not found <slyfox>roptat: i wanted to run 'guix refresh' from a ./pre-inst-env thus would like to guild guix. I ended up installing guile-ssh locallyto get past build failure <roptat>slyfox, when you use "guix environment guix", you should get guile-ssh <slyfox>yes, it needs installed guix though :) <wdkrnls>roptat: I'm in the US. Most substitutes download fast enough, but then guix gets stuck on one substitute (different each time) and then the command keeps running for days with no more change, but no timeouts - it just hangs. <wdkrnls>This substitute is downloaded incredibly slowly (1980's speed) for a few seconds, and then everything just hangs. <desmes>Has anyone installed Guix on a raspberry Pi? I'm thinking about trying to do it. <desmes>I mean, It would make a lot of sense to run Guix on a home server. For the rollbacks, reproducibility, etc. <wdkrnls>I hope a community forms around this as it would be nice to use guix as my phone operating system eventually. <desmes>wdkrnls: that would be awesome lol <desmes>I see, so it's not ready for ARM architectures yet. <mbakke>desmes: plenty of ARM boards are supported, but rPI requires proprietary firmware to function IIRC. <mbakke>you can still use guix-the-package-manager, though <foxmean>Hello guix. I'm trying to add Runit daemon setup in Guix manual. I've cloned git repository and edit guix.texi. But I've failed to build the manual info by "makeinfo guix.texi". The shell output is https://paste.debian.net/1106116/. Have you notice something wrong? or should I try to patch without try building the manual locally? <roptat>desmes, I use Guix on a cubietruck, a slightly more powerful board than the rPi I think <roptat>foxmean, try with "make doc/guix.info" <roptat>it should run makeinfo with all the required arguments <janneke>foxmean: great! you may find some information and pointers in my reply to your bug report; please read that again and ask any questions you may have <roptat>foxmean, also, it will build the texi files that are currently missing (because they are generated) <desmes>roptat: I see, I'm sure it feels good to use it as a simple home server or NAS <roptat>yes, it's running a few things, like my mail server <desmes>By the way, I have a question for the Emacs users here (which I guess a lot of you are). Do you guys use Guix Emacs packages or Melpa packages? What are the pros and cons of use an Emacs package from the first or the second? <roptat>foxmean, try "make doc/os-config-bare-bones.texi doc/os-config-desktop.texi doc/os-config-lightweight-desktop.texi" maybe <desmes>Since there are a lot of Emacs packages on the Guix repo, I was wondering that. <roptat>desmes, we're not all guys here, so we try to avoid that term ;) (use "people" or "guix" instead) <foxmean>roptat: The bash tell me there is no such a file :(. " bash: doc/os-config-desktop.texi: No such file or directory". <roptat>I'm not an emacs user, so I can't help <roptat>foxmean, right, but make should be able to build it, no? <roptat>foxmean, you'll be missing "doc/version.texi" too, I wonder why it's not generated by make... <roptat>have you run ./bootstrap and ./configure --localstatedir=/var ? <desmes>roptat: Every time I see some screencap of some Guix user or developer I see them using a terminal within Emacs hahaha. I guess it makes sense that the target for a guile-based distro is similar to the target of a guile-based editor <truby>desmes: if it's a raspberry pi 3 you could try the UEFI port for it, I reckon Guix would be able to boot on that as it doesn't require the OS to support the proprietary boot firmware. I haven't tried it though as I can't get my pi 3 to boot anything :-( <foxmean>roptat: I'm using make from xbps (package manager of Void GNU/Linux) and makeinfo form guix package manager. Maybe I should try to use make from guix instead, or it fine? About your question: I've not yet run ./bootstrap and ./configure --localstatedir=/var . <truby>roptat: does the cubietruck have uefi? I've been looking for an arm dev board that has UEFI for playing around with <desmes>truby: Oh really? I'll check it out then. <roptat>then you should, how is your Makefile generated otherwise? <roptat>I've added the cubieboard-u-boot-bootloader to guix when I installed it, btw :) <truby>I see, that's a shame, my search continues :-) <roptat>foxmean, if you have guix installed, the easiest way to have all dependencies is by running "guix environment guix" which creates a temporary environment where you have everything installed <foxmean>And also didn't work when run "make doc/os-config-bare-bones.texi <foxmean> doc/os-config-desktop.texi doc/os-config-lightweight-desktop.texi" <roptat>I mean, it should be only a one line command <roptat>then I think it's all you're missing <foxmean>Is it "make doc/os-config-bare-bones.tex doc/os-config-desktop.texi doc/os-config-lightweight-desktop.texi" ? <foxmean>The shell said "make: *** No rule to make target 'doc/os-config-bare-bones.tex'. Stop." when I run it. <efraim>hmm, it seems ghc-ncurses doesn't need ncurses5 after all <foxmean>It's work. But how can I check the guix.info file. When I run "info guix.info" the guix info of my system was show instead. If I view it with less or emacs it show only authors and some meta-data instead. The detail is: https://paste.debian.net/1106127/ . It also generated guix.info-1, guix.info-2, guix.info-3, and guix.info-4. I've checked it and there are also contain something like meta-data too. <roptat>another possibility is to generate the html version and open it with your browser <foxmean>But I've some question to ask janneke. It's about in E-mail that you suggest me to change "/var" to "@localstatedir@" is it necessary? Because I've not try it in my system, so I fear that it will not work for the others :(. <janneke>foxmean: ah...right; where does the file live or your system? ***MinceR_ is now known as MinceR
<janneke>foxmean: i meant the for the /var in /var/guix/profiles/... <foxmean>Sorry, I am not completely understand your question. Is it mean: /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon ? <foxmean>Or is it mean I am using Void GNU/Linux not guix live system? <wdkrnls>Hi Guix, I've started seeing "guile: warning: failed to install locale" every time I execute guix commands. <roptat>foxmean, @localstatedir@ in a .in file is automatically replaced by whatever you pass to --localstatedir when running ./configure <roptat>wdkrnls, have you pulled recently? :) <roptat>there's a new glibc version, and it could explain why you see these messages <roptat>there's a news entry that explains what you need to do (run guix pull --news) <wdkrnls>roptat: I think I tried to pull again in the hopes it would fix the problem. Now the news doesn't show anything about it, although I definitely missed it the first time. <wdkrnls>Is there a way to retrieve old news? <wdkrnls>Ah. Thanks daviwil. I suppose then I should just make sure to keep an up-to-date clone of the guix repository to find out the news. <daviwil>In my case, I saw that error after I pulled and did a system reconfigure, but after I rebooted the message was gone <roptat>wdkrnls, a system reconfigure should fix all your issues :) <roptat>basically, guix uses glibc 2.29, but your system currently only has locales from glibc 2.28 <janneke>foxmean: yes, `/var' is configure's --localstatedir=/var <roptat>reconfiguring it will install locales for 2.29 <janneke>foxmean: so if you look at etc/guix-daemon.conf.in you will see just that <wdkrnls>I'm curious if anyone is working on qt-5.12 series as I'm looking to build a package which depends on it. <wdkrnls>For posterity I discovered that 'guix pull --list-generations' shows the older news :) <efraim>wdkrnls: qt-5.12 is on the staging branch, its up next for fixing up and merging <efraim>out of curiosity, do you have a preference for 5.12 vs 5.13? <foxmean>janneke: I have more questions, how to add my file to etc/local.mk? Is it /doc/local.mk? <janneke>foxmean: and this is how i found it, try running: git grep guix-daemon.conf.in <janneke>foxmean: you know that whereever you need to add it, it will be alongside that file! <janneke>foxmean: for your next possible question and an maybe even bigger surprise, run: git grep guix-daemon.conf <foxmean>I'm so confused :(. Can I commit and sending patch to you? Maybe you can add something or just refuse it. So sorry, I'm newbie and also lay computer user that can help you much. <janneke>foxmean: yes, sure. but please send it to the bug report. <janneke>foxmean: sending an incomplete patch, asking for more help, can be a very good way of discussing <efraim>meson-build-system doesn't provision alternate outputs :( <wdkrnls>efraim: I suppose my preference is for qt-5.12 since that is the specified version in the installation documentation. From the QT website it appears that 5.12 is the LTS release as well, so I imagine a lot more software will be based around it. <truby>I get a weird error when trying to run guix from a source build with pre-inst-env: `error: failed to run download program '/home/truby/src/guix/scripts/guix': Permission denied` <truby>I can run `./pre-inst-env /home/truby/src/guix/scripts/guix` though, and it works fine <daviwil>Not sure what/who did it, but I'm very happy that, after my most recent pull, NetworkManager now reconnects wifi correctly after waking from suspend! <daviwil>Was considering switching to wicd to see if that improved the situation any, but glad I don't have to now <daviwil>So aside from being able to roll back versions easily, what's the benefit of installing Emacs packages through Guix versus [M]ELPA? <daviwil>One upside I've considered is that certain packages like (emacs-helm-pass) can depend on the external program they rely on, causing it to be installed also. Seems like that might make setup a lot easier <truby>daviwil: tbf I think being able to roll back is pretty big given how unstable melpa can be :-). I couldn't work out how it'd interact with spacemacs though *truby wonders if spacemacs could be patched to use guix.el to install the packages it wants... <montokapro>Hi all - I'm a newbie trying to follow the contributing guidelines extra closely. My emacs package does not build for mips systems - should I resolve before contributing? https://pastebin.com/p0b9xKLB <daviwil>truby: I think the idea is that if the Emacs packages are already installed in your load path, Spacemacs won't try to download them again since they'll already be present, as far as it knows. But yeah, if you haven't already installed the corresponding Emacs package before loading up the Spacemacs layer, it'd have to know how to invoke Guix and what the package name might be <truby>the package name would be the same but prefixed emacs- right? but yeah spacemacs won't load packages that are already installed.. if I knew what packages spacemacs installs heh