<mbakke>rekado_: I've been working on a TeX Live upgrade and could use a sanity check. For 'mit-scheme', I had to add kpathsea to its texlive-union, and also patch shebangs in the texlive-union procedure. Does that seem reasonable?
<mbakke>maybe kpathsea should be in 'texlive-base' instead
<katco>any stumpwm users having issues after the recent common-lisp build system work? any stumpwm module which has `inputs` defined can't find said inputs when trying to load the module. in my config i'm doing this: `(set-module-dir "/run/current-system/profile/share/common-lisp/sbcl")`. if i instead do `(set-module-dir "/run/current-system/profile/lib/common-lisp/sbcl")`, it can't find the stumpwm modules at all (i think it needs the
<morgansmith>also there is a #:emacs flag specifcally for this but that also doesn't seem to work :/
<morgansmith>my current hypothesis is that there is something not right with the inheritance :/ I can use the #:emacs key to change the emacs in the build-input from an inherited package only if the original package also used the #:emacs key. I think the default has more authority than a key in an inherting package
<morgansmith>I'm thinking this because I can do it properly on the emacs-xelb package, but not emacs-org
<morgansmith>ok, I figured it out. It's just cuz no-one told me how to use substitute-keyword-arguments. I actually still don't really understand it. The docstring is quite short and it's not mentions in the manua.
<morgansmith>so why the heck do I need this double quoted empty list thing?
<apteryx>I won't have time to test it before later today.
<apteryx>feel free to merge it already if you are confident!
<morgansmith>is there a way for me to use substitute-keyword-arguments in a way so I can set a keyword if the package actually has that keyword (otherwise I crash) and always set it even if it's not already assigned to a value?
<cbaines>morgansmith, there's a distinction here between the keyword being present in the arguments, and the build system supporting that keyword argument
<cbaines>I'm not sure what you mean by crashing, but it sounds like you can do that through providing a default value
<morgansmith>it crashes on guix/build-system/gnu.scm 327 because the gnu build system really doesn't like being passed a #:emacs key
<morgansmith>I think I'll just put a little if statement that checks the build system of the package
<cbaines>checking upfront whether you're trying to make a appropriate modification seems the right way to go
<lfam>It does appear to have actually built some things, however, although I'm not sure in response to what. After a few days I noticed that no Rust compilers had been built, so cbaines logged in to berlin and built them "manually", and I can confirm I no longer have build them on the staging branch. But a large part of the ffmpeg dependency graph is still not built
<lfam>Let me know if you have any ideas for how I can help. I have time...
<cbaines>lfam, if you have a target derivation, I can ask for that to be built on berlin
<cbaines>I just checked on the rust stuff, and it build eventually
<lfam>The question is, does it correspond to substitute availability for users?
<cbaines>I'm not sure I follow your question, does what correspond to substitute availability?
<lfam>Using the interface at <data.guix-patches.cbaines.net>, I can compare build results between branches, at certain points in time. This comparison roughly corresponds to "compare particular commits" and is good enough. It can filter out build results in a useful way, like "show what broke".
<lfam>But, can I use to make a judgement about when a branch is "ready" to be merged?
<lfam>The relevant questions being, "did it try to build all the new derivations yet, and did an acceptable percentage of them succeed?"
<cbaines>So, when trying to reason about the result of merging one branch in to another, I'm a little wary of the novel things that this might lead to. Take a simple example of ruby being upgraded on core-updates and a Ruby gem being upgraded on master, if core-updates doesn't have that gem upgrade, then merging core-updates in to master will result in a package derivation that's unseen on either branch.
<cbaines>Informed with all that information, package substitute availability on master and staging, plus information on specific failing builds, I think the rest is up to someone to make an informed decision
<cbaines>I'd feel more comfortable leading people to it if I could give some information about how up to date the information is. Maybe I should just put something on the page saying "this information is probably not up to date"
<cbaines>But back to judging when a branch is ready to be merged, no blocking broken packages on that branch when compared to master, and a similar level of substitute availability seem OK criteria to me
<lfam>How can I edit the URL to get "package-substitute-availability" for a particular revision?
<ZombieChicken>Is there a guide for installing GuixSD onto the Pinebook Pro?
<ZombieChicken>I know there is/was some work on that, but I can't seem to find it atm
<lfam>Another question I have is about the compare-by-datetime timestamp format. When I put the wrong format, it tells me what the correct format is. It might be good to always show the required format next the input box
<cbaines>lfam, I think that's reasonable, would you like to try making that change? It's safe to just find the relevant strings and update them I think.
<lfam>What program is it? I'm not finding these strings in build-coordinator.git
<cbaines>lfam, wrong repository, you want data-service.git on Savannah
<lfam>Ah. I've been conflating the data service and the build coordinator