<mark_weaver>although we generally recommend installing the 'gcc-toolchain' package instead, which includes gcc, binutils, glibc, and something called ld-wrapper that automatically adds rpaths so that the built executables can find the shared libraries they were linked with
<mark_weaver>rekado-: well, here's another idea: move the entire quasi-quoted 'arguments' value to the body of a new top-level procedure that takes the version as an argument. and then call that procedure from both package recipes.
<mark_weaver>also, while you're at it, please wrap that 'substitute*' within a 'let' that binds (string-append (assoc-ref %outputs "out") "/lib/ardour" ,major-version) "/") to some variable, and use that.
<mark_weaver>the backlight keys worked on my Libreboot X60 because on that machine libreboot adjusted the brightness itself, rather than reporting the keypresses to userland. at least in the version of libreboot I was using at the time.
<davexunit>so, I know that one can specify a directory as a package's source field, but is there any way to control precisely what files in that directory should be included?
<davexunit>the use case I have in mind is testing package builds from a project's git repo.
<davexunit>my guile projects have a 'package.scm' file in the root of the source tree that I use for 'guix environment', but I also want them to be buildable packages.
<mark_weaver>davexunit: you could use a snippet to remove the files you don't want
<mark_weaver>(or to remove everything but the files you explicitly want)
<mark_weaver>davexunit: although in the git repo case there's a better way. use the 'git-fetch' method and use a file url pointing to your local repo.
<mark_weaver>although I guess it's a pain to have to provide the hash for that.
<mark_weaver>but you can just run it and then take the hash from the error message :)
<mark_weaver>perhaps we should have something to make this easier, dunno.
<mark_weaver>I guess you could write a procedure that takes the directory name and a specification of what files you want, and produces a package object that uses trivial-build-system to copy just those files to the output. then you could use that in the source field.
<mark_weaver>fixed-output derivations are the only ones that have access to files outside of the store, so they are the only way you can create the trimmed source without importing the entire git repo into the store
<mark_weaver>well, I suppose the simplest way would be to write some code that copies the desired source files to a temporary directory, and then import that directory into the store
<mark_weaver>that copy operation would be repeated every time, unfortunately
<mark_weaver>the more efficient method would do the equivalent of "guix hash -r", but looking only at the files you want to keep
<mark_weaver>otherwise the entire .git directory will be imported, and presumably fresh hashes will be generated for all dependent builds whenever the git repo state changes at all, even if the checked out files haven't changed.
<civodul>actually, there's a basic filter mechanism on the daemon side, for add-to-store
<davexunit>civodul: adding each file to the store sounds wasteful, but maybe it's okay.
<davexunit>there could easily be hundreds of files depending on the project.
<davexunit>adding all of the guix source files to the store, for example.
<mark_weaver>the best idea I could come up with was this: dynamically compute the hash of the fixed-output-derivation by doing the equivalent of "guix hash -r" on the git checkout but ignoring any file that's not part of the git repo, and then having the fixed-output-derivation copy the git-handled files to a fresh store directory.
<mark_weaver>that suggests to me that 'git-fetch' derivations can access my home directory, or at least the world-readable parts.
<mark_weaver>so, here's the hack I envision: make a procedure that dynamically generates a fixed-output derivation to do this, by first computing the hash that the output will have, by doing the equivalent of "guix hash -r" except on selected files only
<mark_weaver>and then within the fixed-output derivation, it simply copies those selected files to the output directory
<mark_weaver>in this case, the selected files would be the files that are actually part of the git repo, using "git ls-files"
<mark_weaver>adding another layer, as we do in /var/log/guix/drvs for example, has another problem: it adds one more level of indirection for every file lookup that ends up in the store, and actually more than one because in practice there are multiple layers of symlinks that traverse into the store repeatedly