<peanutbutterandc>Okay, in geiser, if I run M-x geiser-load-current-buffer, I get the error about "no code for module (guix packages)" and stuff. I do have emacs-guix installed. How do I go about fixing this please?
<efraim>I want to update the go-build-system to delete the vendor directory and symlink all the go dependencies into it
<efraim>go feels like we should just have dynamically created dependencies, give it a uri, commit and license and have it do the rest from there.
<efraim>I want to strip some of the bootstrap binaries and reuse some of janneke's early packages for other architectures
<efraim>It's going to take a while, I'm reviewing the docker patches in case anyone else was looking at them
<janneke>efraim: yes, it would be great if those could "grow" towards eachother. on a slightly longer term i'd like to replace gcc-2.95.3 with gcc-4.6, and after that it might be possible to backport power (and riscv?) to that
<efraim>I wonder if 4.2.1 might be an easier target. with the BSDs doing a lot of work to backport support for other architectures for THE LAST GPL-2 version it might be an easier target
<janneke>dannym's work on tinycc is helping mature the lower end of the bootstrap graph and i am working to remove mes from the bootstrap binaries and replace it with stage0
<janneke>efraim: ah, it's just that 4.6 is now the latest C-based release, it may be wise to use another stepping stone, at least initially, yes
***iyzsong-- is now known as iyzsong-w
<efraim>one of the docker patches adds seccomp to docker
<efraim>it can be disabled again in the 'docker run' invocation
<efraim>it looks like it also gets ignored if you use 'docker run' with '--privileged'
***ae is now known as Guest14973
<rotty>is it possible to "chroot" into the guix-sd installation ISO?
*rotty is toying with getting guix-sd onto a hetzner cloud VM, using their rescue system...
<janneke>rotty: i guess, if you can find a shell somewhere (/run/xxx-system/profile/bin/bash maybe?)
<janneke>the os formerly known as guix-sd is called Guix System nowadays ;-)
<peanutbutterandc>Hey there, I'm trying to build a cmake project. And it calls for a uuid library as a dependency. However, the only one available in guix is crossguid
<peanutbutterandc>efraim, but just for the sake of the argument (because I want to learn) is there a way to make it use crossguid? If yes, how?
<efraim>no idea. it looks like crossguid also uses util-linux. you might be able to use busybox/toybox if you want something different :)
<peanutbutterandc>efraim, I see. Thank you very much. While I'm grepping on the side, how do I specify the lib output of util-linux as a dependency in another package definition? ,util-linux:lib does not work.
<glv>Hi. I'm currently testing merging the wip-lisp branch into the staging branch to see if there would be issues. Trying to build nyxt fails because it indirectly depends on php which fails to build (error in test phase for ext/date/tests/bug73837.phpt).
<glv>However the same version of php builds fine on the master branch. Does someone know what the problem could be on staging?
<nckx>glv: Suboptimal answer, but I know the PHP test suite fails inconsistently (alas, never on any of my machines). Try... again?
<nckx>If the error message is consistent, it's worth investigating further.
<glv>I tried 5 times, and I always get the same error (Bug #73837: Milliseconds in DateTime() [ext/date/tests/bug73837.phpt]).
<glv>nckx, slowing down my machine made the test pass. Yes I think you should push your patch, it will allow the build farm to have substitutes more consistently (e.g. for webkitgtk which depends on PHP and takes a while to build).
<apteryx>woah, haven't run 'guix gc' in a year or so. The 'deleting unused links...' part takes forever. Is that for deduplication?
<apteryx>perhaps an option to opt out of the daemon's native deduplication could be useful for Btrfs users (btrfs does its own deduplication).
<nckx>apteryx: You might've heard something about an experimental kernel patch set to do so. However it was never merged and AFAIK is pretty much dead at this point. It had the same problems as ZFS dedup (huge RAM usage making it unsuitable for broad adoption) and was incompatible with actually useful features like compression.
<mbakke>efraim: isn't that glibc patch mainly s/__posix_spawn/posix_spawnp/ ?
<efraim>mbakke: yeah. but for some reason when I edit the patch it no longer applies
<mbakke>efraim: ah, hand-editing patches is fragile, I always create a new diff
<efraim>mbakke: I hate it when it's something like that
<apteryx>efraim: do you do it in Emacs? the diff-mode has some support to automatically update the hunks metadata
<efraim>re-doing the patch switched the two parts and now it magically works
<apteryx>the available memory (RAM). I don't know what magic it uses to find that.
<civodul>xz using up to half of my RAM sounds a bit scary no?
<apteryx>currently when testing 'guix pack', it uses my host machine number of cores, not the offload machine, which has many more, so I was trying to get the args to be lazily evaluated.
<civodul>it's weird to express the limit as a function to the available RAM
<civodul>ah yes, make sure to call parallel-job-count in the build env
<apteryx>yeah, hence my earlier questions about the Gexp definition of the %compressors. I don't see how I can append my dynamically created args in there (it needs to be plain types given passing the Gexp boundary, IIUC).
<apteryx>I could glue something less elegant in the lower build gexp directly
<civodul>i haven't looked in detail but perhaps #~(list "xz" (string-append "--threads=" (parallel-job-count)))
<civodul>depending on what the call site looks like
<luis-felipe>In the Installing Debugging Files section in the Guix manual it says "GDB must then be told to look for debug files in the user’s profile", is this necessary when using the GNU system or just for Guix on foreign distros?
<mfg>how do geiser and company work together? geiser finds symbols which company doesn't complete
<civodul>luis-felipe: on Guix System, the default ~/.gdbinit contains the right incantation
<luis-felipe>civodul: Ah, right. Should have opened the file myself to check.
<andreas-e>I mean, in the system configuration that I passed to "guix system docker-image".
<bonz060>efraim: I want to give a serious shot. If it doesn't work out, I'll try to figure out; If I don't get GN2 tests running, I'll go back to Travis- I'm used to that- and should be easier to setup.
<apteryx>civodul: I've now defined my compressor-command as #~(append (list #+(file-append xz "/bin/xz") (%xz-parallel-args)), %xz-parallel-args being a procedure in scope (via (guix build utils)) on the builder's side. The call site looks like: #~("I" (string-join '#+(compressor-command compressor))). Any ideas on how I could adapt the call site so that my compressor-command gets expanded properly on the
<nckx>‘Sudo no longer refuses to run if a syntax error in the sudoers file is encountered. The entry with the syntax error will be discarded and sudo will continue to parse the file. This makes recovery from a syntax error less painful on systems where sudo is the primary method of superuser access.’ :-o Also, having your entire sudoers file on one single undebuggable line is no longer supported. The times they are truly a-changing.
<apteryx>it'll scale down on lesser systems. At the default compression setting, it uses about 100 MiB per core, and we enforce minimum 2 cores even for single core systems. That's a minimum requirement of 200 MiB, which seems reasonable.
<apteryx>the only oddity is that when passing -c1, it still uses 2 cores, but that's required for reproducibility (xz results differ betwen single/multi-thread modes).
<apteryx>guix build --source -c2 webkitgtk -> 57.488s / guix build --source -c4 webkitgtk -> 41.885s on my old deskto
<apteryx>on the beefier machine: 2 cores -> 26.19 s and 224 MiB, 8 cores -> 14.75 s and 956 MiB
<apteryx>seems to become less and less linear with the greater amount of core. But with --memlimit=50% it seems to conservatively throttle itself to use maximum 9 cores or that 24 logical cores machine.
<nojr>Hello. I'd like to ask a question. How come Django 3 is not in the package repos? I've asked this a couple times but no one ever answered. Is it because it's not possible to build it in a reproducible way?
<shcv>anyone know where I can find instructions or help for setting up guix-sd on a ZFS root?
<shcv> I have an existing system currently on a zfs root that I'd like to switch over to guix; it seems like it should be pretty straightforward, but I don't know how to make sure the zfs modules end up in the initramfs, or how to add the necessary kernel parameters