<kristofer>ok, I have determined that exim identifies the path to the binary in the store. when exim makes a local_delivery it spawns a new process as said local user and delivers mail to the relevant mbox. I have cons'd exim to %setuid-programs, however I am unsure how all that functions. The store doesn't contain the setuid/gid bits, but they are on the symlink in /run/setuid-programs. does the subprocess need to use the symlink from
<kristofer>/run/setuid-programs/ instead of the store in order run as a local user?
<g_bor>I've noticed a slight inconsistecy in guix gc output. In the last lines of output, there is a hardlinking saves number without thousands separator, while in the final line the freed space is reported with a thousands separator.
<civodul>in 0.15.0 'guix pull' was overhauled, fixing this kind of problem that you're experiencing
<civodul>but if you're upgrading from pre-0.15.0, there are a few bumps on the road
<civodul>most likely you need to "guix package -i guile-sqlite3"
<hulten>civodul: done that, I still get «guix: system: command not found».
<hulten>Also did a guix package -u before the guix system command.
<nixo_>civodul: solved! and I also wrote my first package, I'll open the PR this evening to have it in the repository (it's enchive, https://github.com/skeeto/enchive, that I used a lot on NixOS). Where do I open PRs?
<kristofer>Hello! Anyone have a functioning exim setup? I have been troubleshooting my setup and I believe it's something to do with setuid-programs. When exim processes a local_delivery it fails to setuid() to my user. It keeps the mail in the retry phase.
<kristofer>I have this in my operating-system: (setuid-programs (cons #~(string-append #$exim "/bin/exim") %setuid-programs))
<roptat>kristofer: I don't think that changes anything for the service itself
<roptat>setuid-programs only copies the program to another location and add the setuid bit. It doesn't change anything in the store, and the service always looks for exim in the store
<roptat>I don't use exim, so I can't help much more than that, sorry :/
<kristofer>yeah the binary has the path hardcoded and the store doesn't contain the setuid bit
<roptat>kristofer: if you don't get an answer here, you can try asking on firstname.lastname@example.org
<nixo_>why aren't melpa packages included by default?
<nixo_>Is it fine to open PR to merge the one I use?
<lfam>nixo_: We always welcome new packages of free software :)
<lfam>nly: I haven't played with channels yet, but I think the answer is no, there is no verification of channel sources like there is with package sources. But it's worth a message to <email@example.com>
<lfam>nly: In many cases, I'd expect channels to pull from a Git branch, which can't really be known in advance by the pulling client
<lfam>The WireGuard Makefile uses a variable like this: KERNELDIR ?= /lib/modules/$(shell uname -r)/build
<lfam>Hm... maybe we should wait for it to be mainlined
<nckx>Rather than building as an external module, if you would like to build WireGuard as a module or as built-in, directly from within the kernel tree, you may use the create-patch.sh script which creates a patch for adding WireGuard directly to the tree.
<nckx>i.e. We could patch our kernel or at least provide a patched one. But that seems extreme.
<lfam>Interesting line from a recent LWN article on the topic: "Miller confirmed that assessment and clarified that even though he is listed as one of the two crypto maintainers, he would be looking for an ack from the other maintainer, Herbert Xu, as "I haven't done a serious review of crypto code in ages"."
<lfam>So, there is only one person maintaining the Linux crypto API
<nckx>Linux crypto is... in a weird state right now.
<nixd>Trying to build a custom package using the cmake build system, but I get an error saying that cmake could not find PkgConfig. I do specify to use the pkg-config package in the package definition and have installed pkg-config on my system, just in case. Anyone got ideas? Am I missing something simple?
<bavier>nixd: what you have installed in your profile is not visible to packages when building; you'll want to declare pkg-config as an input to the package
<bavier>nixd: is there any hint from cmake? what did it do before deciding pkg-config could not be found?
<nixd>bavier, I knew that, but I tried nontheless, didn't have any impact. I do not have pkg-config as an input though, I just have it in the #:use-module part. From my understanding the inputs are just the dependecies of the program Im trying to build and not compiler tools, or am I wrong?
<bavier>nixd: cmake-build-system will take care of compilers, but you'll want to put pkg-config in the native-inputs field
<nixd>bavier cmake just says it detects a working compiler (g++ in my case) and throws the error after saying it uses a supported compiler.
<bavier>nixd: would you mind pasting your package and the error output? paste.debian.net works well
<efraim>I guess I can wrap it so it only affects the 32-bit architectures
<nixd>How do I use git-fetch recursively? I have a problem fetching a git repo which has a few parts that are empty in the guix build -K leftovers, but there should be files as there are some in the repo. The repo I want to fetch is https://github.com/jaagr/polybar which has /lib/xpp, but this directory is empty in the guix build source tree in /tmp/...
<janneke>okay, /me finally built also tcc-boot0 using the new %bootstrap-mes package
<janneke>now only rewriting mescc-tools-boot and we can get rid of %mescc-tools-see, %mes-seed, and %tinycc-seed -- i hope
<rekado>nixd: can you also show us the current package definition?
<rekado>nixd: also, maybe it’s better to build the libraries as separate packages
<nixd>rekado, sure http://paste.debian.net/hidden/4c2211d0. I thought about packaging xpp seperately aswell, but I wasn't sure if I could make it work as it looks like cmake expects xpp to be in a specific directory in the main source tree to me
<pkill9>out of interest has anyone run guix on raspberry pi?
<vagrantc>haven't tried on rpi specifically, a couple similar class machines
<mekeor>pkill9: i did not try guix on raspberry pi.
<mekeor>pkill9: but: “GuixSD can be used on an i686, x86_64 and armv7 machines. It is also possible to use Guix on top of an already installed GNU/Linux system, including on mips64el and aarch64.”
<mekeor>pkill9: raspberry pi version 2 model b runs on ARMv7 architecture. raspberry pi versions 2 model b v1.2; and version 3 model b; and version 3 model b+ run aarch64.
<lfam>Guix on armv7, especially the Pi machines, will be kinda slow, because those machines are generally just really slow. It does work, however. armv8 (aarch64) is much better, and equally cheap and available
<kmicu>lfam: what do you have in mind when you say that Guix will be slow on armv7?
<lfam>kmicu: I'd expect any compilation to take a loooooong time