IRC channel logs


back to list of logs

<guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 23:58:04 on 2020.04.27
<mroh>wow, fatal: unable to access '': The requested URL returned error: 502
<mroh>works now
<guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 00:01:04 on 2020.04.28
<bandali>mroh, i'm looking, but i'm not yet sure what's going on. it seems that retrying one or a few times should work, at least as of now
<mroh>bandali: ty very much!
<bandali>cheers :-)
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:15:58 on 2020.04.28
<guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:15:59 on 2020.04.28
<guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 00:20:04 on 2020.04.28
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:20:04 on 2020.04.28
<guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:20:05 on 2020.04.28
<bdju>new bot? interesting
<bdju>it seem unstable, though.
<guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 00:26:04 on 2020.04.28
<vagrantc>bdju: i think it only connects long enough to report an issue
<vagrantc>which ... is a bit annoying
<vagrantc>what's the storage capacity of the build farms? seems like it could maybe use an order of magnitude bump...
<reepca`>sneek: botsnack by comparison
<vagrantc>i can see the reason to not have the bot running on the machine where it reports ... and setting up a bouncer would be more complicated
<raghavgururajan>mbakke Sure thing.
<raghavgururajan>bricewge Ah, I should not have removed python-releated changes in v2 patch. My mistake. Will fix it soon.
<raghav-gururajan>janneke, Thanks for the changes and pushing it. I was wondering why not to use "~/.guix-profile/sbin?
<camlriot42>hello, whats the correct syntax to add spice service to config.scm mentioned in here:
<dissoc3>camlriot42: i don't really know anything about spice but i took a look at the service file for it. what are you trying to configure?
<camlriot42>trying to run guix in qemu-kvm
<camlriot42>I downloaded the qemu image
<camlriot42>I wish to add the spice service in config.scm copied from here:
<guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 00:53:40 on 2020.04.28
<guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 00:53:41 on 2020.04.28
<camlriot42>dissoc3: could you suggest what should I add to enable the spice service?
<mroh>camlriot42: try (spice-vdagent-service) in your service list
<dissoc3>camlriot42: did you add it to your services?
<dissoc3>i did what mroh suggested and it appears to work for me
<camlriot42>tried this one (service spice-vdagent-service-type)
<camlriot42>okay adding that
<dissoc3>just add spice to (use-service-modules ... spice)
<camlriot42>only ^ and not this (spice-vdagent-service) ?
<camlriot42>or both
<camlriot42>seems to work. guix system doesnt complain. will report after reconfiguration is done. thanks!
<camlriot42>from log files: localhost spice-vdagentd: GetSeats failed: The name org.freedesktop.ConsoleKit was not provided by any .service files
<camlriot42>localhost spice-vdagentd: (console-kit) seat: (null)
<camlriot42>clipboard works. but display scaling doesnt
<camlriot42>localhost spice-vdagentd: no session info, max 1 session agent allowed
<camlriot42>any clues about what could be wrong in config.scm
<mroh>maybe you need to configure the agent to do scaling etc, but i dont know anything (domain specific) about spice-vdagent, sorry.
<camlriot42>no problem. will search further. thanks
***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<c4droid>Hi, I'm porting the guix to my lfs system, guix can work well with sysvinit?
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:40 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:41 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:46 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:47 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:58 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:59 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:58 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:59 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:52:04 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:52:05 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:52:40 on 2020.04.28
<guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:52:41 on 2020.04.28
<c4droid>Hi, I'm porting the guix to my lfs system, guix can work well with sysvinit?
<jackhill>c4droid: I don't see why not. I'm not sure if the installation script supports, it, but I think all you need is a service that runs the guix-daemon
<jackhill>c4droid: it looks like it has been worked on, so why not give it a wirl and report problems here oron the help mailing list or bugtracker as appropriate
<c4droid>jackhill: I'll check has sysvinit support, and then I'll go through the documentation to find the part about the transplant to my system.
<c4droid>But the way, thanks for your answer, jackhill.
<jackhill>c4droid: you're welcom
<vagrantc>hrm. updating glibc-*-locales in guix always seems a bit rough ...
<vagrantc>if i have a system running core-updates, but a user profile not running core-updates ... i can't seem to figure out how to get it to use the correct locale package
*vagrantc wonders if unversioned glibc-*-locales should even exist
<vagrantc>leaving the old locale packages around doesn't seem to be enough ...
<vagrantc>which breaks programs such as i3status and tmux ... they refuse to even work as they can't find their locales
<vagrantc>apparently setting GUIX_LOCPATH=/home/USER/.guix-profile/lib/locale works ... shouldn't that be set by default?
<vagrantc>probably even has something about this in the manual...
<raghavgururajan>Hello Guix!
<raghavgururajan>When I run 'ktsuss", I get "bash: run: command not found".
<raghavgururajan>What is this run command?
<raghavgururajan>It is not provided by any package.
<xelxebar>I bet ktsuss is a script, no?
<raghavgururajan>xelxebar I recently packaged ktsuss
<raghavgururajan>xelxebar It is in master now. I also fixed some issued. But this one I am not able to get around.
<akoppela>I'm using Guix on top of Debian. I'd like to use Shepherd to run NGinx. Is that a good idea or should I use systemd?
<raghavgururajan>xelxebar So after adding ktsuss to setuid-programs, when I run 'ktsuss foo`, the popup appears for authentication. When I enter username and password, the program foo is executed but not in root mode as it should be.
<akoppela>GuixSD provides web services to configure NGinx, can I reuse that to run NGinx with Shepherd on Debian?
<raghavgururajan>xelxebar shebang?
<xelxebar>raghavgururajan: No, the error you report is bash complaining that the 'run' command doesn't exist. It looks like defines the 'run' function there.
<raghavgururajan>xelxebar But that script is for building right? I am not sure how it is affecting the application during run-time.
<xelxebar>raghavgururajan: Yeah, something is screwy. That error is *bash* complaining. Why is your executable running bash?
<xelxebar>You should do some sanity checks that the executable is really what you think it is
<xelxebar>what does this say? file $(command -v ktsuss)
<xelxebar>raghavgururajan: Also, if the package is fundamentally broken, how did it get into master in the first place?
<xelxebar>Better yet,
<raghavgururajan>xelxebar I don't think it is fundamentally broken. I think it is due to hardcoded FHS.
<raghavgururajan>xelxebar I tried packaging another similar progam called GtkSu. I get similar error there too.
<raghavgururajan>But there instead of "bash: run: command not found", i get "sh: foo: command not found". Here foo is that is passed as `gtksu foo`.
<xelxebar>raghavgururajan: Well, if it's failing to run under Guix, it's a broken guix package.
<xelxebar>Wait... how exactly are you calling it?
<xelxebar>Mostly likely "foo" actually doesn't exist...
<raghavgururajan>I just typed 'gtksu foo' in terminal. Similar to 'sudo foo'.
<raghavgururajan>I tried nano in the place of foo
<xelxebar>Does foo exist as a command on your system?
<raghavgururajan>yes, it does.
<raghavgururajan>sudo foo works. but not gtksu foo.
<reepca`>well, to be precise, it would matter whether foo exists as an executable in $PATH, as "command" technically can include shell builtins IIUC
<xelxebar>what does command -v foo say?
<xelxebar>reepca`: Yeah, or shell functions, aliases, etc.
<xelxebar>It's likely an environment problem then.
<raghavgururajan>rg@secondary ~$ command -v nano
<xelxebar>and `ktsuss nano' complains that nano doesn't exist?
<raghavgururajan>xelxebar reepca` Sorry, forgot to mention that the error "sh: nano: command not found" was when doing `sudo gtksu nano`, after authentication as root.
<raghavgururajan>But when I just do `gtksu nano`, neither root nor user password works during authentication.
<raghavgururajan>I get wrong username/password.
<raghavgururajan>xelxebar reepca` Let me start over to simplify things. I think I was confusing earlier. These are the steps to reproduce.
<raghavgururajan>1) Install GtkSu from
<raghavgururajan>2) Run `gtksu nano`
<raghavgururajan>3) You will get authentication popup window.
<raghavgururajan>4) Neither root/password not user/password works.
<raghavgururajan>5) Error will be "incorrect username or password".
<raghavgururajan>6) Now, run `sudo gtksu nano`
<raghavgururajan>7) You will do two authenciation, one for sudo and one for gtksu. This time gtksu authentication works.
<raghavgururajan>8) But you will errror "sh: nano: command not found".
<raghavgururajan>That's it.
<xelxebar>raghavgururajan: I would focus on the first problem. Running "sudo gtksu" seems to completely defeat the point.
<xelxebar>Is gtksu setuid?
<xelxebar>In your position, I would first ask upstream for help finding the root cause. If it turns out that Guix's weirdness is a problem, then is when I would personally ask here.
<raghavgururajan>xelxebar Yes, thats why I also tried adding gtksu to setuid-programs and retried steps 2, 3 and 4. But same error.
<xelxebar>Debugging output?
<raghavgururajan>xelxebar gtksu works out of the box on trisquel. I tested.
<xelxebar>I can really only offer generic suggestions since I'm not familiar with the program itself.
<raghavgururajan>Yes yes, I understand.
<raghavgururajan>Okay, so the syntax is `strace gtksu nano` correct?
<xelxebar>Yeah, but that will likely spew out a ton of output. strace is really only useful once you have some idea of the syscalls you want to look at.
<bricewge>camlriot Can you report a bug about your spice-vdagent issue?
<bricewge>I think it's missing some build time arguments
<xelxebar>raghavgururajan: Try tracing the openat syscall: strace -e openat ...
<xelxebar>That can at least give you a good idea of the files etc. the program is trying to read
<raghavgururajan>`strace -e openat gtksu nano` correct?
<raghavgururajan>Okay got it.
<elais>has anyone tried to package lem or roswell?
<raghavgururajan>xelxebar Quick question, does xauth a setuid program?
<raghavgururajan>I suspect XAUTHORITY env-var is the culprit.
<xelxebar>On my foreign distro xauth isn't setuid
<reepca`>so I've discovered something somewhat interesting... I can't use sudo to run a command as another unprivileged user, but I can use it to run a command as root. And I can use su to do both.
<reepca`>(sudo just keeps saying I've given the wrong password)
<drakonis>ah this mid term roadmap looks interesting
<drakonis>guix shell will be good
<raghavgururajan>reepca` I see.
<reepca`>... hm, seems I didn't fully understand the difference between su and sudo. Apparently for sudo I need to give my password, while for su I need to give the other user's password.
<raghavgururajan>That's alright.
<raghavgururajan>I am working on something else now. Will get back to that later.
<raghavgururajan>Btw, is `getfacl` program provided by 'acl' package, a setuid program?
<akoppela>xelxebar: Isn't those docs for GuixSD? Or is that the same for running Guix on other host?
<janneke>raghavgururajan: %setuid-programs is a variable, defined in gnu/system.scm
<raghavgururajan>jannake Yes, I saw that. If I am adding additional programs as setuid programs, what criteria should I follow to see whether or not it is a good idea to make that program a setuis program?
<janneke>raghavgururajan: i think the main criterium is: "it's never a good idea to add one"
<raghavgururajan>jannake I wanted to know if it is safe to add "losetup" of util-linux and "setfacl" ot acl, as setuid programs.
*janneke is not a security expert
<raghavgururajan>I see.
<janneke>every setuid program is a possibly security problem
<janneke>what i'm saying is surely a bit too extreme...
<raghavgururajan>jannake Cool! Btw, regarding previous patch, why not to add "~/guix-profile/sbin"?
<janneke>raghavgururajan: good question: why not? :-)
<raghavgururajan>janneke Lol, you mentioned "No way!" as comment.
<janneke>what would happen, if I call ktsuss, from say a guix --pure environment?
<raghavgururajan>janneke Say no more. I understood now. Haha!
<janneke>raghavgururajan: good :-)
<janneke>raghavgururajan: also that comment was a bit black/white
<janneke>i did not read the ktsuss.c code; it /could/ just be that, depending on how and where that PATH is used, it would be sort of okay
<raghavgururajan>janneke Regarding fixing SpaceFM, I need to fix ktsuss and udevil first. I am working on fixing udevil now.
<janneke>raghavgururajan: good, will you make sure everything works before submitting new patches?
<raghavgururajan>janneke Yes :-)
<janneke>raghavgururajan: one more thing, i have been receiving so many pings from you that i am starting to ignore them
<raghavgururajan>janneke Sorry, I apologize.
<janneke>raghavgururajan: a ping can sometimes be nice if you forgot something, and especially if there is a deadline you should ping your mentor
<janneke>raghavgururajan: thank you -- it's not a problem, most people need to learn to ping sooner: the wait for 3 weeks for reaction on a form
<janneke>raghavgururajan: try to find some more balance between patience and being ignored :-)
<xelxebar>When packaging, is there a general way to find the sha256? For single-file archives, we can use guix download, but what about for specific git commits or texlive packages and the like?
<xelxebar>Filling in a dummy value and getting an error from guix build?
<Kimapr[m]>for git commits/branches/tags you can `git clone --single-branch --branch <x> <git repo path>`, cd into it and then `guix hash .`
<Kimapr[m]>idk if it works or not, so a fallback is to fill in a dummy value and get an error
<xelxebar>Kimapr[m]: Thanks. So there's not a general way to also prepopulate the store as well?
<efraim>Maybe gtksu and ktsuss reset PATH and that's why they can't find nano or any command
<reepca>hmm, is there a nifty command to start a process stopped? Like, all the program does is send SIGSTOP to itself and then exec?
<reepca>I'm in the odd position of wanting to use strace with the -f option, but it exec's a setuid binary
<reepca>so to trace it properly, the tracing process needs to be root IIUC
<reepca>but the running process needs to be not root...
<reepca>ah, seems the -u option to strace can get me the result I want
<reepca>regarding the ktsuss issue, it seems to work fine for me with one major limitation: no arguments can be used. There's a bug (I believe as yet unreported) in the sudo backend, or at least in how it interacts with our sudo. ktsuss assumes that its backends will do their own parsing of whatever command they're given, so it joins both the command name and its arguments together into a single string argument with spaces in between each
<reepca>one. Our su performs the parsing they expect, splitting it back up, but our sudo does not.
<devtexa>Does guix pull only support http:// https:// git repositories?
<Kimapr>afaik its whatever repositories git supports
<reepca>also, it seems to me that it shouldn't be a setuid binary, as the only part that requires elevated privileges is handled by either sudo or su. Aside from that issue with its sudo backend, it works fine for me as a regular executable.
<reepca>raghavgururajan: ↑
<devtexa>My repository using ssh:// failed
<devtexa>Is my command wrong?
<devtexa>guix pull --url=ssh://user@server/path/to/guix
<bricewge>Does your ssh need auth?
<bricewge>That's probably it then
<rekado_>guix-ci isn’t even a bot. It’s a single command line that pipes a message to IRC.
<rekado_>I don’t have enough time to write a bot, but if someone wants to do that I’d support them.
<devtexa>Then I try to add ssh key
<devtexa>it fail: guix pull: error: Git error: error authenticating: no auth sock variable
<devtexa>Where should this variable be written
<raghavgururajan>reepca Thanks so much. I will look into it.
<bricewge>devtexa: Does it need to be a private repo?
<reepca>I think there might need to be a colon after the server e.g. --url=ssh://user@server:/path/to/guix
<reepca>ah, never mind, I'm just used to using an alternate port
<devtexa>Okay, actually I am using a colon
<devtexa>Because the ssh port of my server is 2222
<bricewge>rekado_: Did I just broke
<bricewge>I was spamming F5, trying to clean the cache because of the search bar glitch, and got a 502...
<devtexa>To be honest, guix pull really needs to support http proxy
<bricewge>devtexa: It does “sudo herd set-http-proxy guix-daemon http://localhost:8118”
*raghavgururajan fixed udevil (#40922). \o/
<xelxebar>Ugh. Trying to package up this texlive component. Have no idea what I'm doing and it's slapping me around hard.
***apteryx is now known as Guest68547
***apteryx_ is now known as apteryx
<reepca>Not knowing much about how guix pull works internally, is there any architectural reason git can't just prompt for a password when it's run like normal?
<raghavgururajan>reepca What command did you try with ktsuss?
<bricewge>reepca: Maybe it's because the guix-daemon doesn't run as the user that execute guix commands, IDK
<reepca>bricewge: but it doesn't make any sense for the daemon to be fetching the repository. It only allows network access for fixed-output derivations (known hashes), but pulling by nature doesn't have that information.
<reepca>raghavgururajan: 'ktsuss echo hello' fails, 'ktsuss echo' succeeds.
<raghavgururajan>reepca Thanks! For me `ktsuss foo` always throws up "command passed is invalid".
<reepca>raghavgururajan: makes sense, it checks to make sure that the executable exists prior to passing anything to su or sudo. It also happens prior to smushing the command and arguments together into a single string.
<raghavgururajan>reepca Ah, so `ktuss foo` should work without --pure env.
<reepca>provided that foo exists if absolute or can be found in $PATH if the full filename isn't specified, aye
<raghavgururajan>reepca Yay, works now.
<raghavgururajan>So sudo_backend is the culprit.
<raghavgururajan> I have send another patch to disable sudo in ktsuss. su works fine.
<raghavgururajan>*have to
<reepca>indeed. That or our sudo is behaving differently than most other sudos. Not sure which.
<reepca>just checked on Ubuntu 18.04.3, sudo "echo hello" doesn't work there either.
<reepca>so it seems it's probably a bug in ktsuss
<lprndn>Hello guix!
<janneke>str1ngs: i've tried everything with my pinebook-pro wrt "mask mode"; it just feels totally dead
<janneke>str1ngs: thanks a lot for the info, though -- i would have hoped to get such hints from pine64 support :-(
<rekado_>bricewge: not your fault; again the malloc error
<rekado_>I wonder if we can trigger this reliably
<rekado_>I’m running mumi in a loop now … :-/
<bricewge>rekado_: It was just a coincidence then, spaming F5 again and mumi stays on it's feet.
<rekado_>since my wrist pain flared up again I’m thinking about adding a kaldi speech recognition service
<rekado_>it’s a pity they still use python 2
<rekado_>maybe this can be replaced…
<msiism>When I choose to install Guix with full disk encryption, why doesn't the installer choose to create an unencrypted /boot partition? How will the system be able to boot when everything is encrypted?
<Blackbeard>Hello guix :)
<bricewge>msiism: There was a mailling list thread about this a couple of weeks ago
<bricewge>Hey Blackbeard !
<msiism>bricewge: Thanks, I'll have a look.
<reepca>bricewge: think you may have meant "a couple of years ago"
<Blackbeard>liberdiko: hi
<bricewge>reepca: Oops, wrong one
<rekado_>msiism: GRUB can unlock the disk so you can boot. Linux will then unlock the disk once more.
<bricewge>Good catch!
<msiism>bricewge: Oh, well it was an interesting read nonetheless...
<bricewge>msiism: ^
<msiism>rekado_: Ok, I see. Is that a feature of newer Grub versions?
<msiism>This reply by Ellen Papsch is really great:
<camlriot42>hi liberdiko: I sent the logs of spice-vdagentd to bug-guix. cant see the report on mail archive or issue tracker.
<bricewge>About cross-compiling all the doc use “armel-linux-gnu” as triplet example, but using doesn't seems to work. Am I doing it wrong?
<msiism>Now, if I select a certain keyboard layout in the TUI installer, will I have that available in Grub on the new system? Because otherwise I'll have to remember two ways of entering my passphrase.
<bricewge>Hello camlriot your first bug report can take some time
<Blackbeard>msiism: you can configure grub before rebooting
<msiism>Ok, so I would set that there then.
<bricewge>camlriot: If you didn't received an error email you should be good
<Blackbeard>Change /etc/config.scm
<bricewge>camlriot: Thanks for reporting the issue BTW
<msiism>Blackbeard: Okay, I'll try that.
<camlriot42>liberdiko: no error emails. :)
<Blackbeard>And $ guix system reconfigure /etc/config.scm
<Blackbeard>msiism: make sure to copy config.scm to your home
<msiism>Blackbeard: you mean the original one?
<Blackbeard>I am not 100% sure about TUI process I always use SSH
<msiism>Well, I can just use a shell on another TTY to do that, can't I?
<Blackbeard>The TUI lets you edit it I think
<msiism>I see,
<msiism>Another question about partitioning:
<msiism>The guided partitioning will use over 100GB for root on my 320GB disk.
<Blackbeard>Finish the TUI, it will let you see the file before install
<Blackbeard>And edit it I think
<msiism>Usually, my root partition is 12-15GB. Is there any reason I should considerably increace that size for Guix?
<rekado_>msiism: since /gnu is on the root file system and upgrading or reconfiguring will add garbage to /gnu (until you run “guix gc”) it is recommended to have 50GB or more
<rekado_>this gives you enough headroom to clean out garbage later
<rekado_>it’s not that the system needs that much
<rekado_>it’s just that by using Guix you add stuff to /gnu
<Blackbeard>Guix will save generations and they are awesome
<Blackbeard>So it needs a bit more space
<rekado_>e.g. when building a new system that in the absolute worst case shares nothing with existing stuff in /gnu means that you’ll need twice the size of a regular system installation
<sirmacik> rekado_: did you get swank working in stumpwm?
<rekado_>or playing with “guix environment” will install things to /gnu
<rekado_>even thought things are not permanent
<sirmacik>I've found your email during my search and I have the same problems
<rekado_>you can remove unused stuff with “guix gc”
<rekado_>the point is just that you may need more space to be comfortable
<rekado_>the /gnu directory is a big cache
<rekado_>having it too small means that you’ll constantly have to collect garbage, and that’s just no fun
<rekado_>sirmacik: I’m not using stumpwm any moer.
<msiism>rekado_: Hm..., so, putting everything on a single partition seems the better way to go about this then.
<msiism>Well, at leat if you really want to save space at all cost.
<msiism>I think I don't.
<jonsger>I heard rumours that having /gnu on a btrfs partition with compression enabled, should help
*raghavgururajan fixed udevil, ktsuss and spacefm. \o/
<xelxebar>I like to keep my /gnu on a btrfs subvolume and share it between OSes
<sirmacik>rekado_: >: so far it seems that the simplest way is to install stumpwm via quicklisp and run it from there
<efraim>msiism, jonsger: the uncompressed->referenced difference is guix deduplication
<rekado_>sirmacik: maybe you need stumpwm-checkout as seen here
<sirmacik>I've tried that but it always shows something about no ,stumpwm-checkout
<rekado_>what shows this message? What’s the exact message?
<sirmacik>I can post it later today, can't remember it right now. Until then I need to finish some work >:
<efraim>also when relevant, it can be faster to read and decompress data than to just read it from a disk
<mbakke>something is locking the SQLite DB on Berlin for more than an hour:
<mbakke>Perhaps it could be worth switching to Postgres.
<rekado_>mbakke: must be my GC proces
<rekado_>I’m deleting stuff mentioned in /gnu/big-stuff
<dutchie>which package should I install to get the gradle command?
<dutchie>meta-question: is there a quick way to answer the question "which package contains this path"?
<efraim>is there something like head but it only takes the first X characters instead of the first X lines?
<rekado_>mbakke: should I cancel it?
<dutchie>efraim: i think head has an option for that
<efraim>that would make sense
<mbakke>rekado_: dunno, how long do you think it will keep running?
<mbakke>dutchie: I don't think gradle is packaged yet
<efraim>guix refresh -l icu4c@64 | head -c86
<efraim>maybe now I can stop passing it through cut or less to only get the number of affected packages
<dutchie>mbakke: ah. well i'd still appreciate an answer to my meta-question
<dutchie>maybe i should post it to guix-users or guix-devel
<rekado_>mbakke: it’s in the stage of deleting hardlinks. Merely *reading* the entries in the /gnu/store/.links directory (no stat calls, just readdir) takes about 85 minutes.
<rekado_>it’s fine to abort it and start it again later
<mbakke>dutchie: yes, it comes up every now and then. There was a recent discussion but I don't remember the outcome.
<rekado_>we have 5.8T free, which isn’t great, but it’s not extremely urgent to finish this now
<efraim>dutchie: there isn't an easy answer. I normally use find against the store, but that only works if you actually have it already
<efraim>sometimes I hit up debian and use apt-file to find the package and then apt show to see what the source is to map it to one of our packages
<dutchie>yeah, my current strategy is to `guix build` some plausible looking packages and then look in them
<mbakke>rekado_: I guess there is no "good" time, so might as well let it finish now?
<efraim>new plan: import pkgsrc and use their PLIST to see what files are installed
<bricewge>dutchie: Point 2 in
<mbakke>rekado_: do you know what happened here?
<bricewge>Pierre Neidhardt has a grant from NLNet to work on it
<efraim>I hope he has a better idea than my pkgsrc idea
<reepca>rekado_: out of curiosity, any idea what $(number of links outside of /gnu/store/.links GC'ed)/$(total number of links in /gnu/store/.links) is for a typical gc run?
<dutchie>bricewge: awesome, i will await the results eagerly :)
<reepca>actually, more useful number might be more like "what percent of /gnu/store/.links is usually actually deleted during the link-deleting phase?"
<rekado_>that also depends on the number of things that are marked for deletion. I usually feed “guix gc” a list of files.
<rekado_>only a very small amount of files will be deleted from /gnu/store/.links
<rekado_>that directory is massive
<mbakke>I wonder if removing dead links needs a DB lock at all
<demotri>rekado_: Do you know why the German Cookbook 404s:
<demotri>rekado_: I found out why the full-page version in all languages is missing and I have a patch for it. But I wonder why the noded-German version is missing.
<demotri>This is to fix #40803.
<Kimapr>oof. `guix gc -d` deleted my alternate profile
<Kimapr>ah, not one, but all which wasn't in root of my home directory
<mbakke>Kimapr: you mean it essentially did rm -rf /home/you/some/alternative/profile !?
***CcxWrk is now known as Guest9572
***CcxWrk_ is now known as CcxWrk
<rekado_>wip-haskell-updates is 5 months old. Can we remove it?
<bricewge>camlriot: It went trough Next time it'll be quicker.
<mbakke>rekado_: I think so
<rekado_>I’m removing the spec from cuirass first
<demotri>dutchie: Gradle is not part of Guix yet. See and
<demotri>dutchie: It is hard to impossible due to its dependencies.
<reepca>could we use the nlink stat field to get a much smaller set of links to consider deleting? For example, consider only the links corresponding to deleted files whose nlink value was 2 prior to deletion. We'd have to hash them to find the link, but the set should be quite small.
<reepca>of course, for that to really work we'd have to forbid hardlinks into the store from places outside of it, but that doesn't seem like a common occurrence
<dutchie>demotri: fair enough
<camlriot42>liberdiko: okay. thanks!
<demotri>dutchie: People who solve the gordian knot of dependency hell are always welcomed :-)
<rekado_>bring your own sword
<demotri>rekado_: Do you know why the German Cookbook 404s:
<rekado_>demotri: it must not have been built
<rekado_>maybe check the maintenance.git repo
<demotri>Hm. OK.
<Blackbeard>I was in the hospital all night again. Finally home at 6:30 am hopefully tomorrow I'll be better and send the patches :)
<demotri>I found out why the others where not built (i.e. the all-in-one-page cookbook).
<demotri>But I wanted to be sure with the html_node version is not another problem.
<demotri>I thought maybe you know a reason. Locally it builds OK. I will double-check the serving part in maintenance.git.
<demotri>I have a patch for the doc/build.scm that will fix the others. Will submit today.
<rekado_>I haven’t looked at this at all. I don’t know what’s wrong there. Sorry
<demotri>OK, thanks anyway.
<sirmacik>hm, what should I put in config.scm for mcron to create directory /var/cron/tabs?
<sirmacik>I've got (service mcron-service-type), but crontab -e still returns that there is no such directory
<rekado_>sirmacik: I think the mcron-service-type should extend the activation type and create the directory
<sirmacik>but it doesn't >:
<sirmacik>there is no /var/cron directory
<rekado_>sirmacik: yes, I’m saying it should
<sirmacik>oh, ok (;
<rekado_>so someone would have to fix this
<rekado_>would you like to do that?
<rekado_>we can do this together
<sirmacik>I'd like to
<sirmacik>where shall we start?
<rekado_>have you ever submitted a patch for Guix?
<sirmacik>nope, I've cloned guix repo though, I plan to make few missing packages following already present examples
<sirmacik>I know how to create patch to send it in an email
<rekado_>sirmacik: okay, cool
<rekado_>then let’s edit the code!
<rekado_>the mcron service type is defined in gnu/services/mcron.scm
<rekado_>you’ll see that the service type has two extensions of other services
<rekado_>it extends shepherd-root-service-type (to install a shepherd service) and profile-service-type (to add mcron’s executables to the system profile)
<rekado_>we need to add another extension
<Kimapr>mbakke: yes, the profiles /home/me/*/* are gone but not /home/me/*
<rekado_>we want to extend activation-service-type
<rekado_>this allows us to perform a few tasks to prepare the service
<rekado_>since we don’t want to figure this out all by ourselves, let’s copy this from some other service
<rekado_>let’s open gnu/services/audio.scm
<rekado_>at the very bottom is the definition of mpd-service-type
<rekado_>it declares an extension of activation-service-type with mpd-service-activation
<sirmacik>got it
<rekado_>mpd-service-activation is defined right above
<sirmacik>renamed to mcron-service-activation and put in mcron.scm
<rekado_>as you read it you’ll see that it gets a user id, creates a directory structure with mkdir-p (defined in (guix build utils))
<rekado_>and then it chowns the directory
<rekado_>who would be the owner of /var/cron/tabs ?
<sirmacik>user will be the owner of crontab file
<rekado_>let’s do without the chown for now
<rekado_>by default the file will be root owned
<rekado_>the activation snippet will have become pretty small now
<sirmacik>(let ((directory "/var/cron/tabs")) (mkdir-p directory)) ?
<rekado_>you could even do without the let
<sirmacik>it would be usefull though for later chowns and mods
<rekado_>we can add it once we actually need it
<rekado_>now you just need to add (service-extension activation-service-type mcron-service-activation) to the list of extensions of the mcron-service-typeo
<rekado_>don’t forget to add a copyright line for yourself to the top of the file
<rekado_>and maybe test this: sudo -E ./pre-inst-env guix system reconfigure …
<sirmacik>testing out (:
<sirmacik>cant see any credits in the file
<sirmacik>where is ./pre-inst-env file placed?
<sirmacik>I can't see it in guix main directory
<janneke>hmm, when i use guix -pull --profile=~/.config/guix/p --channels=channels.scm; all packages are remvoved from that profile?
<mbakke>Kimapr: are you able to reproduce it? please file a bug report, that is obviously not supposed to happen
<janneke>do we/i need to keep guix-profiles and package-profiles separate?
<rekado_>sirmacik: you need to bootstrap and configure your checkout first
<pinoaffe>is there a recommended way to find a committer's nickname?
<sirmacik>going to the docs then (:
<mbakke>janneke: guix pull will replace the contents of the profile you are using
<rekado_>sirmacik: I recommend checking out this video:,-part-one/index.html
<pinoaffe>because it usually takes me quite some time to find out who to ping if I've got a question
<rekado_>pinoaffe: there’s no list of IRC nicks, but sometimes .mailmap can help
<pinoaffe>rekado_: aight, thanks
<janneke>mbakke: okay, so using a separate profile for guix+ and packages installed from guix+ makes sense!
<mbakke>janneke: right, just like 'guix pull' vs 'guix package'
<mbakke>or ~/.config/guix/current vs ~/.guix-profile
<janneke>mbakke: good thanks! .. yes!
<pinoaffe>rekado_: would you (or someone else who worked on the mpd service) mind taking a look at some time?
<Kimapr>ah, it didn't delete the profile links, but it deleted the actual profiles from the store
<Kimapr>seems like gc operation didn't detect them as roots
<Kimapr>mbakke: i won't try to reproduce it again because that's unwanted as it deletes profiles that i need and restoring them takes time
<rekado_>pinoaffe: it seems like a bad idea to store passwords in plain text in the store (which is readable to all)
<rekado_>is there an alternative?
<mbakke>Kimapr: did you invoke 'guix gc' as your user?
<rekado_>Kimapr: is this all on the same system or is the daemon running on a remote system?
<Kimapr>rekado_: it's all on the same system
<rekado_>hmm, okay
<pinoaffe>rekado_: the mpd config file only supports plain text passwords, so it'll have to end up in there in plain text format
<rekado_>I’ve only seen this before in cluster operation where the daemon cannot access the profile links and thus determines that the profiles are not in use
<rekado_>pinoaffe: I see
<rekado_>on traditional systems we could at least make the file readable by only the mpd or root user
<rekado_>with files in the store we cannot do this.
<pinoaffe>yeah, that kinda sucks
<rekado_>it may not be a problem because users of the mpd service might not have access to the file system
<rekado_>but it’s not ideal and it would be good to point this out in the documentation.
<sirmacik>hm after I run make authenticate i tells me there are no rules for that :o
<rekado_>sirmacik: skip that
<rekado_>even if it works it doesn’t work :)
<sirmacik>ok (;
<rekado_>the instructions are incomplete, in the wrong order, and even then you may not have all keys to actually authenticate all commits.
<pinoaffe>rekado_: okay, I'll add that to the docs
<Kimapr[m]>rekado_: aha, i seem to understand why profile got deleted, i moved its link to another directory (actually just renamed the old one, but anyways)
***Kimapr_ is now known as Kimapr
<sirmacik>rekado_: I'll watch the video then, patch will be pushed later today
<civodul> <- could be relevant for some of our work
<rekado_>“Virtualization and isolation” —> Hurd
<rekado_>bah, newer versions of python-fastlmm require the proprietary mkl. The older versions require Python 2
<efraim> returned nothing
<rekado_>probably isn’t very popular
<rekado_>used for bioinfo
<janneke>after`guix -pull --profile=~/.config/guix/p --channels=channels.scm', ...p/etc/profile only contains a PATH setting; i would somehow have suspected GUILE_LOAD_PATH, GUILE_LOAD_COMPILED_PATH settings too?
<janneke>`guix environment --ad-hoc guile' also does not add those
<janneke>how should i access the guile modules from a named profile using guile?
<efraim>wow, they really hook mkl in there deep in the
<efraim>janneke: I suspect the easiest option would be to add guile to that profile and use that guile
<janneke>efraim: that's what i did before...but you cannot do that
<janneke>if you add guile, and then `guix pull' to the same commit, you get another "generation dance"
<janneke>guix pull will delete guile from that named profile
<efraim>what about using that guix to create an environment with guile in it
<janneke>efraim: yes, i did that -- but that does not add the GUIX modules to GUILE_LOAD_*PATH
<janneke>it seems guix and guile would need to be in the same profile...but you cannot really do that?
<efraim>guile takes an '-L' flag, or '-C' for compiled flags
<efraim>but yeah, that's the dance I had one time I wanted to play with shepherd from the guile repl, I had to add shepherd and guile to the environment
<janneke>yes...i'm not scripting my way around it, adding the named profile myself
<janneke>but it feels like i'm missing something :-)
<efraim>i've used $GUIX_ENVIRONMENT/lib as a location before :)
<str1ngs>janneke: it's an interesting scenario to be sure. I'm a assuming you want to use guix as a module? I just install guix in a profile with guile. but that means I only get version 1.1.0. I just make sure the pull version is first in my PATH. I'm not sure if this is the best way either.
<ruffni>i've written some package definition (in my home dir) and would like to know whether guix can build it. how do i point `guix build` to the definition? do i have to store it in the right place?
<rekado_>ruffni: you can use “guix build -f the-file”
<roelj>If I use a channel with multiple Scheme modules, should I do something special in the code of the channel to compile the Scheme modules?
<roelj>And how does it handle patch files? I store them in the repository root (the channel is a Git repository). Will that cause any problems?
<Kimapr>How to delete a vm created by `guix system vm`? What does the "returns a script" part in `info guix`/Invoking `guix system` means?
<Kimapr>does it put a path to it in stdout/stderr or makes a symlink on a specified path?
<ruffni>hmmm.. i copied the example hello package definition (from the docs) to a file and ran `guix build -f the-file`. guix responds: `(define-module (gnu packages hello)
<civodul>hi roelj!
<civodul>roelj: nothing special to do: the Scheme modules are automatically compiled upon 'guix pull', see
<civodul>for patches, nothing special either
<civodul>except that the file name is relative to the root of the channel
<ruffni> guix build: error: #<unspecified>: not something we can build.. but no line number or anything
<civodul>(unlike in Guix proper)
<civodul>ruffni: your file must return a package; so if you wrote (define foo ...) then add "foo" as the last line
<roelj>civodul: Cool! I think that should work fine then. I don't understand why hpcguix-web then throws an exception with: wrong-type-arg "string-null?" "Wrong type argument in position ~A (expecting ~A): ~S" (1 "string" #f) (#f)
<civodul>roelj: heh, not enough info to help on that one :-)
<civodul>Kimapr: in general, users don't have to "remove" items from the store specifically
<civodul>just run "guix gc" once in a while
<civodul>Kimapr: re "returning a script": the output of 'guix system vm' is a script called '', that's what it means
<roelj>civodul: Yeah, it's probably my own fault. But now you've already ruled out the channel stuff. So, you've been very helpful as always! :)
<civodul>heh cool :-)
<ruffni>i hope you don't mind my noob questions.. `guix show ode` shows the right package but won't recognize #:use-module (guix packages ode) (no code for module)
<pkill9>ruffni: you need to use (gnu package ode) not (guix packages ode)
<alextee[m]>hi, just sent a patch to update lv2!
<ruffni>i changed the lines but still get the same error msg... `no code for module (gnu package ode)'
<rekado_>ruffni: “package” or “packages”?
<roelj>I can't find (gnu packages ode) in a recent Guix checkout :) Did ruffni create this module?
<ruffni>no, i thought that if i can find a package via `guix show pkg_name` i could also include it in another package definition.... how wrong am i?
<roelj>ruffni: Ah, so "guix package -s ^ode$" shows: location: gnu/packages/game-development.scm. Which means you need #:use-module (gnu packages game-development).
<roelj>instead of #:use-module (gnu packages ode).
<ruffni>got it, thanks!
<pkill9>has anyone used pipewire?
<ruffni>ok, hopefully last one for today: there is this jackd2 dependency (which i guess is debian for jack2) which is (as mentioned by running `guix show jack2`) defined in (gnu packages audio). guix' response: `error: jack2: unbound variable`
<mbakke>ruffni: the variable name is 'jack-2'
<pkill9>should earlyoom be added to %desktop-services? it's great
<roelj>ruffni: You can get the actual name of the variable by doing "guix edit jack2" and have a look. Usually it is the same as the package name, but sometimes, like in this case, it differs.
<ruffni>i see :) thanks
<ruffni>is there something like a tutorial for defining packages (a little bit more complicated than the gnu hello one)?
<pinoaffe>ruffni: not really, but generally the start is not really more difficult than the gnu hello one, the difficult part is in finding workarounds for annoyances in the build processo
<ruffni>true that. i just might write down what obstacles come down the path (from the newbie perspective)... maybe it's useful for other newcomers? just like finding where a variable for a package is defined and how to look it up. i'm sure it's in the docs but for someone like me it's difficult to find out by myself
<roelj>ruffni: You can also get the symbol name from the Guix HPC site. See for example: . It shows the symbol name under "Symbol name"
<ruffni>how do i get the scons-build-system to run with python2?
***daviid is now known as Guest93705
<mbakke>ruffni: try grepping the guix sources for 'scons-python2' for examples
***leoprikler_ is now known as leoprikler
<NieDzejkob>I think I've figured out how to build Rust 1.40, expect news in 3 hours :D
***daviid is now known as Guest38650
<alextee[m]>can s omeone update meson plz, it's been too long
<alextee[m]>0.50 is already ancient
<efraim>hmm, pkgsrc doesn't support valgrind for powerpc
<efraim>but debian provides valgrind for powerpc
***Guest38650 is now known as daviid
<rekado_> alextee[m]: it’s 0.53.2; that’s from February
<rekado_>(on core-updates)
<alextee[m]>on core-updates :D
<alextee[m]>i hope it will get merged to master soon
<nagamalli>bricewde, nagamalli: guix build evolution-data-server --check --no-grafts -K
<nagamalli>It'll keep the output in /tmp/guix-*, just use ripgrep there.
<nagamalli>Build failed after some time.Plz suggest why?
<rekado_>woo, got speech recognition to work.
<rekado_>it’s a huge gstreamer pipeline, but it works somewhat
<rekado_>no need for the kaldi-gstreamer-server; all we need is the gstreamer plugin and model files
<rekado_>I’ll need to look for a better language model, or train a new one
<bricewge>nagamalli: What were you trying to achieve again?
<nagamalli>bricewde : Actually I was suggested to do the task regarding Evolution-data-server.In that I looked visually and
<nagamalli>inspected the tarballs of the versions of EDS we are trying to use and instructed to see
<nagamalli>whether the line G_DEFINE_AUTOPTR_CLEANUP_FUNC (ESource, g_object_unref); in the folowing path plugins/eds/gtd-eds-autoptr.h
<nagamalli>but it was not there , so i looked at
<nagamalli>Here its stated that pipeline doesn't work until the changes are done in EDS.
<nagamalli>And this pipeline is failed.
<bricewge>nagamalli Please share the log of guix build (it should be written at the end of the output if it failed).
<efraim>how do CPU optimizations work when building for another architecture?
<efraim>we would still want them as CFLAGS?
<bricewge>nagamalli: But for what I understand you don't need the build to succeed just look at the directory "guix build" created and you will find the source patched by guix
<nagamalli>bricewde:yes, i didn't find the suggested path as this plugins/eds/gtd-eds-autoptr.h , but i foung in this
<nagamalli>It checked the tarballs of various versions - THE LINE EXISTS
<nagamalli>The source itself its never removed. I shoudlve checked it first.
<nagamalli>Here its stated that pipeline doesn't work until the changes are done in
<nagamalli>And this pipeline is failed.
<honr>Hi. I'm trying to install Guix. I would like use a proxy server during the installation, how can I do that with guided installation?
<bricewge>I don't understand how this relates to Guix
<cbaines>honr, is this when trying to just install Guix as a package manager, or as an operating system?
<NieDzejkob>bricewge: I don't understand why you think this doesn't relate to Guix :P
<honr>cbaines: OS
<cbaines>honr, I'm guessing the terminal based graphical installer doesn't support specifying a HTTP proxy...
<NieDzejkob>a quick grep suggests that it does
<NieDzejkob>it should be next to the keyboard layout option
<cbaines>I think using a proxy at installation time has come up a few times before, maybe someone else can help
<NieDzejkob>(unless I'm misunderstanding what "newt" is)
<drakonis>newt is the installer
<honr>I read from the manual that I can use herd set-http-proxy guix-daemon if I choose to install manually. However, I want to avoid manual installation if possible
<bricewge>NieDzejkob I'm lost here... Is it related to a build failing of evolution-data-source or an issue in the tracker??
<civodul>honr: the installer allows you to choose a proxy from the F1 "parameters" menu
<honr>Thank you, I'll give it a try now
<NieDzejkob>bricewge: oh, I thought you were replying to honr, nevermind
<bricewge>Looks like a Matrix snafu
<NieDzejkob>alextee[m]: artyfx doesn't build after your lv2 version bump, could you take a look?
<alextee[m]>NieDzejkob: yes i know, same as ir and a couple of others
<alextee[m]>the issue is an upstream problem: they use _LV2UI_Descriptor instead of LV2UI_Descriptor (there was a typedef _LV2UI_Descriptor { } LV2UI_Descriptor and now it's typedef LV2UI_Descriptor {} LV2UI_Descriptor)
<alextee[m]>i'm sending bug reports to the upstreams of those 3 packages now
<alextee[m]>these packages so far: infamous-plugins, ir, artyfx
<NieDzejkob>alextee[m]: Okay, I'm glad to hear that! I also noticed that sorcer fails, but with a different error
<NieDzejkob>ERROR : can't open architecture file lv2synth.cpp
<alextee[m]>NieDzejkob: that has been failing for a long time
<alextee[m]>didn't bother looking at it :-) checking now
<thePiGrepper>hi, quick question. what's the difference between `guix -V` and `guix system -V`, besides taking 3 time longer to execute and having the word 'system' added to the first line?
<honr>civodul: thanks. however, after filling the proxy server (in the format addr:port, i don't know if this is right though), it shows "in procedure struct_vtable: wrong type argument in position 1 (expected struct): #f -- guix system: error: `/gnu/store/...-guix-1.1.0-.../bin/guix substitute died unexpectedly'
<honr>i don't know if this is related to proxy server
<noobly>my python installation is having trouble being found by my shell and by emacs. I set an alias to the proper location, and that worked in the shell, but org-babel still complained. I don't know whether to look more into org-babel to fix the problem, or maybe there's some guix-profile mistake i've made that would fix better.. any ideas?
<rekado_>re sorcer:
<alextee[m]>ah cool
<alextee[m]>we should have a way to auto disable packages in cases like these
<alextee[m]>not sure how it would work, maybe manually
<alextee[m]>if the user has it installed, don't upgrade, and if the user doesn't have it installed mark it as non-installable or something until the problem is fixed
<alextee[m]>or just show a message to tell the user it will be uninstalled if they upgrade
<alextee[m]>it's not nice when guix upgrade fails randomly
<lfam>thePiGrepper: They are different commands
<lfam>I'm not sure exactly what the entry point is for the first one, but the answer is basically that they do different things
<efraim>dustyweb: some of your python packages have (license? #f)
<dustyweb>efraim: oh good
<dustyweb>nice job me
<efraim>my eyes normally glaze over the synopsis, description and license fields
<efraim>"I can build it, I don't care if anyone knows what it's for!"
<lfam>The home-page is, however, critically important ;)
*lfam tests openldap graft
<efraim>doesn't matter what it points to, as long as its https :)
<lfam>Funny you should say that... I'm also getting of the FTP URLs for OpenLDAP
<lfam>We should probably get rid of them everywhere
<lfam>I was surprised that Valgrind stopped hosting their own tarballs
<efraim>looks like I already had the openldap source locally
<lfam>For 2.4.50?
<efraim>same, aparently since 3.0.4
<efraim>for 2.4.47
<lfam>There's a new release that includes a DOS fix
<lfam>I guess I don't really have a way to test it, short of making sure that curl and gnupg don't crash
<efraim>is that CVE-2020-12243?
<efraim>I just pushed openldap/fixed for it
<lfam>It's funny that this package has soooo many dependents but none of us use LDAP
<lfam>Perfect :)
<efraim>the other two CVEs from 2019 debian had listed looked like they were related to actually using ldap
<lfam>We should put the update on the next core-updates branch
<lfam>Do you think we should go ahead with a full "upgrade" replacement?
<efraim>dunno, i always assume something will break
<lfam>But like I said, is anyone actually using LDAP?
<lfam>Maybe they would have noticed these CVEs and let us know...
<efraim>input on 23 packages
<lfam>The big one is curl
<efraim>I meant to work on automating zram support but instead fixed valgrind, gd, elfutils and icu4c for powerpc
<lfam>What's going on with gd, efraim?
<efraim>gdImageString16 tests fail on powerpc and apparently 64-bit AIX
<efraim>probably a big endian problem for powerpc
<lfam>I see
<guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 22:08:04 on 2020.04.28
<dustyweb>efraim: resubmitted
<NieDzejkob>Hold on, isn't ensure-keyword-arguments just default-keyword-arguments with the arguments swapped?
<sirmacik>rekado_: I'm finally after work and sitting down to finalize that patch (:
<sirmacik>video has much clearer set of instructions
<guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 22:13:04 on 2020.04.28
<sirmacik>rekado_: one more question, what should be after that system reconfigure you've posted before?
<bdju>Just heard about PantherX and that it's based on Guix System. That's interesting.
<civodul>janneke: "I think we could try an explosive mixture of our two branches" -> love it! :-)
<sirmacik>rekado_: and its sent (:
<janneke>civodul: yes, what a great attitude!
<janneke>civodul: we would need for mothacehe to rebase on core-updates, and for us (me?) to rebase onto wip-disk-image
<janneke>and possibly merge some more wip-hurd-vm stuff to core-updates while we go
<honr>I tried to launch guix from the qcow image, however, there doesn't seem to be a /run/current-system/configuration.scm