<xelxebar>Check out guix/build-system/cmake.scm. That's the "official documentation" as far as I can tell :P
<xelxebar>Around line 126, you can see a list of keyword args. Looks like #:configure-flags and #:make-flags might be helpful?
<kittyblam>excuse my unfamiliarity, while technically using guix for a while now I never delved in much, how do I find/open cmake.scm? xD
<xelxebar>I'm not that familiar with CMake, but it looks like there's a CMAKE_C_FLAGS macro it uses? At worst, you could try adding a pre-build phase that just does (setenv "CFLAGS" "...")
<xelxebar>kittyblam: Oh, cmake.scm is in the guix repo: git://git.savannah.gnu.org/guix.git
<xelxebar>FWIW, The gnu/packages/ directory contains package definitions and is a gold mine of information when first learning how to write package defs. I've shamelessly mined it countless times.
<kittyblam>ah finally downloaded and figured out how to get to the cmake.scm
<kittyblam>also may or may not have gotten distracted reading other files in this lmao
<kittyblam>xelxebar: yeah I do notice in graphics.scm blender (which, while it does not include yafaray, both deal with rendering and openexr etc.) does appear to have something kinda like that setenv junk
<kittyblam>I'm going to take a quick break, one momento uwu
<xelxebar>Cool. Hope that gets gets you running :D
<kittyblam>btw I wantn to mention that I got it working I believe, although I don't have an XML to feed the 3d rendering engine to confirm as a sanity check it did appear to build just fine and show up in my terminal uwu, next step after a sanity check will be packaging the GUI version then I guess looking into how I could clean it up and how commiting this stuff works lmao
<rekado_>the python-notebook tests relating to deletion also fail outside of the build container.
<rekado_>I haven’t been able to reproduce problems with python-send2trash directly. It works just fine on its own.
<jpoiret>shebangs are a kernel feature, they just recognize the #! at the beginning and use the command line until a newline is encountered. The scheme block command is to make scheme ignore it, but you don't want the !# to end up in the command line
<jpoiret>well your approach of using guix to setup emacs and then launching emacs through it is better imo
<jpoiret>then you can just (require ...) in your init
<M6piz7wk[m]>i changed that approach to make it more flexible so now i am using guix to provide emacs and then i am doing `default.el` file in the root of the repo that is loaded through `emacs -q -l default.el` that i expect to make a call to guix to provide the desired packages
<jpoiret>you don't need to call guix from inside emacs
<jpoiret>rather, you can do `guix shell -m ./emacs-manifest.scm -- emacs -q -l init.el`
<M6piz7wk[m]>i do as i want emacs to decide which package manager it wants to use e.g. if guix is available then use guix else fallback to MELPA
<M6piz7wk[m]>so that this way it can also implement nixos and others as needed
<M6piz7wk[m]>and also for it to not fail when guix is not available
<jpoiret>i mean, it isn't impossible to do at all, just that no one else has written it yet
<jpoiret>the thing is, to have it work across melpa and guix at the same time, you'd need to have both the melpa and guix name (they might differ)
<M6piz7wk[m]>hm O.o so like can i just do `(shell-command "guix shell -m path/to/manifest.scm")` and expect it to work that way?
<M6piz7wk[m]>or will that just create an environment that is not reachable to emacs
<jpoiret>nono, you have to launch emacs inside the shell
<jpoiret>otherwise yes that will create and env that is not reachable to emacs
<jpoiret>i'd say for now, you can add a check for a guix shell at the beginning of your init and disable the package manager (do you use use-package?)
<M6piz7wk[m]>so that it decides the check for package manager prior to invoking emacs
<jpoiret>ehhhhhhh, not sure if this should be the responsibility of cargo imo, but your call
<M6piz7wk[m]>ehh i meant that i use cargo-make to manage the repo (i don't use cargo just the project that is named that way) to make the project call to check the package manager and install the packages
<M6piz7wk[m]>and then open emacs with the packages already installed?
<brendyn>M6piz7wk[m], I would like to implement a straight.el backend to use guix packages for emacs
<jpoiret>not installed, only present in the env through a shell, but yes (that might be what you said)
<M6piz7wk[m]>so like `makers emacs -> package manager check -> Install packages and emacs -> launch emacs with the packages and load the default.el`
<jpoiret>brendyn: you mean use-package backend, right?
<brendyn>maybe. i dont actually understand it in depth. Doom uses straight so i was looking at that
<jpoiret>oh, no, okay, i see what you mean. It won't use the guix package definitions though then
<jpoiret>but yes you could translate straight recipes to guix package i think
<brendyn>it will, but for example you could inherit the guix package definiton, but using the commit specified for example
<jpoiret>but how do you tell by the straight recipe which already existing package definition it corresponds to?
<M6piz7wk[m]>is there any standardized extension for manifest.scm files?
<M6piz7wk[m]>i have one that provides emacs and second that provides extensions to emacs
<jpoiret>civodul: while you're here, sorry for the 2 patches about the installer, I noticed a typo in a variable name right as I sent it. I tested the second patch in a VM and it worked properly (installer worked, and tested the function manually). git send-email ate most of what i wrote in the v2 patch mail
<florhizome[m]>but does roll–back even set back my guix to a previous commit or just the composition of my packages?
<florhizome[m]>Since I’m doing profiles the packages in my „main–profile“ have become pretty arbitrary anyways
<jpoiret>if you want to rollback guix itself you need to use `guix pull --list-generations/--switch-generation`
<jpoiret>and you can use guix pull --commit= if you just want to use an old commit
<florhizome[m]>ah, pretty sure it was civoduls last guix home commit, it touches on-first-login. "sneek: later tell civodul" ?
<M6piz7wk[m]>how does guix know that it should be looking for packages in `pkgs/something.scm` ?
<efraim>florhizome[m]: I think I found a fix, give me a bit to check it
<jlicht>M6piz7wk[m]: I believe (by default) everything that is both exported and not a hidden package is found by fold-packages; see %package-module-path in gnu/packages.scm for the implementation details
<singpolyma>Ok. I would suggest given how guix shell works that you make the "main" package in a file not a variable and name the file guix.scm if you plan to keep this as a one-off out-of-tree package
<M6piz7wk[m]>rather want to define a template out of it to develop packages from it
<singpolyma>Packages that will go into guix as patches, or into a channel, or you will keep just seperately?
<M6piz7wk[m]>so ideally a thing that can be defined as a channel on demand
<vivien>So, what is the plan for at-spi2-core on core-updates-frozen?
*M6piz7wk[m] is getting flustrated by the lack of information on guile and guix >.<
<singpolyma>M6piz7wk[m]: if you do it in an out of tree module that will be the easiest cut-paste, but if you intend them to go in eventually using branches of the actual guix git will probably save you work
<jlicht>this is above my paygrade ;). You can use qemu-binfmt on guix to build and run stuff for other architectures. I'm not saying it always works, but it seems less complicated than adding several other tools
<roptat>M6piz7wk[m], evaluating this scheme file results in #<unspecified> because the last expression is a (define-public ...). You want to return a package object instead, which you can do by adding my-package in a single line at the end
<podiki[m]>did the CI run out of space a week ago? bunch of (i686) builds failed due to space and looks like were never re-attempted (e.g. tevent, groff)
<roptat>yes, you'd need to run make on the repo and use ./pre-inst-env
<podiki[m]>so a good chunk of i686 is not built, wasn't sure if the rust/svg/pixbuf was sorted or not on i686 (core-updates-frozen)
<M6piz7wk[m]>podiki[m]: from what i captured someone broke it and it's nowreverted?
<roptat>zimoun, maybe missing some variables? are you using the ocaml- or dune-build-system?
<M6piz7wk[m]>roptat: so i have to build guix each time i want to test a new definition?
<apteryx>podiki[m]: due to polkit I guess; we were discussing using polkit-duktape instead of polkit on rustless archs
<apteryx>I'm not too sure if we can make the package conditional; need experimenting
<zimoun>roptat, none. gnu-build-system. It is a Coq package.
<roptat>M6piz7wk[m], mh, put it that way it sounds expensive, I dunno. I'm just used to it and do it all the time, so I don't really see the cost. Once you built the repo once, you can make changes and run ./pre-inst-env immediately. You don't have to build everything all the time
<zimoun>roptat, indeed. Something was wrong. Thanks!
<vivien>Is there a plan to fix the propagation of at-spi2-core in core-updates-frozen? That’s a rather annoying issue :(
<civodul>vivien: what's the issue? that's when adding gnome to a profile, right?
<vivien>civodul, using the gnome-desktop-service-type puts gnome into the profile, which widely propagates stuff and at the end of the day I can’t reconfigure my system.
<podiki[m]>I was also going to finally guix pull on my older core-updates-frozen guix..... (but I don't use gnome)
<apteryx>vivien: could you remind us what how the issue manifest itself? a clash of at-spi2-core and at-spi2-core-minimal in the same profile (propagated by different packages in the closure of the GNOME meta package?
<apteryx>the minimal variant was introduced to break a cycle betweek GTK+ and Inkskape 1 in 2a92a2bc18ff1a95f507388c09d110715c2a507a
<M6piz7wk[m]>is there any better emacs terminal that works with this environment? the default one is keep breaking lines and doesn't do a good job
<tissevert>actually it's a bit weird, because when you "guix shell -D guix", you ask your currently installed guix to prepare an environment containing the packages needed to develop… the guix package (as it is known by your current version of guix ! it has no link whatsoever with the current copy you happen to have in the current folder: you could run that command in any folder on your machine)
<tissevert>it just so happens that this development environment is suitable to… build what is in the current folder, since it's the same software (except for the version)
<nckx>apteryx: I asked you what you meant by ‘that was a feature of Xorg’, because me no grokky, but that never arrived because my wi-fi card stopped working. So I rebooted. Paste (both via ‘the clipboard’ and ‘the primary selection’) works fine now.
<jpoiret>currently, warnings in sanitizers of guix records have their source location correspond to the beginning of the record definition, rather than the field it's attached to. My macro-foo is very lacking, but does anyone think we could remedy this?
<M6piz7wk[m]>oh `mytuple = ("apple", "banana", "cherry")` i remember that xD
<jpoiret>I don't exactly know how macros interact with current-source-location though
*M6piz7wk[m] waits for kind person to build rust-info on 1.52.2 rustlang to confirm it builds
<jpoiret>M6piz7wk[m]: doesn't it work with the #:rust keyword?
<nckx>Guix's implementation/approximation/toxic containment of the Rust build system is special compared to other Guix packages. All dependencies are built ‘at once’, not individually like you can with C^Wsane packages. The upshot is you have to add #:rust to the final package, not some intermediate, even if the intermediate fails.
<jpoiret>back to what I was saying: turns out that with some macro shenanigans, you can actually report the error with the location of the incriminating value, rather than the whole guix record definition!
<vivien>openssl provides an openssl pkg-config definition
<yewscion>Hello all, quick question: Is there a trick to getting commands working with guix? I'm apparently unable to locate git-receive-pack (or indeed any of the git utilities) through SSH on my remote machine, but I can once I have SSH'd in.
<yewscion>M6piz7wk[m]: Hmm, it's interesting. I've used this setup on other distros in the past, so I'm sure that the Guix setup is the issue. When You say "the session doesn't have those", is it an environment variable that is unset (or something similar)?
<yewscion>running `ssh user@server env` works, and so does `ssh user@server env bash`, but `ssh user@server git-receive-pack` still doesn't work.
<yewscion>It does seem like the bash used by SSH in this instance is at fault here. Maybe there is something I need to learn about SSH, so that I can better integrate it with Guix.
<M6piz7wk[m]>Dunno x.x but it looks like an environment without imported derivations to me
<jlicht>yewscion: is the remote machine a guix system? Or a binary guix on a different distro?
<yewscion>jlicht: It's Guix System, running on linode.
<yewscion>I've just noticed that SSH /can/ find git if I use my user account, instead of the `git` user I'd created for this purpose. The main difference in my user declaration for git was the `(system? #t)` call; Does that prevent some Guix-specific setup for this situation?