***nand1_ is now known as nand1
<marusich>In the build.cc file, we #define pivot_root. Looks like it expands to SYS_pivot_root. I see in the linux-libre source there are places that mention "sys_pivot_root", but not "SYS_pivot_root". <marusich>I've looked in a couple places, and I can't figure it out. What is SYS_pivot_root referring to? <civodul>SYS_pivot_root is the syscall number for 'pivot_root' <marusich>I found the answer in glibc-2.25/sysdeps/unix/sysv/linux/sys/syscall.h <marusich>They generate these at build time I guess <marusich>Fun fact: I don't know why, but pivot_root succeeds when I launch my docker container with --privileged, but it fails when I launch it with --cap-add=ALL <marusich>I thought all capabilities would have been enough; I guess I was wrong... <marusich>At least this is just something that happens because I'm running guix-daemon. Other GuixSD Docker imgages, which don't run builds using Guix, shouldn't require such extensive permissions. <marusich>I wonder what the difference between --cap-add=ALL and --privileged is? <marusich>I think I'm just gonna roll with --privileged for now and see if that will be good enough for doing the things I need on a Mac. <marusich>Since the question of what privileges must be given to a Docker container in order to run a specific service inside it depends on what the service does, it's orthogonal to the creation of GuixSD docker images, so I'll see if I can polish up my patch I sent long ago for that. <mbakke>Oops, apparently core-updates broke offloading. <mbakke>Installing guile-readline fixes it. <ng0>mcomix broke on the commit where core-updates was merged <efraim>it turns out modules/glibc was causing all the test failures for me in clisp <ng0>merged HEAD now it seems like I can continue updating <rekado>I just tried to build java-testng and got a test failure. <rekado>I previously built it on a different machine and succeeded. <efraim>It looks like the .dtb file for arm boards is supposed to be at /boot/$board.dtb <rekado>“guix pull” fails to build Guix :( <rekado>trying to build the same derivation again to get a look at the test log <rekado>but there hasn’t been a new release since. <rekado>so I’d expect to be able to git pull from there. <rekado>this is the “base” Guix on the cluster. <roptat>rekado: re java-testng, I remember the tests failing non deterministically <efraim>talking to myself from ~2 hours ago, it looks like u-boot is compiled with the dtb file compiled into it, so u-boot would need to be modified (again) to save the dtb file <efraim>so i'd get a special-files-service for the dtb, and a super-duper-special-file service for the text file for boot.ini or whatever <rekado>civodul: great! There’s one typo: “now’s is” –> “now is” or “now’s” ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | Outreachy+GSoC: https://gnu.org/s/guix/blog/2018/join-gnu-guix-outreachy-gsoc/ | videos: https://gnu.org/s/guix/blog/tags/talks/ | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://hpc.guixsd.org'
<roptat>has there been some work on making it possible to translate the manual? <roptat>I saw some discussions for the website too, is it implemented? <rekado>roptat: no, the discussions were only about the website. <rekado>I don’t know what the best way is to translate the manual. <roptat>I know po4a has texinfo support, so maybe that's how we are supposed to do it <efraim>Do they have any documentation? Its on my list to fix for aarch64 <rekado>I wonder why we have no substitutes for sbcl <efraim>I pushed a fix to clisp a few hours ago <civodul>roptat: like we said at FOSDEM, if you know of tools that would make it easy to maintain translations of the manual, that'd be great! <civodul>i don't know po4a but if it does the job, that's great <efraim>Do we have a package for virtaal or was it jsut a patch so far? <roptat>civodul: po4a is what we use to translate LFS <rekado>I’m trying to run Guix software on a system with Linux 3.10. <rekado>and it aborts with FATAL: kernel too old. <rekado>if I cannot use any of the Guix applications on the old CentOS cluster any more that’s really bad. <rekado>erm, sorry, it’s linux 2.6.32 on the cluster <rekado>nixos has a glibc patch for CentOS kernels <efraim>3.2 is the new minimum for x86_64, it's been higher than 2.6.x on arm since 2.22? <rekado>right, but the CentOS kernel is heavily patched and actually does work with glibc 2.26 <rekado>glibc just refuses to work because it only checks the version number. <rekado>I now have the problem that none of the newly installed software runs on the cluster here. <rekado>I’m tempted to just graft glibc on the cluster installation to fix this asap <rekado>ACTION just applied a glibc graft commit to my clone <apteryx_>Would someone have a recommended tool to inspect large diffs? I usually use magit, but it gets a bit unwieldy for really large diffs. <rekado>Emacs with diff-mode works fine too. <apteryx_>I need the ability to skip entire directories so I'm thinking I'll have more luck with a "graphical" diff tool, as these often seem to come with that. <apteryx_>thanks for the suggestions, I'll try them as well! <civodul>rekado: terrible indeed, though 2.6 is really old <groffer>apteryx_: I find meld to be a very nice (GUI) difftool <rekado>civodul: I’ve just fixed it locally with a glibc graft. <apteryx_>groffer: thanks! It's not packaged in Guix yet it seems. <rekado>CentOS 6.x is supported until 2020 :( <rekado>it will keep using an increasingly patched 2.6.x until then I assume. <groffer>apteryx_, ah yes, that's right, sorry <efraim>is there a way to use binfmt with guix on a foreign distro? <groffer>Is there a way to predict how much space will required in TMPDIR for building? I ran out with 3.9GiB when trying to install cargo (apparently no substitutions are available (yet?)), now I hope 95GiB will be enough ;) <civodul>i *think* the cluster at work is at 3.10 <quiliro>i was wondering why, if I have: guix gc, then guix package -u <quiliro>the question is why i have to download the packages again if i have guix gc <civodul>presumably because 'guix gc' removed some of the things 'guix package -u' needs <civodul>'guix gc' collects garbage, i.e., things that are not needed at a given point in time <civodul>if they become necessary the next moment, that's too bad for you <quiliro>why wouldn't i need guix package -u ? <groffer>If I get "Connection refused" with "guix package -i ..." while another guix build command is running does that mean that all the builders are busy? <pkill9>quiliro: it doesn't remove 'guix package -u', it removes stuff that is needed by any software that 'guix package -u' finds new versions of <pkill9>well, stuff that is needed by newer version of software, which no isntalled software needed when you ran 'guix gc' <quiliro>ok, pkill9 ...but i have not updated the list of packages (no guix pull) <pkill9>i find that for example, 'guix gc' will remove build software such as gcc and make from the store, because I don't have it installed to any profile or have them registered with the garbage collector, so when i next build something it needs to redownload them <groffer>quiliro, I have only *very* limited understanding, but I think stuff gets deleted by guix gc when it's not referenced by any used profile, i.e. also things that are only build dependencies but are not needed once something is installed. Then when you do guix package -u some of it might be needed again and thus re-downloaded <pkill9>also i have only limited understandign so can't give you definitive answer <groffer>It also bothered me a lot in the beginning, as it seems very counter-intuitive, but now I just use a ~9GiB partition for /gnu and haven't needed run guix gc during the last few weeks :) (I use guix on a foreign distro and have only limited amount of packages installed, YMMV) <quiliro>so i can guix gc and operate correctly....but i have to re-download if i need something as a compilation library which is not necesary for the installed packages but it is for the packages i will install? <quiliro>i think i should have an offload machine <mbakke>I tend to use e.g. `guix gc -C 5G` so as to not remove absolutely everything. <roptat>how does the %D% or %C% pattern work in Makefiles? It's kinda difficult to find info on search engines ^^' <civodul>specifically: info "(automake) Include" <ng0>hm.. so if letencrypt needs(?) files owned by root, and prosody requires them to be read by prosody only *and* prosodyctl cert import can't find the certnames in the /etc/lets.../live/name-different.. folder, how is one supposed to make prosody with tls work in GuixSD? I mean I have my own CA in an old repo, but LE would be better. One idea I have is copy the files around and chmod <quiliro>The following packages will be upgraded: <quiliro>so it downloaded a bunch of packages to do nothing <quiliro>am i correct in this or the bug is in my understanding? <OriansJ>quiliro: It does appear to be a bug. <ng0>wrt prosody, I think I'll pick the not so elegant solution by sync-copying to a folder <roptat>so I'm able to generate a translate .texi file, but then I don't know how to have the info page built <roptat>I can't put it in info_TEXINFOS because this texi file is not a source file <roptat>I get this when I try to do that: automake-1.15: error: cannot open < ./doc/guix.fr.texi: No such file or directory <civodul>roptat: well that file doesn't exist, right? :-) <roptat>no, but I have a makefile rule to generate it <roptat>oh and how is version.texi built exactly? <snape>ng0: yes, there will be deploy hooks for this <mbakke>lfam: Regarding Qemu upgrade, let's just give GRUB a private 2.10 for the time being. <snape>ng0: it's probably the cleanest solution. Next step is to define an ad-hoc deploy-hook within each service <snape>and to get then to extend the certbot service <ng0>I saw we have no OpenLDAP service.. does anyone have one in their private repo? <snape>I still haven't found a solution to the question regarding certbot-activation. I wish I could find one before I push my patches, but it's probably better to push anyway <roptat>I'll send a patch and see what you think about it <ng0>yay me for throwing away the prosody and bitlbee config I had back then.. one of the only configs that ever disappeared.. LE seems a bit more difficult than my own CA right now wrt xmpp. <ng0>well, integration is good <snape>what does "wrt", and "yay me" means? Please forgive my bad English :-) <snape>Does anyone know if there is a way for a service to make a command available to the user? <civodul>snape: yes, via profile-service-type <civodul>that adds a package to /run/current-system/profile <snape>I think I'll replace certbot-activation with that <roptat>actually the patch may be a bit too big: 2MB <civodul>do you mean you already translated the whole thing? :-) <roptat>no, I just added the rules to translate it <roptat>it seems I forgot the attachement <roptat>I'll send the same without the french manual <roptat>the way it works is that po4a creates or updates the po file for a language from guix.texi <roptat>then guix.(locale).texi is generated by po4a from (locale).po <mbakke>roptat: It's possible the attachment was scrubbed for being too big. <marusich>Does anyone here understand the difference between LOG_COMPILER and LOG_DRIVER? I do not understand from reading the Automake manual and inspecting our Makefile.am what the contract is for these things. <marusich>From reading the section "15.3.3 API for Custom Test Drivers" I understand that log *drivers* are expected to follow some kind of contract which is pretty well defined in the manual, but I do not have a clue what a LOG_COMPILER is supposed to do. Just run and return an exit code? I don't know.