<marusich>ScaredySquirrel, the invocation of "remove" is incorrect on line 62. You are passing only 1 argument, the procedure you create, but it requires 2. You need to add a second argument which is the list from which you want to remove services.
<marusich>Here is an example of how to invoke remove, using packages:
<leoprikler>I think it would be better to pull in the appropriate modules and use cons*
<atw>leoprikler: not sure, but that's my assumption having seen earlier versions of ScaredySquirrel's conifg. re editors: while installing a system, nano and zile may be most convenient as they're already available
<leoprikler>IIRC the default config writer uses (append (list ...) %base-packages) though
<marusich>Not sure what automated mechanisms exist... If I find myself in that situation, I try to walk through the bracket groups to find the problem. Does Emacs highlight matching brackets for you? that makes it easier.
<leoprikler>you don't really tell it how to find errors, since Emacs does not know the meaning of your program
<leoprikler>however, as marusich points out, it can highlight matching braces for you
<leoprikler>I personally prefer electric-pair-mode as already pointed out, but I'm sure there's something more visual out there if you look hard enough.
<marusich>ScaredySquirrel, once you fix your brackets, I can offer one more piece of minor feedback. In http://dpaste.com/3N6SGNG on lines 48-50, you construct the list of additional packages by mapping specification->package+output over a list of specifications. This works, but it relies on undocumented or undefined behavior in Guile. According to R5RS, the procedure used with map must return a single value; Guile's manual is silent on that topic. To
<marusich>avoid potential issues, you should replace specification->package+output with specification->package, which returns just a single output: the package.
<ScaredySquirrel>I can't even fix my config.scm in emacs it says wrong type argument: stringp, nil
<sneek>sputny, nckx says: Those errors & warnings are scary, but ‘normal’ (we all get them) and don't affect the boot. If your installer works there's nothing to worry about, if it doesn't it's unrelated to those messages and we'll need more info to find out why.
<sputny>nckx: What further information can I provide?
<roptat>so I tried to update ocaml this week-end, but it's difficult. I managed to get rid of camlp4 on the current version of ocaml by updating some packages, and I pushed the changes (camlp4 was blocking the update because it's not compatible with the newer version and not maintained anymore)
<roptat>I also ended up updating another ~50 packages after the ocaml update, and added maybe 5 more packages, but I'm stuck because we have two packages whose latest version is not compatible with the newest version of ocaml : bap and earley
<roptat>they are leaf packages, and all their dependencies are compatible
<roptat>I haven't tested coq yet, but I think it will work
<roptat>I'm going to a conference this week, so I won't work on it, and then I have my thesis, then holidays with my family, so if anyone wants to work on it, feel free :)
<efraim>You can keep the old version around a bit if you want, we've done that before
<jackhill>agg0: As I understand it though, it's more of an infrastructure problem. Guix pull doesn't work because the thing it is pulling from returns an error. Suvanna is, I believe, actually run outside of the Guix project.
<snape>ScaredySquirrel: so what don't you understand exactly?
<agg0>how is the lead on guix these days? I was running it for a few months about a year ago, but life forced a break on me. Now I can finally have fun again... if guix gets fixed hah
<snape>it's good, expect when nothing works and nobody's there
<agg0>jackhill: makes sense. But that shouldn't happen if we put out guix as a dependable system. I suppose if you aren't in my position your older config should run no problem. But talking about guix in HCP environments, while such basic issues easily occur, is a bit of a joke.
<agg0>Just to put it out there for the novices: lisps are the most enlightenemed languages out there. Once you get it, you got it. And even getting it isn't that hard))))
<agg0>jackhill: makes sense. Once I get my system set up, and I got a bunch of free time, I'd love to get into the backend of this project a bit more. I love everything it stands for and tries to bring to the table. I guess I just wish we had on-pay maintainers)))
<snape>ScaredySquirrel: for example, 'name' is a field of the 'user-account' structure
<jackhill>that said, in critical environments I think Guix provides enough rope for administrators to insulate themselves from breakage: e.g. pull from a local git mirror and, potentally, only adding known good commits to that mirror. Still it would be nice if doing so weren't required.
<snape>ScaredySquirrel: as a more general strategy, I'd suggest that you start with a very simple config such as one given as example in the docs, and once you're sure it works, you try to add things to it little by little
<alextee[m]>does the installation of vimb fail for anyone else?
<alextee[m]>make: *** No rule to make target '../version.h', needed by 'main.o'. Stop.
<snape>alextee[m]: works for me on commit c6d130630a85709fc5a5488cfd6715ec13e72399
<nckx>sputny: Hm. If that's really all you see before the system freezes, I'm not sure. My own Guix is badly broken at the moment (not Guix's fault)… Have you verified the signature of the installer image? That would rule out download corruption. Someone else reported a similar error recently, but I don't remember who. Could you send a bug report with the information you've provided here to bug-guix at gnu.org?
<sputny>nckx: Yes, it's all I see. I have verified the signiture. I try once again. If it doesn't work out, I report a bug. Thanks a lot :)
<nckx>sputny: Wish I could say more, but you don't describe anything I've not seen myself on a successful boot. What kind of machine is this? When you say BIOS, do you mean non-UEFI? (Some still call UEFI ‘BIOS’.) UEFI in CSM mode?
<leoprikler>Does anyone else experience error 504 on git clone/guix pull?
<atw>leoprikler: I've had occasional failures on those but usually 502s
<bandali>though they are reported in #savannah, and lately i've been updating #gnu's topic with news about any disruptions to the gnu infra
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ servers are having serious issues: try and try again. | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
<nckx>If it's in #savannah's topic anyway, I'll be less euphemistic here.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ Savannah (guix pull) servers under attack: try and try again | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
<decent-username>Good evening. I tried to follow the instructions detailed in the video called "Installation from Script" from https:guix.gnu.org. But I have trouble importing the public key (At least I think that's what I'm supposed to do after downloading the script.).
<mbakke>nckx: I updated the description, thanks :-)
<leoprikler>That being said, Emacs specifically is currently not in a great state
<mrb`>They are in one profile together with emacs itself and some fonts. Emacs has all installed packages in its load-path, but can't find it's own lisp files. Does not matter if on console or X with exwm.
<mbakke>lfam: that assessment makes sense... I don't remember any more why I removed the "networking" requirement for openssh-service-type (07bf68ed09), it can probably be re-added while we figure things out.
<lfam>Now I am starting to remember why things are a little messed up regarding the default loopback interfaces. The static-networking-service is limited to a single interface, and might not even support ipv6 yet?
<lfam>Gabor had started working on the wip-netlink branch to overhaul this stuff but that work has paused
<g_bor[m]>on my setup 93 is the max that gets through currently, civodul tested it was 85 on 1.17.5, so somewhere around 80 should be safe. Of course it is not a great performancewise, but better than nothing.
<g_bor[m]>lfam: yes, right now I was waiting how the outreachy proposal turns out. We don't have an intern, so work could go on.
<g_bor[m]>I have seen some interesting problems documented in the recv-from! guile implementation, so this needs some thought, so that it is not a world stopper :)
<nckx>ScaredySquirrel: Nope, I'm going to keep working only from your first paste, not restarting from scratch every time. You're still not importing the openbox package module, and I remember that being discussed previously. Also missing are gnuzilla, xdisorg, vim, video, emacs. I commented out ungoogled-chromium-wayland, I guess that would require (gnu packages chromium) too.
<lfam>g_bor[m]: Do you remember if there is a code comment or email thread about why static-networking-service doesn't support ipv6?
<mbakke>lfam: I think it was just never implemented.
<nckx>Then you have (gdm-service-type) which should be gdm-service-type, otherwise you're calling it as a procedure.
<nckx>ScaredySquirrel: When I make all those changes the file builds perfectly.
<lfam>mbakke, g_bor[m]: Okay, I will look into the implementation
<g_bor[m]>lfam: I believe there is some info, but it boils down to that it is configured using ioctl, and that only supports ipv4.
<lfam>g_bor[m]: And netlink is the new way to configure this stuff?