Vincent, Thank you! This list is for general Guix discussion. Although that can sometimes include rough patches (heh), please send any future contributions to our patch tracker at guix-patches@gnu.org — after carefully reading the ‘Submitting Patches’ section of the Guix manual. Vincent Legoll 写道: > * gnu/packages/version-control.scm (cgit)[native-inputs]: New > field. This is no new field. Neither are those of mailutils, iwd, or graphviz! Please rewrite all commit messages as either * gnu/packages/version-control.scm (cgit)[inputs]: Move groff & python-docutils from here… [native-inputs]: …to this new field. or * gnu/packages/version-control.scm (cgit)[inputs]: Move groff & python-docutils from here… [native-inputs]: …to here. although to be honest, I only ever use the latter format unless I'm feeling particularly pedantic. > [inputs]: Move groff & python-docutils to native-inputs. If we run $ guix gc --references `guix build cgit` we can see that both groff and python-docutils are part of cgit's closure. This means they must to be able to run… at run time :-o Oh dear. python-docutils's ‘rst2html.py’ is required by cgit's /lib/cgit/filters/html-converters/rst2html, and groff itself by cgit's /lib/cgit/filters/html-converters/man2html. Both of these uses look legitimate to me: they weren't accidentally captured by a stray environment variable or overzealous wrapper. Now, it's still possible that either or both of these dependents must *also* run at build time, and for that they would need to be native indeed. Unfortunately: $ guix build cgit --target=mips64el-linux-gnu guix build: error: gnu/packages/python-xyz.scm:2950:2: python-docutils@0.16: build system `python' does not support cross builds I could ignore that and pretend that all Python packages are safely architecture-independent (they're not) to continue investigating, but I'm out of time. I don't think this particular patch adds any value at this time, so let's drop it. The rest LGTM! Kind regards, T G-R