Hello everyone, I didn't want to derail the conversation too much in the GCD 008 PR, so let us discuss the details here. Thank you Thanos and Hugo for sharing with us the ways you guys have been using LLMs.
Here are the concrete tasks I think that are not feasible by existing tools for which LLMs have been sought for: ```org * Build Failures - Compiler Failures - Missing packages - Problematic flags (test, arch, etc.) - Package requires path to binaries as variables (cf. emacs-elfeed) * Build Phase Issues - Changes to existing phase(s) - Requires new simple phase(s) - Complicated phases such as subtituting ENV variables, config etc. * Patch Coordination with upstream ``` This list is of course not exhaustive yet, please remind me what other kinds of issues we fall into, and an example commit or package definition would be great. One immediate free improvement we can get is to "autonomously" have a bot decide when the build failure is because of a dependency change and requires upgrade and then it should automatically call `guix refresh` for that and prepare the patch properly. This should not be _that_ difficult. Regarding compiler failures, the ones that are straightforward such as the one that Thanos' bot did for GCC14, can be also automated by parsing properly the output of the compiler. In that case, it missed -Wno-error=array-bounds flag, a simple bot can parse through the compiler output, check for which flags are missing and suggest to add them to (arguments) in the package definition. Let us try to find out such issues where we know statically what is wrong and that is provided to us by the compiler, environment variables, etc. and see what we can do with them. Regards, -- Divya Ranjan Pattanaik, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
