https://bugzilla.redhat.com/show_bug.cgi?id=2246561 --- Comment #11 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to blinxen from comment #10) > > > I will look into this and create a PR upstream. > > > Great, thanks! > > Here is the PR --> https://github.com/helix-editor/helix/pull/8684 Thanks! > I assume I have to install the license files for the themes too. Is that > correct? Yes. The themes are getting installed, so the associated license file(s) should get installed too. > > I just did a spot-check, and the lexicographically first one already doesn't contain a license file (tree-sitter-astro, in runtime/grammars/sources/astro). There are others that are missing license files as well. > > I did some python magic and got the following list of grammars that don't > have a license file. > > ``` > sql > llvm > eex > clojure > twig > forth > comment > vala > beancount > uxntal > ungrammar > purescript > vhs > perl > hare > astro > pod > lean > unison > smithy > rego > ``` > > Some of these do have LICENSE files but the commit that is used in > `languages.toml` does not have it --> They (the license files) were added in > a later commit. Besides adding "bundled(...) = ..", do I also have to > install the license files for the grammars? These projects are bundled and get build + shipped by the helix package, so yes, I think so. You might need to rename the files to avoid name clashes with the %license macro. For example, do something like "cp -p runtime/grammars/foo/LICENSE -> LICENSE-tree-sitter-foo" for all grammar modules, and then do "%license LICENSE-tree-sitter-*" in %files. > > I think I know what's happening. Those grammars are built as C objects by the helix build scripts, not as Rust projects. So the dependencies specified in Cargo.toml don't even factor into it, from what I can tell. It also looks like the "tree-sitter-afl-fuzzer" (the only crate that has more than just the "tree-sitter" crate dependency) is not an actual tree-sitter grammar, but a subproject of the SSH client configuration grammar, so it isn't used at all. > > That sounds about right, here is the answer from upstream: > > ``` > Yes helix does not require tree sitter whole building grammar it just > invokes the c compiler. I need to check tough some headers may be needed but > I am not sure about that. > > For a package manager I would generally recommend to invoke the c compiler > yourself to properly handle cross compilation and make sure all flags are > respected (the sourcecode for every grammsr is provided in the source > archive of every release). > I don't think tree sitter versions matter much for the grammars. Tbh I > didn't even know they could specify a specific TS version (grammars are just > one or Teo c source files that my or may not be auto generated). > A slight tangent: Some distros (like alpine) ship the grammars as separate > packages and share them across editors like nvim. > Whole this may seem attractive in theory it's incompatible with the reality > of TS. The queries that ship with the editor are specific to one specific > version of the grammar and will (sometimes subtley) break when used with a > different version. Helix should only be packaged with the exact grammar > commits that we pine d in our languages.toml/ship in the source archive > ``` Sounds about right to me. That makes it even more clear that packaging all the tree-sitter grammars separately is unrealistic. :) -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2246561 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202246561%23c11 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
