***langdon_ is now known as langdon
***jonsger1 is now known as jonsger
<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. <nixo_>Hi, I'm having probems with gui on GuixSD <nixo_>guix gc gives: guix gc: error: build failed: executing SQLite statement: FOREIGN KEY constraint failed <nixo_>guix version is guix (GNU Guix) 2faf2edf5880a47d70b716b1780465eb1671c855 <civodul>nixo_: i think you're using the --verbose option, but probably you shouldn't <nixo_>building XXX.drv...; building of XXX.drv failed; view build log at ... <nixo_>civodul: just this, so debugging is difficult <g_bor>civodul: I've noticed an inconsistency in guix gc output. <g_bor>most probably it's because some message parts originate from the daemon, while some is produced in the script. ***sturm is now known as Guest6324
<civodul>g_bor: possible; which inconsistency do you have in mind? <nixo_>civodul: without the verbosity parameter I just get: building of XXX.drv...; building of XXX.drv failed; view build log at XXX.drv.bz2 <civodul>nixo_: could you paste the complete output of the 'guix build hello' command? <Jackneill>what are the talks/blog posts etc that you recommend? for just user and also a dev who wants to understand the whole concept/working? <hulten> I have an old GuixSD 0.14.0 installation, which I'm trying to upgrade. I did a guix pull, which worked. <hulten>Then with «guix system reconfigure» it tells me: «guix: system: command not found». <hulten>Does someone know how I can fix this (use the «guix system» command)? <civodul>hulten: could it be that you're upgrading from an old Guix? <hulten>Yes, I am doing that. Is that a problem? <hulten>What would be the best approach here? <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? <hulten>Maybe I should reinstall (i.e., install GuixSD 0.15.0). I could just save my config.scm and «guix package -I» from the different users to reproduce the installation, right? <civodul>hulten: what does "guile -c '(use-modules (guix scripts system))'" say? <g_bor>civodul: The thousands separator appears in the guix gc output, where freed space is reported, but does not appear where the text hard linking saves ... MB <roptat>hulten: most likely ~/.config/guix/current/bin is not in your path <civodul>g_bor: oh right, that's because the text written by the daemon is not i18n'd <roptat>or maybe you need to run guix pull once more (I remember that was needed for a transition) <roptat>hulten: if it exists, you should add ~/.config/guix/current/bin at the beginning of your PATH <hulten>roptat: I've done that, now "guix system" does something. <hulten>Thanks roptat and civodul for the help! <civodul>if ~/.config/guix/current is available, you're safe now (as in: you completed the 'guix pull' transition) <hulten>One question: why is it that *system* is not found according to guix. <civodul>probably due to a missing dependency, which caused the (guix scripts system) to fail to load <hulten>I see, I'm not thinking really "lisp/guix" yet... <civodul>using the command line shouldn't require you to be "thinking lisp" :-) <civodul>so it's really that this transition wasn't smooth at all <hulten>It's normal with alfa/beta software that this happens between releases. <civodul>the bright side is that such bugs shouldn't happen with the new 'guix pull' <hulten>But possibly it will be smoother from 0.15 to 0.16 or 1.0, as Ludo' mentioned that "we are close to 1.0" (or something along those lines). <hulten>And uhm.. whatever difficulties during an upgrade path, like mine here, the end result should be identical to that of a clean install, right? <hulten>I understand that that's the whole idea of a functional package manager, including the whole GuixSD system. <roptat>hulten: once you reconfigure and reboot, yes <roptat>also, if you're on guixsd, you should remove the guix package from your profile to make sure you don't use an outdated version <ng0>hulten: we have been close to 1.0 for about a year :) but now closer than 1 year ago <hulten>In the end it is mostly a number. Since roptat mentioned that upgrade issues like this should not happen from 0.15.0, this is at least one huge requirement met for a 1.0 release. <hulten>(Well, for GuixSD this is a requirement; I don't think it works like that for non-functional/transactional systems.) <hulten>roptat: Does that mean that if "guix package -I | grep guix" does not give any output, for any user, I'm fine? <g_bor>do you think it is allowable to disable doc generation for icedtea-6? <pkill9>g_bor: you could put it into a different output <pkill9>that's what some other packages do with large docs <g_bor>pkill9: the problem is that the documentation is not reproducible. <g_bor>And there is no easy way to make it so. But icedtea-6 is only used used in the bootstrap. <pkill9>so are binaries allowed when bootstrapping compilers? <pkill9>(that might not be worded correctly) <pkill9>aka are binary versions of compilers allowed to be used to build themselves <g_bor>pkill9: icedtea-6 is completely bootsrapped from source, if that is what you mean. <g_bor>pkill9: we are trying to avoid that situation in guix, some compilers are not easily bootstrappable though. <g_bor>It would be nice and useful work to collect the list of compliers that needs bootstrapping, create relevant bug reports and reach out to the communities. <g_bor>Also there are some wip in this area. <g_bor>roptat is working on scala, dannym on rust. <pkill9>i want to be able to bootstrap the blitzmax compiler to package gridwars <g_bor>pkill9: seems to be non-tirvial, but tractable. <roptat>I also had a look at coffeescript and a colleague is working on OCaml <roptat>I don't think I'll be working on coffeescript though, I already have a lot of projects <civodul>roptat: really cool that you managed to get your colleague to work on OCaml bootstrapping :-) <g_bor>roptat: I am now getting into this icedtea doc reproducibility stuff. <g_bor>it seems that we will have to patch the build system somewhere... <g_bor>I've also found some relevant environment variables. <roptat>civodul: what's the reproducible build summit exactly? <civodul>roptat: it's a gathering of people from projects with an interest in reproducible builds <civodul>there are many Debian developers, and then typically a few people of each of the other projects <civodul>i think there are reports of previous meetings on the web site <civodul>you coming to one of these events? :-) <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 guix-help@gnu.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 :) <nixo_>lfam: cool, so be prepared :D <nixo_>however I want to note that one of the best thing of guix vs nix is the emacs-guix package :) <nly>Do channels support hash verification? <nly>emacs-guix is awesome! nixo_ <lfam>nly: What do you mean by hash verification? <nly>I'm sorry if I am asking a naive Q I just found out about channels <nly>What I meant is a verification for the url in some from <nly>Like how would I know if the source changed <nckx>civodul: guix-hpc.bordeaux.inria.fr's certbot or Web server needs a kicking. <nly>For example if I am pulling from a specific commit(not a branch) <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 <help-guix@gnu.org> <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>Recommendations for porting that to Guix? <lfam>Nix does this: KERNELDIR = "${kernel.dev}/lib/modules/${kernel.modDirVersion}/build" <lfam>I guess that should work <nckx>lfam: So it wants to read something form the build-time kernel's module directory? Isn't that a bad sign? ***Guest65532 is now known as benny
<civodul>nckx: thanks for the heads-up, fixed! apparently nginx did not get restarted <lfam>nckx: Not sure... you tell me :) <lfam>Neither my Debian kernel nor the linux-libre kernel have the directory <nckx>lfam: No clue. I'm planning to Wireguard myself up the wazoo once I get a proper LAN set up in the new 'partment, but until then I'm a total noob about it. <lfam>I figured I could make the package, then other people might be inspired to make a service for it <nckx>Just seems like something that will either break if it's actually used on a different running kernel, or superfluous otherwise. *nckx kind of buried the lede here: thanks for working on Wireguard, lfam ;-) <lfam>Right... I wonder if we misunderstand it. Being tied to the kernel it was built on would be a major "impedance mismatch" with how GNU/Linux distros work <nckx>civodul: Thanks! Wasn't sure if you ran the thing. *nckx takes a look at the Makefile. <nckx>Oh, so main.c is an out-of-tree module. <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. <nckx>lfam: Thanks for taking a look anyway. <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 whispers 'Speck' and runs away. <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 <bavier>nixd: the 'guix build' output would be fine if it includes the output from cmake <nixd>bavier it includes some of the cmake output, yes, give me a second <bavier>nixd: you can also check in the build directory (if you used '-K' to guix build), and look for a CMakeError.txt file <nixd>bavier Looked at that, but there is not CMakeError file, just CMakeOutput <bavier>nixd: check the quoting on the native-inputs field, you need a '`' rather than a '\'' <bavier>nixd: with that the build will proceed, but there appears to be other issues to resolve <bavier>oh, the the tarball doesn't contain source for some git submodules... :/ <bavier>you might need to use a git checkout with 'recursive #t' <nixd>bavier I will try. Is there a reason why " works for the inputs field, but not for native-inputs? Do you think I should try to use the git repo directly? <bavier>nixd: want I meant is you need a quasiquote rather than a single-quote so that the unquoting works properly <nixd>bavier, ahh I understand, got it further now. Thanks for you help, I'll now try using the git repo as a source <efraim>gah, have to patch python[2]-more-itertools on core-updates <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/... <nixd>after using guix build -K. Any ideas? <nixd>I mean is it possible to fetch all of the submodules of a repo with the repo you're trying to fetch? ***rekado_ is now known as rekado
<rekado>nixd: have you tried what bavier suggested? Adding “recursive #t” should be enough. <nixd>rekado cmake still throws the same error, and the submodule's directory is still empty, I'm not sure what I'm doing wrong here <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 <lfam>For example, `guix pull` <lfam>With luck, one would get substitutes, but that's not certain. In 2018, I would always choose armv8 over armv7 <kmicu>Ah, compilation times. So CPU slowness in general, not anything related to Guix. <lfam>Right, but Guix / Guile are not exactly the fastest softwares in the world... yet :)