<nckx>mroh: You should try to remove those bundled sources. <roptat>ok, I managed to build the bootstrap groovy, now I'm struggling with the standard library <grubles>what can cause a hash mismatch when running guix system build? ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.gnome.org | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/'
<nckx>grubles: ☝ please paste the actual error there. ***ChanServ sets mode: -o nckx
<nckx>paste.debian.net is down because it is a day ending in -y. <grubles>here's the hash sum error...i have to type in manually since the box is not connected to the internet currently <nckx>I really hope you didn't type the hash(es!) manually but I fear the answer. <nckx>Let's find the new URL... <nckx>Jinkies. I'm confused at how you can get a (download) hash mismatch on a machine without 'net access but OK. <nckx>Then run reconfigure again. <grubles>oh, it runs into that error even if connected <nckx>The command above will fix that. But is your Guix old? icu4c was updated to 66.1 in March... <grubles>nope just downloaded the image a day or so ago <drakonis>if only the install images didnt take forever to upgrade to a new repository revision <nckx>They take as long as any other month old system, live or not. So yeah, forever is about correct. <nckx>grubles: Did ‘guix download ...’ ‘fix’ it? <drakonis>then it doesnt even manage to allow me to use the updated repository to generate a system <nckx>I always pull before installing. <grubles>ahh guix pull is what i need i think <nckx>drakonis: Do the images have substitutes disabled or something? <nckx>grubles: That does not require forgiveness. Welcome. <nckx>As drakonis notes, it will take a while. <nckx>I find it acceptable, but de gustibus et CPU speedibus &c. <drakonis>they do have substitutes, but the process to download them is also plenty slow <drakonis>it can only do one thing at a time and it does bog down the process <drakonis>it spends a lot of time compiling all files <nckx>It's all right but there's mucho room for optimisation. <drakonis>i'd say that room for optimization does not begin to describe it <drakonis>i wish it could perform as fast as nix does <drakonis>even smaller tasks like installing or dropping into an environment take too long <nckx>Bed time for nckxes, 'night all. o/ <xelxebar>sneek: Later tell efraim: Did that beaglebone black disk image ever build? <ryanprior>I'm working on a package that, as part of its tests, wants to inspect files in its own .git directory. Is there a way I can instruct Guix not to dispose of that? <ryanprior>Or should I disable the tests? Or is there something else I should try? <guix-vits>ryanprior: IDK. Guix, it seems, do not deletes .git from tarballs. But in package perl-czplib (perl.scm) .git deleted manually. Probably .git is bad for something. <ryanprior>Might be relevant to note that I'm using the `git-download` method and not a tarball. <apteryx>janneke: haha! the xz-bootstrap supports --memlimit with % after all, my mistake was really silly... forgetting a space between the args passed as XZ_DEFAULTS. <guix-vits>Or the .git were available (for good or bad). <iyzsong-w>in (guix build git), 'git-fetch' delete the '.git' directory. what are those tests for, i think you could disable them... <ryanprior>It tests using its own repo as data, which in the common case probably works fine <iyzsong-w>um, those tests look useful, but we can't get '.git' in source, as they're changing, and not fixed? maybe have to skip them.. <apteryx>is it safe to evaluate parallel-job-count anytime, or is it safer to defer its evaluation until the point where it's needed? <nalaginrut>hi folks, how can I publish my guix compatible package? <apteryx>you can send its definition to guix-patches@gnu.org for review <apteryx>using git send-email or alternatively attaching the result of git format-patch <apteryx>recommended read: the Contributing node of the info manual. <nalaginrut>I want to set my repo to allow people publish without manual review <apteryx>you may be looking for a channel, if you want to allow your personal packages to be available before they get merged into guix proper <apteryx>a channel is basically a git repo with a few Guile modules defininig packages. When adding a channel, its package definitions are made available in additions to those of Guix. <nalaginrut>I want to provide a channel for Artanis users to publish their plugin/extensions easily <nalaginrut>so that I don't have to write a pkg-manager for Artanis <apteryx>it can be used as a quick sharing tool/sandbox to refine packages to eventually contribute to Guix proper :-) <nalaginrut>Yes, could be quick sharing temporarily to mine, if it's not Artanis specific package, then I'd recommend to contribute to official repo. <nalaginrut>I want to write a web service to do some simple checks, at least the package licenses has to be GPL compatible ***iyzsong-- is now known as iyzsong-w
<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? <mroh>peanutbutterandc: try setting geiser-guile-load-path. <peanutbutterandc>guix-vits, Okay, so I load up a guix-package.scm, then I tried M-x guix-switch-to-repl but it isn't available. <guix-vits>peanutbutterandc: Yes, seems that repl should be started somehow beforehand.. <guix-vits>Other commands may trigger "Starting Guix REPL" too. <peanutbutterandc>M-x geiser-load-current-buffer tells me "No Guiser repl for this buffer".... <guix-vits>peanutbutterandc: IDK, but "/run/current-system/profile/share/guile/site/3.0" is in %load-path of M-x geiser RET guile RET. <Brendan[m]2>peanutbutterandc sounds like your environment is incorrect <peanutbutterandc>Brendan[m]2, I use guix on a foreign distro, and guile is installed via guix <peanutbutterandc>I thought everything was all right, and thought that `guix repl` was created just to cope with this issue <Brendan[m]2>sounds like GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH aren't set right <Brendan[m]2>I fonder if .config/guix/current/share/guile/site/3.0/ should be there <peanutbutterandc>Brendan[m]2, You're Mr. Tildesley, right? I did the patching for Calibre as per your suggestion. (: [And yes, that makes sense. I will try that out.] <peanutbutterandc>Good to see you, Mr. Tildesley. Your critical thinking skills are something to be envied. I had never noticed the ..binary-real-real issue. It is rather ugly. <peanutbutterandc>I will be on the lookout for any more ..binary-real-real-s in my system from now on. Thankfully, there are none, yet. <Brendan[m]2>peanutbutterandc hopefully. reviews are a lot slower that they used to be. it can take a long time to get something in <Brendan[m]2>so im just working on multiple things and dumping them in emails <peanutbutterandc>Brendan[m]2, I see. Anyways, I did extend GUILE_LOAD_PATH... but it isn't as great as `guix repl`... I wonder if I can use guix and geiser without that.... <peanutbutterandc>,use (guix packages) in `guix repl` just imports the module, but with `guile` it goes on to compiling a lot of stuffs.... <peanutbutterandc>I don't know... I have a feeling someone should have figured out a way to do this beforehand <peanutbutterandc>I use `guix repl` to get the procedure docstrings (after I `,use (ice-9 session)`) <peanutbutterandc>but it seems that if I can get geiser to do the work, I'll be able to do the whole thing a whole lot faster <efraim>xelxebar: it looks like I need to plug my pine64 into a display, it doesn't seem to be booting ATM. I'll try to do that today <sneek>efraim, xelxebar says: Did that beaglebone black disk image ever build? <xelxebar>efraim: Oh no. Hope we didn't fry your board <efraim>xelxebar: they're generally pretty resilient. worst case scenario is a corrupted SD card <efraim>I've been through a few in the past few years with the boards ***iyzsong-- is now known as iyzsong-w
***iyzsong-- is now known as iyzsong-w
***apteryx is now known as Guest3271
***apteryx_ is now known as apteryx
***iyzsong-- is now known as iyzsong-w
<Brendan[m]2>strace shows a "epoll_wait(3, i/o error: No such file or directory (os error 2)" but no indicated of what file it actually is. Any tricks I can use to figure it out? *Brendan[m]2 thinks bug-guix@... should be guix-bug@... <Brendan[m]2>i kept accidently sending bug reports to guix-bug because of guix-devel and guix-patches <efraim>I have a custom /etc/os-release file I created with the BUG_REPORT_URL set (as per freedesktop standards) and I check it most times before sending bug reports :) <efraim>with glibc-2.32 now in core-updates it's time to test my wip-ppc branch again <efraim>so many projects on my TODO list ***iyzsong-- is now known as iyzsong-w
<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. ***ae is now known as Guest15454
<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]). <nckx>That does not look like the most robust-against-random-heavy-loads-across-many-core-machines test. <nckx>But I don't know much PHP. <nckx>I suggest we skip it based only on how iffy ( $n > 700 ) ? "microseconds differ\n" : "microseconds do not differ enough ($n)\n" is. <glv>If I read this test correctly, it would fail if my machine is too fast... <glv>I'll retry building PHP with all the cores loaded in case it works. <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). <DivanSantana>hi all, after later guix system reconfigure I'm getting unboand variable proxy. I'm not sure what is causing that or how to fix. Anyone know? <efraim>having a hard time getting glibc-bootstrap-system.patch to apply to glibc-2.32 is harder than it should be :/ <nckx>apteryx: No. Perhaps you're confusing it with ioctl_fideduperange. <apteryx>nckx: oh! What are those links used for if not for deduplication? <nckx>I mean btrfs does not do its own deduplication. <nckx>It implements that ioctl, though. We could ask it to, but it's not automatic. <nckx>The links are used for dedup, yes. <civodul>efraim: oh, i admit i didn't check that <efraim>civodul: it doesn't come up much :) <nckx>glv: OK, done, thanks. It will make its way onto staging with the next merge but I'm not going to force that now. <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 <efraim>I'll commit the updated patch later <civodul>editing patches in Emacs is pretty fun, i agree with apteryx :-) <nckx>Oh? Something about the pattern in which I edit always confuses emacs's diff-mode into corruption. This is the first I hear of it working. <PotentialUser-85>Good afternoon! During the booth installation there is one red long line that the python language .tar <PotentialUser-85>is not found, as a result of which the installation stops, the program displays the installer on the start screen with the choice of localization, etc. <roptat>PotentialUser-85, is thit 1.1.0 or latest? <rotty>janneke: i guess I'll fall back to installing guix system in a VM (locally), and then dump the virtual hdd onto the actual target system <roptat>can you try again with latest? it's built from the current master, maybe your issue was already fixed? <roptat>1.1.0 is starting to get a bit old <PotentialUser-85>Thank you all for the advice, now I will try to download and install again. <mfg>out of curiosity: when are releases made anyway? (if any) <civodul>mfg: we're not doing as good as we'd like <civodul>i guess it's a mixture of technical and social reasons <civodul>but there should be one Real Soon Now <elxbarbosa>ouch, installing mpc and it is nowhere to be found <civodul>hi elxbarbosa, what exactly isn't found? <elxbarbosa>first Ive installed it w/ a manifest file, then manually, none of these way cant find it. I even did check /bin and /sbin... <civodul>ah i see, you're probably looking for "mpd-mpc" <civodul>yeah, i did "guix search mpc" to see what you had in mind :-) *apteryx is puzzled by how the compressor-command is formed using Gexps in (guix scripts pack) <apteryx>puzzled, eh. I thought that Gexp (#~) always expanded to scripts, but I see it being used as data <apteryx>such as in the (string-join '#+(compressor-command compressor)) <apteryx>so they can be manipulated as sexps. Interesting. <civodul>i knew what you really meant was "amazed", see? :-) <apteryx>will this embedded gexp, #~("I" (string-join ...) end up as a script in the store? *civodul is low on energy today, looking for ways to cheer up <civodul>a gexp does not necessarily map to a script in the store <elxbarbosa>hey, how to correctly add EMACSLOADPATH and GIT_EXEC_PATH, enabling these vars break my system <apteryx>civodul: OK! Thanks for clearing that up :-) <apteryx>elxbarbosa: on a foreign distribution? <apteryx>it houldn't "break your system" :-) What are the symptoms? Are you setting these manually (there's no need to do so). <elxbarbosa>apteryx: sorry, emacs wont start if I enable export EMACSLOADPATH="${GUIX_PROFILE}/share/emacs/site-lisp:${GUIX_PROFILE}/share/emacs/26.3/lisp" <elxbarbosa>so does git wont work if have thisn in .profile: export GIT_EXEC_PATH="${GUIX_PROFILE}/libexec/git-core" <elxbarbosa>if needed I can enable it and paste the output of having it enabled <mfg>why do you even have to set those? <apteryx>there's no need to manually export these variables; sourcing ~/.guix-profile/etc/profile should be enough. Which should be done for you already on Guix System. <elxbarbosa>hey, what you all prefer: tutanota, protonmail or xxxxx? thanks *apteryx wonders how to slip (parallel-jobs) in the args of the compressors, to be lazily evaluated in the 'build' script. <civodul>problem is IIRC parallel xz is non-deterministic <apteryx>yeah, but that'd be true also for lzip or others that support multi threading <civodul>i think there was a patch for that in the past and we ended up rejecting it <apteryx>civodul: I think i've found a way to make it deterministic <civodul>i think that was nckx mbakke or cbaines <apteryx>yes, Leo pointed that to me. It was from Marius. <apteryx>I don't really like having %xz-parallel-args in (guix build utils), but that seems like the best place to share it across places, without duplicating it. <civodul>well double-check with "guix build --check" & co. :-) <apteryx>perhaps that's poorly worded; I mean if you have 2 cores compression happens twice as fast, 3 cores thrice as fast, etc. <civodul>also worth checking memory usage, xz has a reputation of being quite bad at it <apteryx>yes, that's what the --memlimit=50% takes care of <civodul>yes, that's linear speedup, but i suspect it's sublinear in practice <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. *civodul goes afk for a bit <mfg>does guile have a similar shortcut like [:-3] for strings? so cutting the last 3 characters of a string? <mfg>found it, thank you :) <luis-felipe>I was trying to get a stack trace of Glade but gtk+ and glade packages don't have debug outputs. How can one get the debugging symbols for these packages? <nckx>roptat: Dealt with, thanks. <bonz060>Nothing sucks like replying to spam :'( <bonz060>Has anyone been able to use guix pack to create a docker container and use /that/ in CI build? <andreas-e>nckx, they did raise interesting points. I am ending up with a video on my hard drive I would like to watch. <nckx>I hope everyone's clear on which video you mean. <nckx>Yeah, the NixCon video looks interesting! <efraim>I have that one downloaded to watch later <efraim>gotta see what they like so we can give them more targets to shoot for ;) <nckx>Same. Good thing we attract only incompetent spammers. Thanks! *nckx AFK to absorb the last slivers of sunlight through their totally human skin. <efraim>regarding using a guix system docker-image to use for CI systems, do they allow running in privileged mode? <bonz060>efraim: What do you mean privileged mode? <efraim>bonz060: The last time I ran a docker image created from 'guix system docker-image' I needed to use 'docker run --privileged ...' <bonz060>Oof. I created an image using guix pack; and loaded the same using `docker load --input`. Seems to work without any privelege escalation :) <efraim>Ah. My use case was more for test building guix packages inside other CI systems. <bonz060>The wall I've hit is runing things inside the GH actions using a container I created. <efraim>I've never tried using github actions <andreas-e>nckx: Yes, that is the exciting one! Enjoy the sun. <andreas-e>efraim: I did the following in a guix docker image: <andreas-e> (service guix-service-type (guix-configuration <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 <efraim>I think the privilege separation inherent with the daemon prevent it from working without chroot disabled. I guess it would be possible to start with nearly an empty container <apteryx>arg. Emacs frozen on Geiser large output. Classic. *raghavgururajan is facing issues with gateways ***mekeor- is now known as mekeor
<nckx>raghavgururajan: Anything we can help with? <raghavgururajan>nckx: Nah! disroot's gatway was having hick-ups, so tried hot-chilli and found out it was blocked/banned. ***ae is now known as Guest8198
<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. <civodul>sounds like the continue-upon-syntax-errors semantics will have interesting side effects *mekeor is installing guix-system whooo <mekeor>hmm. `guix system init` failed building `shells`. i will run `guix pull` and try again :) <civodul>hey mekeor, could you paste your config.scm and the command and its output? <mekeor>ah, looks like i just had a typo in my (operating-system (users (user-account (shell #~(string-append #$zsh "/bin/zsh"))))) – i forgot the "d" in "string-append" <mekeor>it works now. thanks, though, civodul :) <civodul>so "shells.drv" would fail to build due to an unbound-variable error <civodul>(though better than a boot-time failure!) <andreas-e>guix gc is too slow on a spinning disk with many packages! <andreas-e>On bayfront, it prints "deleting /gnu/store/....lock", one line every few seconds. At this speed, we will still be there tomorrow! <mekeor>damn. i started receiving ata-errors, indicating that my hard-disk is broken :( <civodul>andreas-e: there must be something else going on on the machine <andreas-e>Now it has become better, since it is hitting bigger files also. <civodul>loads of "syscall_332" when stracing that guix-daemon process <andreas-e>Now it is at the "deleting unused links" phase. <andreas-e>But I think you already worked on optimising things, right? <efraim>looks like there's an issue with my bootstrap guile if it doesn't like using system <civodul>efraim: the issue above has to do with glibc-bootstrap-system.patch <civodul>the 'system' function must try to execute /bin/sh or something <efraim>I'll have to look at it tomorrow. running it from the store directly doesn't fail because it's not a build container <efraim>i'll comment out the line overnight and see if glibc-final-with-bootstrap-bash builds. if glibc-2.32 is as problematic as glibc-2.31 I'll have to spend more time on it <efraim>New plan b: revert the change to the patch and have the static glibc in make-bootstrap inherit from glibc-2.30 😃 <apteryx>civodul: dropping the ' quote at the call site seems enough, after using #~(list for every compressor definition. :-) <apteryx>I saw xz using 600% (6 cores) on the remote, which used about 600 MiB of RAM to compress a pack with xz. <apteryx>that seems conservative (the machine has 32 GiB of ram and 24 logical cores). <civodul>apteryx: neat, though 600MiB seems quite a lot <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 <andreas-e>It looks like a lot of work, which I suppose is the reason nobody did it earlier.