<jgart[m]>Maybe we can translate the other 93% with ****GPT. I had ****GPT explain continuations to me the other day like if I was 5 years old. It's was the deepest yet most lucid explanation of continuations I have ever witnessed. Mind was continually blown. I think I am a better schemer today because of that explanation.
<akirakyle>Is daviid around? I'm trying to get set up with g-golf on guix with the latest 0.8 version which isn't currently packaged so I thought I'd bump the commit, but now building g-golf is failing with a linker error "undefined symbol: gi_type_tag_extract_ffi_return_value" and so here I am seeing if there's anyone who's already tried to do this?
<daviid>akirakyle: i don't use guix, so very likely won't be able to help, everything works fine here (ofc, i wouldn't release otherwise, not even an alpha release), but is this the first and only undefined symbol error you get?
<daviid>akirakyle: just to make sure also, the version is 0.8.0-a.1 - you should keep it 'as is' i guix as well, so users know it is alpha ...
<jgart[m]>Does anyone know where mcron writes the logfile to?
<daviid>akirakyle: gi_type_tag_extract_ffi_return_value is part of libgirepository-1.0, since 1.72 - it would seem to me you are compiling against an earlier version, can you check, then if that is the cause, update libgirepository-1.0 to the latest
<akirakyle>daviid: I'm trying to update the package not because I'm a package maintainer or anything, I was just hoping to play around with it and I'm using guix
<akirakyle>I'll check what version of libgirepository I'm using...
<daviid>akirakyle: i don't think guix has 'package maintainers', if you update the g-golf package and submit a patch for revision, the all guix team and users would be happy - it is who ever has free time to do it ...
<daviid>and afaict, take my words with caution as i am not a gix user, but it inded should just be bumping the commit and the version, everything else in the package def should remain the same since its last update -
<akirakyle>daviid: Yeah I know, I just meant more that I'm not really involved in helping to maintain anything in guix, still just trying to learn the whole system
<akirakyle>It looks like you're probably right, guix currently only packages gobject-introspection 1.66.1
<daviid>akirakyle: ok, you need 1.72 - and thanks because i now see i need to update my configure.ac file as well ...
<akirakyle>Yeah configure should probably complain first
<daviid>akirakyle: indeed, my bad, good catch! see, you helped already ...
<akirakyle>Also while you're here, what's the difference between g-golf and guile-gi? It seems like guile-gi isn't very active the past year. Also it looks like g-golf uses more guile versus c than guile-gi, but is there some reason to choose one over the other?
<daviid>akirakyle: it is a difficult question to answer as being the author of g-golf - but it's no secret that there are fundamental diffs in the architecture and guile-gi is mostly written in C, g-golf is nearly 100% scheme code - this said, they both try to achieve the same goal, which is to allow users to just import and use any GI typelib from guile scheme
<akirakyle>daviid: I suppose I was hoping for a more biased answer :) What do you think are advantages of g-golf over guile-gi? I think being mostly in guile is one, but I haven't studied either code nearly enough to know what potential downsides there might be if any?
<akirakyle>dang... guix's patches are failing to apply when updating gobject-introspection so trying to get g-golf going on guix will be a bit more work
<daviid>akirakyle: sorry to hear that, but updating gobject-introspection should be very straight forward i would say
<lechner>jgart[m] / on my equipment, /var/log/mcron.log
<akirakyle>do'h I didn't take the 5 seconds to see that gobject-introspection-next is already in guix so I didn't have to do a package override
<akirakyle>daviid: now make is failing with an "Unbound variable: <callable>" error
<akirakyle>daviid: Where's a good place to share this failing build output if it's helpful to you?
<akirakyle>daviid: Looks like it's failing on the makefile rule for g-golf/hl-api/ccc.go
<daviid>akirakyle: that is 'strange', but yes, the class is defined in ccc.scm
<daviid>akirakyle: you can paste, a tor-friendly paste, but i am not sure i'll be able to help, because guix has 'its way' of doing things that i am nor familiar with
<daviid>akirakyle: i think the last update was done by rekado, who has a tremendous guix knowledge and experience, i hope he comes to the rescue, meanwhile the backtrace is useless, because it truncates its output - but can you try to clean and try again
<daviid>also, do you have an already installed g-golf earlier version, i'd remove it and then clean/autogen/configure/make
<akirakyle>daviid: there is no cleaning of builds in guix since they're done in pure, completely isolated build environments. Building again will reproduce the exact same output. I only pasted the last part of the build output, here's the whole thing which I don't think contains anything more illuminating: https://paste.debian.net/1265293/
<akirakyle>I'm noticing that in the guix g-golf build recipe, there's manual patching of several files using substitute* so I should probably check those to make sure there isn't stuff that needs to be changed
<akirakyle>daviid: I'm out of ideas, configure.ac and g-golf/init.scm look like they're the only two relevant files that guix manually patches and I don't see any way they might be causing this error
<daviid>akirakyle: tx for the paste but i meant to say the guile scheme backtrace are truncated (by default) - but it is difficult as i can't reproduce, i am thinking ..
<akirakyle>daviid: Ah right, how can I get the full backtrace? On that note, I'm trying to build in a guix shell but it won't because it can't find libgirepository-1.0.so, presumably due to guile's dynamic-link not working which is why guix patches is when packaging. I thought I read somewhere that there was some LD_LIBRARY_PATH to set in a guix shell to get
<akirakyle>Nevermind on the last part, I figured it out. Needed export LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib/
<daviid>akirakyle: (g-golf hl-api ccc) is not that new, and the error is not LD_LIBRARY_PATH related, those are pure scheme modules - i'll wait to see if rekado can help, i can't think of why it fails for you, but i'll keep thinking ...
<daviid>akirakyle: i am confused now, is it compiling? and wanted to ask, when you build, it is always 'clean and isolated'?
<akirakyle>I've also separately been trying to build g-golf from a git checkout by using a guix shell to provide the required dependencies, and that's what I was posting about LD_LIBRARY_PATH, since with the git checkout, none of the patches are applied so I either have to manually edit g-golf/init.scm to provide paths into the guix store or change the
<akirakyle>environment var so the linker knows where stuff is
<akirakyle>Specifically, to change the gobject-introspection version, I changed guile-g-golf's propagated-inputs to gobject-introspection-next, however this doesn't change the gobject-introspection version used by the glib, gtk, or clutter dependencies
<daviid>akirakyle: what i remember is you need to set or unset graft - and another thing is there are other g-golf guix users, one reported a problem that i fixed, in july 2022 - the scheme files involved in the error you are seeing today didn't change since, at least the 'architecture' of g-golf wrt those, so it should compile fine ...
<akirakyle>daviid: Hmmm yeah maybe, I think from that guile-gi issue I'm understanding that grafts aren't really compatible with the way libgirepository works. I'm worried that when I bump guile-g-golf from gobject-introspection (v1.66.1) to gobject-introspection-next (v1.73.1) that gobject-introspection is still in the "package closure" of guile-g-golf since
<akirakyle>it's a transitive dependency via glib and gtk, so I'm not sure if that's then messing things up
<daviid>akirakyle: pretty sure this has no influence on the error we are looking at
<daviid>the error is a pure sheme / goops / module error
<akirakyle>daviid: I'm still trying to get to this error in a guix shell, but if I get there, is there a way I get a full traceback from guile?
<daviid>about the backtrace, you could try the guix similar comand to 'export COLUMNS=400' - though someone reported recently it didn't help, it should :)
<daviid>akirakyle: this bug, it happened here on debian as well, not the exact same. but similar, when g-golf is installed
<daviid>akirakyle: so, for the sake of prooving, can you installed the previous g-golf version, and try gain?
<akirakyle>daviid: So I actually just successfully compiled inside a guix shell!
<akirakyle>daviid: Thanks for all your help though! I'm excited to try to start hacking some gui stuff with g-golf in the future!
<daviid>i am not sure it is g-golf that needs to be compiled using --no-grafts, or just adding this to the example, i have no idea
<daviid>akirakyle: an interesting thing to share with guixers as well is that what you think is 'clean and isolated' isn't as 'clean and isolated' as you think - my 2c
<daviid>i definitely have a g-golf problem to look at and solve wrt this, but it is a guile/goops/module compilation problem 'only' [not a run time problem] that only appears iif compiling g-golf while an earlier version of g-golf is installed ...
<akirakyle>daviid: Sure, I think this quote may be relevant to what I'm interpreting you meaning with that: "As Simon Peyton Jones, a well-known functional programmer, likes to say, "All you can do without side effects is push a button and watch the box get hot for a while." (Which isn't technically true, since even the box getting hot is a side effect.)" —
<lilyp>jgart[m]: you could use the pipe function from guile's standard library
<gabber>i get a "guix pull: error: Git error: object not found - no match for id". i am trying to set up my personal channel (for testing/understanding purposes only; what am i missing? i'm invoking guix pull with --url and --allow-downgrades set
<gabber>what does that mean? what is git looking for? some specific commit?
<nckx>Could it be your chosen channel authentication commit? (--disable-authentication)
<gabber>this does indeed give me another error message :) i haven't set up authentication, authorization and the keyring branch (are they necessary?) from reading the manual this seems to be optional ("As a channel author, consider bundling authentication material...")
<GNUmer>Hey! Really glad to be here and I finally got my RX 480 to work with Guix just by blacklisting the amdgpu driver. GLXgears runs fine, so most 3D rendering should be fine too. My only problem now is resolution, since Xorg is forcing me to use the 1024x768 resolution, which is definitely not the true resolution of my display. How can I inject the `resolutions` declaration into `xorg-configuration`?
<leg7[m]><oriansj> "leg7: sure and having provided..." <- Ok so my computer has a tpm 2.0 which allows me to add keys from the os with efitools
<leg7[m]>Can I encrypt everything with this setup without drawbacks?
<pjalsDanielv[m]>if your using luks2 with something else than pbkdf2 you might need to patch grub
<lechner>leg7[m] / thanks for reminding us the we could add our own boot keys. i am not sure i ever met someone who does. also, i personally think 200-300 MB is a good size for the ESP. I prefer UEFI over legacy on most systems
<oriansj>lechner: well base level guix is easy to install, tweaking to the point where you are happy however is a very different story
<oriansj>Kolev: although you may wish to file a bug report as it means the guix package definition for keepassxc needs tweaking as the wayland backend is missing and we are working around it by explicitly enabling the X11 backend
<silicius>I made a working nyxt-prerelease (version 3-prerelease-2) package. Should I send a patch? idk what's the general stance on prerelease/alpha versions in guix.
<silicius>It has some problems like a broken emacs-mode but is usable and has some new features like native support for gopher protocol
<mirai>lechner: I don't know if connman suffers from the same kind of issue
<mirai>would have to dig into its documentation to see how it expects to be started up
<lechner>mirai / as for exec-command, does it also spawn? otherwise, being connected will result in the Shepherd terminating, because it was overwritten by the 'exec' syscall
<lechner>mirai / sorry, 'fork' is the correct terminoloty
<gabber>any idea why i can clone repo1 from my git-daemon-service but not repo2? i'm like 60% sure i initialized them the same way (`git init --bare`), the permissions look identical, the directory structure (and the contents) seem to be the same, there's an empty file called `git-daemon-export-ok` in both directories. i even restarted the service (for good luck)
<mirai>lechner: ugh, nvm, using a lambda_ invoke just makes it not crash at reconfigure
<lechner>gnucode / i am not sure about how to deliver mails into Dovecot, but i'll soon find out. My ISP gave me a static IP and opened up port 25. In a few weeks I'll be gone from Kaboogle. I cannot wait
<vagrantc>guix weather fluidsynth says both ci and bordeaux match ... with a different fluidsynth
<vagrantc>or well ... ugh. i can't keep all these hashes clear
<oriansj>vagrantc: guix challenge should be able to keep all of those hashes clear
<nckx>rekado: Are you in the middle of something with the Honeycombs? The two listed at https://ci.guix.gnu.org/workers look very stuck, don't accept hydra's public key. pankow does (and has a load average in the twenties), but isn't on that list.
<vagrantc>oriansj: rather, they are all clear, local, ci bordeaux all have the same hash. but i don't know what /gnu/store/HASH-... and the nar hash and the derivation hash ... those are getting confused in my wetware
<nckx><Not happy> Did I say that with those words? Possible, but I don't remember that.
<nckx>sneek is: a C++ bot with some personality written as a Guile extension, maintained for #guile, by someone who isn't active here. It's not the Guix-optimised, Guix-maintained #guix channel bot that many people think it is. That's all.
<nckx>Actually: can you git clone guix again, then run all your bootstrap & build commands, up to and including the reconfigure output? Then I can check exactly what you're running, maybe even reproduce it.
<char[m]>I did git reset hard master and git clean -xf
<leg7[m]><oriansj> "I just wish I knew how to have..." <- I think crypsetup luksFlush does the trick
<GNUmer>Despite declaring the resolutions with the xorg-configuration statement, GNOME still declines to awknowledge my resolutions. It still sticks to 1024x768. How can I tell the Radeon driver (or GNOME) to use 1080p as the display resolution?
<nckx>netdump is interesting! I'd never heard of it before, but that's probably because it looks Fedora-specific & unmaintained.
<nckx>I find it hard to imagine someone capable of debugging a kernel panic simultaneously unable to set up kexec, though. A readymade crashkernel service would make it more convenient, but is certainly not required.
<gabber>(how) can i make cuirass build all things (system configurations, home profiles, manifests)?
<gabber>better question: where can i find an example for the (custom list) build specification for cuirass?
<vagrantc>huh. i swear i've basically done ... guix pull --url=/home/someotherusernotme/src/guix --branch=master before ... but it's erroring out complaining of "guix pull: error: Git error config value 'safe.directory' was not found