<civodul>wingo: can it be that libgc internal locks are taken at the time of fork?
<civodul>for instance scm_i_finalizer_pre_fork doesn't (cannot?) do much about this, no?
<wingo>civodul: the only libgc threads are the mark threads. the finalizer thread is guile's
<wingo>in a pre-fork situation, we're still in the parent, everything still making progress
<wingo>scm_i_finalizer_pre_fork will join the finalizer thread (if any), making it so that there's only one guile thread running (unless you have a signal thread!0
<wingo>so the total set of threads at that point would be guile's main thread and the mark threads, which are waiting on a cond (because the world is not stopped) and which i don't think have any locks taken
<civodul>the mark threads could have locks taken no?
<civodul>there's nothing preventing that from happening, is there?
<civodul>the signal thread is created lazily right?
<g_bor_>If that happens, then my wife is willing to comentor that. She has been working in education reseach for 3 years, and have a really nice gasp as what to introduce/emphasizing main points, grouping topics, and presenting a complex matter in a digestable from. Here I persume that these videos will be primarily user facing introduction/education/documentation type materials. She also has some exposure to guix :)
<divansantana>So... I'm trying to use a custom kernel. When doing a reconfigure it says I have to load shpchp kernel module for my /dev/nvme device. When I add that module for my custom kernel it says not found. Any idea what I can do?
<rekado>divansantana: this is because the newest kernel no longer provides the shpchp kernel module
<rekado>divansantana: Guix tries to keep you from doing something that might end up in an unbootable system.
<rekado>but in this case I think you can safely ask it to skip that check.
<rekado>hmm, I’m getting a bad error in a Python package running on the cluster.
<thomassgn>um, I have a simple guile scriptfile that I run like a executable. I wanna package it, but I'm struggling. Does anyone know of packages that are simple guile (or maybe just a interpreted/script) file put as an executable in the store?
<civodul>mbakke: hadn't thought about worktrees, hmm
<rekado>thomassgn: we have a guile-build-system that might be of interest.
<civodul>janneke: the next step may be me catching up!
<civodul>unfortunately guile-build-system only works for libraries, not for "scripts"
<civodul>you could use trivial-build-system, though it's a little tedious
<thomassgn>derp, the first sentence from the guile-build-system: "This build system is for Guile packages that consist exclusively of Scheme code and that are so lean that they don’t even have a makefile, let alone a ‘configure’ script."
<civodul>g_bor: perhaps you could generate a full image, with 'guix system vm-image'?
<g_bor>civodul: ok, sounds nice. Can I also get a configuration xml for the vm?
<g_bor>Also, I would like to use postgres on one of these vm-s, and once, at the first time I use the image would like to initialize the database and load the data. most probably with a script. Is there any way to do that?
<g_bor>civodul: I am also thinking about getting ovmf working in GuixSD. The main issue is that an ovmf vm needs a private copy of the ovmf, or at least the nvram area, as vm-s write to the bios image.
<g_bor>Is there any way to keep a per-vm writeable file:
<davexunit>how do I make root user use the same exact guix version my regular user does?
<davexunit>this has been a constant annoyance for all the years I've used guix. I run 'guix pull' as my regular user, then decide I want to update the whole system shortly thereafter, so I run 'guix pull' as root and have to wait a long time for it to compile all over again.
<davexunit>I tried pointing it to the same commit but it's still building everything again
<davexunit>if there was a simple way to do a system update using my regular user's version of guix, that would be ideal.
<tune>ah, so it's just starting it. alright. I was following the instructions pretty literally. I thought maybe it was just slow to do something, so I opened another shell to start and enable it via systemd
<nckx>You can Ctrl-Z out of it, then 'bg' to run it in the background.
<nckx>Or run "guix-daemon --build-users-group=guixbuild &" if you've already killed it.
<davexunit>dustyweb: how does the new guix pull make running from a checkout easier?
<davexunit>rekado: re: tune's comments above. I've seen so many new users get stuck on that setup guide because they don't understand what a daemon does.
<davexunit>I think a note is needed that the process is *supposed* to never exit until you kill it.
<tune>to be fair, I am actually familiar with daemons, I was just kind of zoning out and copy/pasting stuff
<tune>sharing a server with a couple guys and one of them keeps removing vim and other programs he doesn't use, screwing over the rest of us. I suggested installin guix so we can have user-level package management, but I'd only used guix on guixsd previously
<tune>btw did that rust issue get fixed? I can't remember. checking before I waste time building
<tune>if I want to make an alias for building stuff more slowly, should both guix pull and guix package have # of cores to use specified?
<tune>'guix pull -c 2 && guix package -c 2 -m ~/manifest.scm' was thinking something like this for user packages, not sure where to fit in the -c 2 for a guix system reconfigure
<tune>I'd rather not do it via environment variable since I don't want it to always use less cores
<bavier>tune: you'd need to give the command-line option each time then, for both