IRC channel logs


back to list of logs

<voroskoi[m]>nevermind, I have figured it out
<civodul>just stumbled upon, which is sorta like "guix pack" but using Bazel + Debian
<civodul>(not super exciting, if i may)
<steggy[m]><guerrilla> "Ok, so I've had bluetoothctl..." <- Late but my 'dumb' answer would be to define your own package(or modify the rfkill package) to include chmod'ing after installing, e.g. ```(modify-phases %standard-phases
<steggy[m]> (add-after 'unpack 'chmod-rfkill
<steggy[m]> (lambda _
<steggy[m]> (chmod "/dev/rfkill" #o755))))``` Whether that's a good idea I have no idea, but that's how I'd approach getting it in as part of the config
<mbakke>civodul: those are some impressive sizes :-)
<civodul>mbakke: yeah well ok, but they don't say what it contains
<civodul>we do have impressive closure sizes too (just for the opposite reason)
<civodul>look, we can fit coreutils in 92MiB, which is almost twice the size of "Debian" in their README
<char>What package do I need to install to get
<raghavgururajan>mbakke: Are substitutes for core-updates-frozen served at ci and/or bordeaux?
<mbakke>raghavgururajan: yes, but there was a recent world rebuild, so substitutes may not be available for the latest commits
<mbakke>*may not yet be available
<lilyp>I lol'd at "Distroless images are based on Debian 10"
<dstolfa>distroless is an extremely peculiar term, especially since it begins with a distro.
<lilyp>Imagine we had used that term first. Then we'd have the Distroless System distro
<dstolfa>distroless guix system (managed by guix, duh)
<lilyp>Almost as funny as /homeless-shelter :P
<roptat>char, that would be glibc, probably the 32-btis version?
***lukedashjr is now known as luke-jr
<singpolyma>Hello all! Noobing my way around guix land again, I have a question: is there any way to install a package "globally" instead of to a single user's profile when using guix on debian instead of as the whole system?
<vagrantc>pretty sure the answer is "no"
<vagrantc>well ... i guess you could create /etc/profile.d that sources a specific guix profile amoung all users ...
<singpolyma>Ok. So I just need to guix package -i as each user that wants to run a particular command? I guess that's basically free to do, yeah?
<vagrantc>well, you could maybe work around by having userX also pull in userY's profile, and userY is where you'd install the "global" packages ...
<vagrantc>maybe userY would be "root"
<vagrantc>or a specific profile, rather than a user's default profile
<Hydragyrum>I'd think having a special user for system profiling would be better? that way you don't need to give read access on /root, and no normal user has write access to the profile
<podiki[m]>anyone familiar with cmake and cmake-build-system? I have a package which runs the compiled binary to produce udev rules, trying to write to /etc
<vagrantc>all sorts of ways you could hack around it ...
<podiki[m]>but nothing happens (no error, warning, or files)
<vagrantc>podiki[m]: runs the compiled binary at build time?
<podiki[m]>in the install part of cmake
<podiki[m]>I get the message it outputs in that phase to stdout so I know it tried at least
<vagrantc>podiki[m]: might patch the binary to install somewhere in the profile? or patch out that cmake rule ... ?
<vagrantc>er, not profile ... somewhere in the output
<podiki[m]>I did patch it to output to lib/udev/... but still nothing...
<podiki[m]> the cmake snippet
<podiki[m]>i would have thought guix would complain about that part trying to write to /etc, or automatically wrapped to be within the build dir. not sure what is happening
<podiki[m]>I guess I could do this as a build phase in the package def, but seems silly to rewrite what cmake is (supposed to) be doing
<podiki[m]>is it because cmake is not running an 'install' on this file? is that how it should be done?
<podiki[m]>oh wait, it does. i'm lost then
<podiki[m]>ok, had to make the directory (in package def) since I guess that incantation of cmake install code doesn't
***lukedashjr is now known as luke-jr
<EdLin>is there a way to upgrade your kernel besides guix system reconfigure /etc/config.scm?
<EdLin>it seems to reinstall the whole system rather than upgrade
<EdLin>am I doing it wrong?
<guerrilla>EdLin: That's what I did. If you've done a guix pull, then there will be more than just the kernel to update.
<jackhill>EdLin: yep, I agree with guerrilla, that seems normal. If you wanted to just get at kernel from a different version of Guix, and leave the left of the system alone, there are ways to do that (search for inferiors in the documentation), but that's definitely a more advanced usage
<theruran>has anyone looked at porting GraalVM?
<muradm>civodul: oh great, thanks.. i gets i wasted night of cpu build load then :)
<muradm>sneek: botsnack
<muradm>sneek: later tell cvodul: oh great, thanks.. i gets i wasted night of cpu build load then :)
<muradm>how do you decide it is worth to use new commit to guix by looking at weather and/or
<jackhill>theruran: I haven't. I'm wary the building it from source to be a difficult task, but it would be really neat to have so I'd be happy to be wrong :)
<xd1le>hi guix
***lukedashjr is now known as luke-jr
<civodul>Hello Guix!
<muradm>hello civodul :)
<dhruvin>"guix build guix --with-branch=guix=master --without-tests" should always build right?
<dhruvin>Alternatively, Do we push commits to guix's master branch that may prevent guix from building?
<civodul>dhruvin: hi! commits that break things on master should be very rare
<dhruvin>civodul: thanks
<abrenon>hello guix !
<qzdlns[m]>morning guix
<xd1le>good morning o/
<karmayogi>At present guix generates a docker container image, is it possible it can generate a LXD container image?
<civodul>karmayogi: hi! "guix pack" has several backends so we could imagine implementing an LXD backend
<civodul>however, could it be that LXD understands the Docker/OCI format?
<civodul>it's fairly common
<karmayogi>LXD do not understands Docker/OCI format because it pre-dates Docker. Indeed Docker itself initially used lxc then built their own lib. LXD container acts like a full VM and supports multi-process along with init, in Docker/OCI world multiple process within a container is discouraged.
<karmayogi>One can run Docker container within LXD by nesting, but its not elegant.
<attila_lendvai>if i have a .envrc then emacs hangs whenever i switch buffers. is there a way to speed this up, or turn it off, so that i can initiate it manually?
<attila_lendvai>nm, i have realized that it's cached. i was just modifying the file regularly.
<attila_lendvai>err, well, it's not. i was just switching between buffers both under the same project
*muradm tired compiling stuff... wandering when ci will do rust
<attila_lendvai>oh, that's why i'm having so many local recompiles working off of master?
<nckx>Morning, Guix
<excalamus>nckx, good morning
<attila_lendvai>so, the script of boost prints an error because it uses `which`, which is not recorded as a native-input. but then everything seems to work. is this a but that i should send a patch for, or should i just ignore it?
<maximed>attila_lendvai: Does this cause a build failure of some package?
<maximed>If you mean that "boost" fails to build because it is missing 'which' among its native-inputs, I would recommend adding 'which' to its native-inputs
<maximed>(packages failing to build is a bug)
<attila_lendvai>maximed, i haven't observed any failure besides the printed error
<nckx>No fix needed then.
<attila_lendvai>thanks! i'll drop this patch then...
<roptat>hi guix!
<xd1le>o/ roptat
<raghavgururajan>Hello Guix!
<nckx>Hi raghavgururajan.
<nckx>And roptat.
*muradm frying some eggs on a laptop after 18 hours non stop compiling... :)
<roptat>I'm waiting for the new rust chain, before I start compiling core-updates-frozen again ^^'
<muradm>roptat: how do you check if it is ready?
<roptat>I just wait for the email saying it's merged :p
<muradm>:D i tough waiting for new rust chain to compile on ci :D
<lfam>Does anybody know how to test if a string is a number (integer or with decimals) in Posix shell (ideal) or Bash?
<lfam>Is the only solution a regex?
<lfam>There is integer math built in to `test` but I need to handle decimals
<nckx>lfam: I don't care about POSIX so would pass "${string//./}" to whatever ‘test’ test you're using.
<lfam>I don't need POSIX, so I'm game
<lfam>Can you give an example?
<nckx>Well, for bash, I personally just test whether "${string//[0-9.]/}" is non-empty, because the first solution I found as a child and now it's a habit 😛
<roptat>so 1.2.3 is a number? :)
<muradm>lfam: if that number is very important, once i had to use bc
<lfam>True, 1.2.3 is not technically a number
<nckx>roptat: It's trivial to limit to a single . if you care.
<lfam>Basically I need to distinguish between a software version such as 1.2.3 and a string
<muradm>but it is extra tool, not shell
<lfam>Sorry to be confusing
<lfam>I suppose this use case is pretty weird and wouldn't be accounted for in the standard tools
<lfam>And the right answer is to use getopts but I want to be lazy
<nckx>What's wrong with a regex though?
<nckx>I think that's the clearest unless you're trying to golf the system.
<nckx>Especially if you want to accept negative and .style numbers…
<lfam>Nothing is really wrong with a regex. I just won't be able to remember how it works later
<lfam>But I will use a regex if necessary
<lfam>And I don't need to handle negative or .style
<nckx>I think a regex is 1% more readable than anything avoiding one, but that's certainly personal.
<nckx>What are you making anyway? ☺
<nckx>roptat: I agree that the -security discussion should be brought to -devel (but thanks for erring on the side of caution!).
<roptat>I'll send a message to -devel then :)
*roptat is busy now :)
<lfam>nckx: I'm extending the functionality of the "fetch kernel deblob script" thing to be able to handle the deblob revisions
<lfam>So currently it's like `fetch 5.14.2 5.13.15 5.10.63`
<lfam>And I want it to take an optional argument in $1 that would be the deblob revision
<lfam>I figured that distinguishing between "string" and "numerals with decimals" would do the trick
<lfam>Since these scripts must be passed down to new packagers, I want them to be as simple and unclever as possible
<lfam>I want to avoid the common pitfall of making a shell script that is write-only
<muradm>i run guix environment --ad-hoc dovecot, now dovecot has libexec/dovecot-lda executable
<muradm>how do i refer to it from command line?
<singpolyma>If I'm writing software and I want to work on it with guix and deploy it as a guix package in a custom channel, should I make a manifest.scm or just write a package definition? Is there any way to convert from one to the other? I think guix environment can accept either?
<muradm>GUIX_ENVIRONMENT/libexec ... hmm
<lfam>singpolyma: Manifests and package definitions are different things
<lilyp>singpolyma: packages are for standalone packages, environments for package collections and system for... well, systems
<nckx>$(command -v dovecot)/../../libexec/dovecot-lda 😈
<nckx>I'm honestly not sure whether GUIX_ENVIRONMENT is API.
<singpolyma>Sure, but a project specific manifest just defines the dependencies same as a package definition must, so it's the same data
<lfam>singpolyma: In any case, you'll need to define the package. Whether or not you use a manifest for deployment depends on your use case
<lfam>So, it depends on if it makes sense to model your thing as a package, or if it instead a collection of packages
<lfam>Like, there are "meta-packages", such as the gnome package
<singpolyma>Right, so just define the package and feed that to guix environment when working on it
<lfam>I think that would be what I try first
<lfam>Especially during development
<lfam>I think the ideal solution will depend on the details
<nckx>lfam: I think regexes are the clearest way to ask ‘does x look like a y’. Especially if you put it in a well-named is_deblob_revision function I really don't think it qualifies as esoteric.
<lfam>Thanks for thinking through it for me nckx :)
<nckx>Compared to clever ways to avoid regexes I mean.
<lfam>I just hoped there was something like `test -isnumber` but as roptat pointed out, 1.2.3 is not a number
<singpolyma>It seems kind of like manifest is analogous to Gemfile and package is analogous to gemspec (for a ruby ecosystem example) -- it is common to write a Gemfile that just says "all the dependencies from this gemspec please" I guess I was thinking if some analogous scheme could ingest the package and be a manifest of the dependencies
<nckx>lfam: Your question was interesting because it's not the usual (to me) ‘is this a number *bash* can operate on’.
<nckx>And yet you have no need to operate on it and pull in bc.
<nckx>I'm procrastinating again. o/
<lfam>Really I should just make it do `fetch --revision foo 1.2.3`
<lfam>My laziness is making things harder
<nckx>Bash and DWIM do not tend to mix well.
<nckx>That's not true, they mix dangerously well, only the mixture is often explosive.
<civodul>nckx: $GUIX_ENVIRONMENT is API, documented and all :-)
<nckx>Thanks. Then it's obviously the way to go.
<jackhill>singpolyma: that is clearly posible since `guix environment <package>` instantiates such a profiles, but I'd have to go looking to see how it is surfaced at the scheme level
<nckx>guix system: error: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group
<nckx>Why u no die, bug.
<nckx>(This was during grafting, which tinkles a bell.)
<lfam>I'm never sure why that situation arises
<civodul>nckx: you have --max-jobs > 1, right?
<lfam>What can cause Guix to try to spawn more processes than specified in --max-jobs?
<civodul>lfam: --max-jobs is per-session (so per-client, roughly), so if you have several clients building things, you can run out of build users
<lfam>Yeah, that explains it
<nckx>Yeah, but no concurrent ‘guix’ invocations.
<nckx>So guix is launching subguixes (to graft perhaps)?
<civodul>nckx: hmm no, so i don't know
<civodul>perhaps looking at "sudo guix processes" could give hints
<nckx>It doesn't run long enough or I missed it, but I'll keep doing so.
<nckx>It's not a serious problem for me, I just thought this had been fixed.
<nckx>No biggie.
<podiki[m]>hi guix
<podiki[m]>can anyone help with writing a shepherd (user) service? I have the basics, but trying to get the command it is running to redirect output to logger
<podiki[m]>I don't think shepherd likes the long command with redirection (which would work in a shell), but I'm not finding the docs on log-file options
<nckx>If you want to write shell script code, you need to launch a shell (untested): #~(make-forkexec-constructor (list #$(file-append bash "/bin/bash") "-c" "blah blah > foo foo"))
<nckx>But if all you need the bash syntax for is to redirect output, make-forkexec-constructor has a #:log-file keyword specifically for that.
<podiki[m]>I was looking for docs on that, will it just be doing that same redirect, so I can give log-file "logger --tag" etc.?
<podiki[m]>no, then it takes that as a file I must need to do something else
<nckx>You mean pipe (|)? No, it won't do that. Use bash for that.
<nckx>Or deal with Guile's baroque procedures to set up pipes.
<nckx>I recommend launching bash.
<podiki[m]>okay, thanks. so right now log-file will only redirect to an actual filename
<podiki[m]>thanks, will do
<nckx>‘right now’ - it always will.
<podiki[m]>my goal btw is to get some user services and have the output to syslog so I can see it all together
<podiki[m]>or is there a way to have sheherd output all go somewhere? can I just start shepherd with its output piped to logger?
<nckx>Yeah, logging in Shepherd is… primitive at the moment :)
<nckx>I've never tried that podiki[m].
<podiki[m]>I shall investigate
<nckx>Some daemons provide their own --log-to-syslog switch, which Guix then uses. I've never heard of darkman but check its --help just in case.
<podiki[m]>do we have any packages that provide sherherd service files for a user to run with shepherd? (as opposed to a full system service)
<podiki[m]>I feel like that would fit as a nice replacement for systemd user services
<dstolfa>i thought that's what guix home gave us?
<nckx>I haven't tried guix home yet, but unless that's what it provides: no.
<nckx>Ah, dstolfa knows more.
<dstolfa>do i? i'm just guessing here
<dstolfa>but my understanding was that it allowed for user shepherd
<nckx>Makes 2 of us.
<lilyp>Guix home allows users to specify some shepherd services and probably has some definitions out of the box
<lilyp>As for packages that ship them by themselves... shepherd isn't that mainstream yet
<nckx>dstolfa: User shepherd has always works, guix home just manages it for you. Just don't ask me how.
<podiki[m]>I was thinking to provide the sherherd service through the package definition, at least until such a thing would make sense to submit upstream
<dstolfa>nckx: yeah, poorly phrased by my part
<nckx>Oh, I didn't mean it as criticism.
<podiki[m]>a space to watch
<nckx>Shepherd user services were always a thing but not well-known at all. If guix home changes that it's already won.
<podiki[m]>I'm not a heavy system user service person, but is nice for a few background stuff where I want to be able to stop/restart/see logs
<podiki[m]>and writing in guile over systemd configs is a win to me too
<podiki[m]>everything guile
<nckx>So systemd does run everything through a shell? (Based on what I guess is your initial port of your systemd service above :)
<podiki[m]>I'm not sure the internals, but it hooks into journalctl
<podiki[m]>so all the output is available there, labeled by unit
<nckx>…which I, in turn, don't know much about. :)
<podiki[m]>if I remember, the systemd exec would just be "darkman" in this case, with all output captured by journalctl
<podiki[m]>what I found nice is that it is central and has builtin tools to get messages just from a service, from last boot, a time frame
<nckx>Shepherd definitely doesn't have that [yet].
<nckx>Frustratingly so, but I'm sure it will happen some day.
<podiki[m]>perhaps it would make sense to have a separate (guile) logging tool?
<podiki[m]>(I have no idea how tightly wound journalctl and systemd are)
<dstolfa>there are lots of things that could be improved upon in shepherd, but it is a very easy codebase to modify in a way... i keep trying to, but i keep getting this weird error code every time i open shepherd's code: ENOTIME
<nckx>Quite, from my limited understanding.
<nckx>podiki[m]: ☝
<nckx>But in the same way that Guix and Shepherd are tightly wound. It's not a value judgment.
*nckx feels need to distance self from vocal… people :/
<podiki[m]>side question, what is the preferred hashbang in guix?
<podiki[m]>(for sh, or anything)
<lilyp>just use whatever you'd have on traditional distros and let guix patch it
<podiki[m]>and for writing a script on a guix system (not in a package)?
<nckx>If you mean for personal (e.g. ~/.local/bin) scripts: #!/usr/bin/env sh works on stock Guix Systems.
<nckx>So does #!/bin/sh, but that's less supported on other distributions.
<podiki[m]>thank you both
<maximed>To test a patched daemon: "sudo herd stop guix-daemon && sudo ./pre-inst-env guix-daemon --build-users-group guixbuild"?
<maximed>Anything special I should be aware of that could store corruption?
<maximed>(Assuming the patches are safe)
<nckx>Make sure you've configured with --localstatedir=/var.
<maximed>It works!
<nckx>It should be a rather routine thing, BTW. It shouldn't be or feel risky or unsupported. If anything fails that doesn't otherwise, it's a valid bug!
<maximed>Does someone know a command-line tool like the "time" shell built-in, automatically repeating the command a few times to compute the average and stddev?
<maximed>found one: ‘hyperfine’
<dstolfa>yeah, hyperfine is a pretty good one
<nckx>Thanks for the TIL.
*apteryx puzzled why 'guix refresh -u mailutils' can't fetch the key while 'gpg --receive-keys 325F650C4C2B6AD58807327A3602B07F55D0C732' works fine.
<maximed>Can running "./pre-inst-env guix daemon ..." while there's still a guix-daemon unning cause problems?
<maximed>Or starting "sudo herd start guix-daemon" while ./pre-inst-env guix daemon is still running?
<maximed>(I didn't do that, but somehow guix-daemon appeared in htop even though I killed the ./pre-inst-env guix-daemon)
<nckx>It shouldn't start.
<maximed>(And the substitute urls are different)
<nckx>Oh, it does, nvm.
<nckx>I thought it would choke on the socket in use?
<maximed>Can I kill them? (sudo kill PID)
<maximed>I presume yes, since pulling the power cord didn't cause problems in the past
<nckx>Sending TERM should be OK.
<nckx>Note that the Shepherd will try to respawn its instance.
<maximed>I ran "sudo herd stop guix-daemon" and "sudo herd disable guix-daemon" before "./pre-inst-env guix-daemon"
<maximed>... maybe interrupting "./pre-inst-env guix-daemon" didn't kill the guix-daemon?
<nckx>Who can say.
<nckx>(It cleans up nicely here, is all that I can.)
<lfam>apteryx: It's probably because %openpgp-key-server points to the defunct SKS network
<lfam>There isn't a meaningful keyserver network anymore so we should use either Ubuntu's keyserver or
<apteryx>yeah, I had already tried: guix refresh --key-server= -u mailutils with the same result
<apteryx>something's fishy
<lfam>I don't think it uses HTTPS
<lfam>I would try that
<apteryx>that worked!
<nckx>Did you get that https:// from anywhere in Guix?
<attila_lendvai>so, i have two innocent looking commits on top of current master. a guix build some-package seems to be rebuilding the world. is that expected? if so, then is there a way to avoid this? e.g. base it off of another branch?
<maximed>attila_lendvai: What files did the commit change?
<maximed>* commit -> two commits
<lfam>Rather than files, what code was changed
<attila_lendvai>maximed, one of them is the wrap-script-or-program that you proposed, and the other one is (guix/build/utils.scm)
<maximed>then it's expected
<maximed>guix/build/utils.scm is used (indirectly) by almost every package
<maximed>via gnu-build-system
<maximed>changing wrap-program->wrap-script in python-build-system rebuilds every python package and their dependencies
<attila_lendvai>and the other one changes wrap-script. so, this is my fate then... :) i wonder how long it will run on a 4 core laptop
<lfam>It will probably take a few days
<lfam>Although it depends what packages you want to build
<attila_lendvai>lfam, i'm building serf because this was the first point where my change broke (use wrap-script where possible and fall back to wrap-program in python-build). that's why i applied the other fix to wrap-script, hoping that it'll fix it, and this led to the long rebuild.
<lfam>If your package depends on rust it will probably take a couple weeks to build through the rust bootstrap
<attila_lendvai>and i thought i'll quickly give it a try... :D
<lfam>It's probably worth renting a powerful server for this
<lfam>Or finding a way to avoid rebuilding everything while testing your change
<lfam>You could make a copy of the functions you are changing and put them somewhere besides (guix build utils) and test them from there
<lfam>For Python-only dependency graphs, the full rebuild time will not be too bad, maybe a day
<lfam>It depends on what 4 cores you have
<attila_lendvai>i'll just resort to patching the package instead of doing the right thing. i'm too new to all this for navigating through a change with such a big effect...
<lfam>Yeah, changes like these have to go through the core-updates cycle
<attila_lendvai>or wait until reaches master
<OJ[m]>I've been looking at package-input-rewriting for most of today, so I could replace jack-1 with jack-2 in packages and I haven't been able to figure out how. I'd like it if it worked automatically for every package that I have installed and has jack-1.
<nckx>Fixes CVE-2021-33285, CVE-2021-35269, CVE-2021-35268, CVE-2021-33289, CVE-2021-33286, CVE-2021-35266, CVE-2021-33287, CVE-2021-35267, CVE-2021-39251, CVE-2021-39252, CVE-2021-39253, CVE-2021-39254, CVE-2021-39255, CVE-2021-39256, CVE-2021-39257, CVE-2021-39258, CVE-2021-39259, CVE-2021-39260, CVE-2021-39261, CVE-2021-39262, CVE-2021-39263
<nckx>…OK. Thanks!
*nckx leaving, but maybe you can share the closest you think you got, and the errors (if any), OJ[m].
<OJ[m]>Well, really, the closest I got is using --with-inputs for an environment, but that's not what I want. :p
<OJ[m]>Then again I put a file in GUIX_PACKAGE_PATH hoping it overrides a couple things.
<OJ[m]>Somebody can probably tell me how dumb this is.
<lfam>nckx: And that's only the 2021.8.22 release! Maybe intermediate releases fix some other CVEs too
<attila_lendvai>wrap-script identifies guile by a keyword arg defaulting to (which "guile"), i.e. scanning the current $PATH. this is not smart... and unsurprisingly it fails in my --pure build env.
<attila_lendvai>any hints on how else to get a path to the guile binary?
<nckx>Yes, packages using wrap-script are expected to include guile(@3) in their inputs.
*attila_lendvai tries
<nckx>Doing anything else (🌈 magical 🌈) sounds like opening a family pack of wyrms, but I don't know if that's been explicitly discussed.
<nckx>(Yes, wrap-program is magical already.)
<attila_lendvai>nckx, guile.scm contains countless package definitions. which one? there's no 'guile' in there.
*nckx eyes $partners NTFS thumbdrives with new-kindled fear; upgrades.
<apteryx>Why does 'guix environment -C' leaves /bin/sh? should we fix this?
*attila_lendvai is grateful for all the help, but gives up for today... o/
<apteryx>that's a constant thing to remember to do when troubleshooting build discrepancies between the build environment and that created by guix environment -C: rm /bin/sh
<iskarian>apteryx, a comment in the source states: "Containers need a Bourne shell at /bin/sh"
<iskarian>No explanation, though
<civodul>apteryx, iskarian: it's mostly out of convenience: since "guix environment" spawns a shell, it needs to have one
<civodul>or you mean it could have one but not link it to /bin/sh?
<lfam>nckx: Can you check that you can still access those NTFS filesystems with the update
<apteryx>civodul: right; I think it'd be nice if 'guix environment -C' was a look-alike as the build environment of the guix-daemon as possible
<apteryx>/bin/sh seems the glarring exception so far
<apteryx>it'd be ok if 'sh' was in PATH of the container, without having to appear at /bin/sh
<apteryx>emacs doesn't seem to make use of its mailutils source
<apteryx>*** Mailutils movemail will now be used if found at runtime.
<apteryx>it'd add 20 something MiB to the closure. Perhaps wiser to remove it, leaving the Gnus users of such feature to install it themselves?
<apteryx>but since that was added for security (Emacs has an internal movemail implementation which doesn't support secure POP), it's perhaps wiser to patch movemail
<apteryx>nckx: does the gpm input really does something for Emacs? it doesn't seem to be recorded as a reference according to 'guix gc -R (guix build emacs)'
<civodul>maximed: i keep getting distracted (in a good way) by the patches and ideas you send :-)
<civodul>the other day it was source location, this time it's base32
<nckx>apteryx: It adds gpm support? But you knew that much since you git blamed me, so I'm confused 😛
<nckx>It's still working fine here, although I'm a few weeks or so behind master.
<nckx>Is it not finding gpm?