<iskarian>sneek, later tell jpoiret: re: finding guile bindings, I'll often just search the guile manual, the guile source code, and/or the guix source code. Geiser seems to think about half of everything is "define"...
<stfnbms>LibreOffice gives me the error message “Missing hyphenation data. Please install the hyphenation package for locale “de”.” I would like to, but cannot figure out which Guix package provides those patterns to LibreOffice.
<yoctocell>PurpleSym: re `package-with-explicit-python', that would be nice, then someone could easily build a group of haskell packages with another version of GHC.
<muradm>previously i was mentioning problem with running make check-system for any test on core-updates-frozen, for instance "make check-system TESTS="basic"", works, tests pass ok, but in the end of the day guix reports "build failed".
<vivien>Hi guix! I’m trying to use guile-gi. However, when I run: echo '(use-modules (gi)) (use-typelibs ("Gtk" "3.0"))' | guix environment --ad-hoc guile guile-gi -- guile there are a bunch of warnings but nothing happens. Is it the same for you?
<PurpleSym>civodul: Excellent! I’ll see if it fixes the issue for me tomorrow.
<vivien>(I notice that with --pure, it works, so maybe there’s an environment issue somewhere?)
<maximed>Guile reads commands from standard input. In your example, the standard input of Guile is the standard output of 'echo'. 'echo' only outputs two commands to standard output, so guile will only read (and run) the two commands
<maximed>vivien: maybe run ,trace (eval (current-module) '(use-typelibs ("Gtk "3.0"))) to figure out where it is hanging?
<maximed>('eval' because 'use-typelibs' appears to be a macro)
<muradm>civodul: bug#50604 acknowledged.. make check-system on core-updates-frozen related.. :)
<vivien>maximed, if I run ,trace (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) the trace stops at "In procedure procedure-name: Wrong type argument in position 1: #f"
<vivien>But If I run (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) (in another session), I don’t get a prompt and I can’t kill the evaluation
<vivien>If I run ,trace (eval '(use-typelibs ("Gtk" "3.0")) (current-module)) in a pure environment, I get the same output: the trace runs for a while and stops at In procedure procedure-name: Wrong type argument in position 1: #f
<vivien>And if I run (eval '(use-typelibs ("Gtk" "3.0")) (current-module)), the evaluation succeeds and I get a prompt.
<roptat>what does "guix build xfce4-terminal" and "guix build xfce4-terminal --no-grafts" tell you?
<roptat>it should be a path in the store, and they should be different
<vivien>lilyp, I have 3 warnings in the working case, and a few CRITICAL for the non-working case, including a suspicious cannot register existing type 'GdkPixbuf'
<CaptainDrewALT>So I did that guix pull from earlier (my cpu isn't great it took a moment) then did a guix package -u. All of a sudden installs work again??? Whatever it needed to resolve has obviously been resolved.
<muradm>is it too late to update wayland-protocols on core-updates-frozen to 1.21 ?
<muradm>Building the following 1423 packages would ensure 2594 dependent packages are rebuilt
<iskarian>Yeah, I can get what you're seeing by setting "GOROOT=~/.guix-profile", so I think that might be what's going on
<katco>iskarian: ah! that appears to be what's going on. i am in the middle of redoing my config files, and i have `GOROOT` set to $GUIX_PROFILE/share/go. i forget why i did that, but i think i can unset it.
<katco>iskarian: ok, sorry for the false alarm. i'll close the bug with notes. and thank you for all your work on guix!
<iskarian>katco, no worries, I'm glad we found the issue :) let me know if anything else breaks! there were a lot of changes in our 1.17 release, and I don't actually use Go
<katco>so far this is the only thing i've run into
<iskarian>sneek, later tell yoctocell: idea for further updater improvement: detect when a package inherits its source from another, and don't bother checking (unless it was specifically specified on the commandline I suppose)
<apteryx>civodul: any experience running 'perf' in a guix container? I did 'guix environment -C --expose=/gnu/store --share=/sys/kernel/debug ldc --ad-hoc less strace zile perf', but getting 'Error: No permissions to read /sys/kernel/debug/tracing/events/raw_syscalls/sys_(enter|exit)'
<iskarian>Oooh, I managed to segfault 'guix refresh'
<roptat>geex3, on a foreign distro, there's a gnu-store.mount systemd service
<geex3>roptat: thank you sir, is it similar in our distro? (the contents of that unit file, looking into it now)
<sneek>yoctocell, iskarian says: idea for further updater improvement: detect when a package inherits its source from another, and don't bother checking (unless it was specifically specified on the commandline I suppose)
<yoctocell>But a lot of the packages aren't part of Stackage, so I am not sure how we should deal with those
<yoctocell>iskarian: how exactly do we detect if a package inherits the source from another package?
<iskarian>I'm not sure! Probably checking the source-location or something. It would be an optimization to put in (guix scripts refresh) for sure. I just wanted to put it out there :)
<yoctocell>Ah, I am not too familiar with how source-location works, but something nice to have. :-)
<iskarian>by the way, I discovered that remote-refs can cause a segfault if there are too many refs in a repo
<podiki[m]>yeah they seem to do well, and with their overlays (or whatever it is called), setting up environments with known versions
<yoctocell>yeah, I wish Guix had something like overlays
<yoctocell>I think there was some work on "parametrized packages", around a year ago
<iskarian>civodul, oh I think I did an oopsie. Moving repository-close! to after the calculation of the return value fixes it. I think I assumed it worked like remote-disconnect in that resources were still available after closing, but I think it frees all memory.
<civodul>though this could/should be considered a bug in Guile-Git: no Scheme hacking should lead to segfaults
<iskarian>Hmmm. Should I not be calling repository-close! at all in this case? Will it automatically be freed by a finalizer?
<civodul>i think right now it has to be called, but it prolly shouldn't be that way
<civodul>or rather: calling it prematurely shouldn't lead to segfault
<iskarian>I know very little about how guile's ffi works, but I have a theory: by moving the calculation out of the tail call, it remained in the scope of 'remote-refs', so the memory of the remote-head-list wasn't yet freed. but in tail-call position, perhaps the calculation was no longer in the scope of 'remote-refs' so the memory was freed before the calculation occurred