Rust November 2024

rust@lists.fedoraproject.org

4 participants
3 discussions

How to package Rust bindings for Tree-sitter parsers?
by Peter Oliver 01 Dec '24

01 Dec '24

TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently (using the usual Rust packaging process), or should they be a subpackage of the main Tree-sitter parser package (effectively giving us Rust bindings for free, but not using rust2rpm, etc.)? Here’s the long version. Tree-sitter is a library for writing parsers for source code, for use in, for example, syntax highlighters and text editors. Nearly 500 different parsers are available separately (https://github.com/tree-sitter/tree-sitter/wiki/List-of-parsers) However, we only have one of them packaged for Fedora so far, with Rust bindings proposed for one more (https://bugzilla.redhat.com/show_bug.cgi?id=2318053) Spec files for Tree-sitter parsers will all be very similar to each other, and could probably be generated by simple-minded RPM macros (a draft of which are at https://src.fedoraproject.org/rpms/tree-sitter/pull-request/1#request_diff) Official bindings are available for using the parsers from a number of languages, including Rust. The Tree-sitter project has tooling to automatically generate these bindings, which are committed to the Git repository of each parser. On release, the bindings are uploaded to the native repository for each language (i.e., crates.io for Rust). This gives us a choice: - We could treat Rust bindings for Tree-sitter as any other crate, with the souce fetched from crates.io. If someone wanted them, they would need to package them in the usual Rust way. - We could package Rust bindings for Tree-sitter as a subpackage of the package that builds the parser as a C library, with the source fetched from github.com. We would have Rust bindings for every Tree-sitter parser packaged for Fedora. The Tree-sitter-specific RPM macros used in these packages may need tweaking in future to keep up with any changes to the Rust packaging guidelines. Which sounds preferable? By the way, I have asked this question on the packaging list (https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject…) but it didn’t generate much discussion. I will also ask the equivalent question on the Python list. -- Peter Oliver

2 2

Firecracker 1.10 crate updates
by David Michael 21 Nov '24

21 Nov '24

Hi, The Firecracker 1.10 release branch was forked a few hours ago, and these are its crate updates not in Fedora by maintainer: decathorpe: proc-macro2-1.0.89 serde_json-1.0.132 zerocopy-0.8.7 (API update) slp: kvm-bindings-0.10.0 (API update) kvm-ioctls-0.19.0 (API update) vhost-0.12.1 (API update) vm-memory-0.16.0 (API update) They committed a release date saying it will be out tomorrow. Let me know if you want me to handle any of these updates. I could take care of the kvm-bindings and kvm-ioctls updates, but I'll need access for others. (Note the vhost/vm-memory updates affect six vhost-* and virtio-* crates.) Also if I should do the kvm-* updates and there are no objections, I'll regenerate them using rust2rpm's supported arches for x86_64/aarch64/riscv64 since riscv64 was added to a lot of the VMM infrastructure crates. The vm-memory update has also added riscv64 support. Thanks. David

3 11

Re: Orphaning eza (rust-eza - maintained fork of exa)
by Fabio Valentini 05 Nov '24

05 Nov '24

On Tue, Nov 5, 2024 at 9:33 PM Arthur Bols <arthur(a)bols.dev> wrote: > > Hi Fabio, > > On 31/10/2024 19:38, Fabio Valentini wrote: > > Hi all, > > TL;DR: I am planning to orphan rust-eza later today. Be warned - it's > a lot of work to keep up with upstream (~1 release per week), keeping > it up-to-date in epel8 is a bit painful (because RHEL 8, duh), and > there are license shenanigans afoot since the v0.20.0 release (package > is currently at v0.19.3). > > Given that I don't even use eza myself and just packaged it because it > was on some people's wishlist as the maintained fork of exa, I really > cannot justify the ongoing cost of maintaining this package to myself. > > I'm interested in maintaining eza since I use it on multiple systems. I'm a bit hesitant, though. First, I won't have time to keep up with every upstream release, but I'll do my best to keep it updated. Also, because of the large dependency tree, I think joining the rust-sig would be helpful so I can update dependencies as needed (and of course, I'll try to help others out where I can). Finally, my experience with Rust is limited, but I am quite familiar with the packaging process. Well .. I guess it depends on how much time you can invest into this? And if you want to deal with the licensing mess mentioned below? :) > Do you think this is a good idea or would it be better to leave it for someone else? > > It might be of note that the project was relicenced from MIT to > EUPL-1.2 without much fanfare as of the 0.20.0 release, in this > mess-of-a-PR: https://github.com/eza-community/eza/pull/1155 - I'm not > a lawyer, but the maintainer unilaterally slapping a different license > onto a project that's been around since 2017 in some form without > asking other contributors (or the original author of exa) doesn't pass > the smell test for me. > > Seriously... https://github.com/eza-community/eza/releases/tag/v0.20.0 > The PR mentions dual-licensing, but it's now a mess of only MIT, MIT or EUPL-1.2, and only EUPL-1.2... Yes. I wasn't joking when I said it was a mess-of-a-PR :) That mess alone would make me hesitant to want to continue maintaining (or using) this project. :( Fabio

1 0

2024

2023

2022

2021

2020

2019

2018

2017

Rust November 2024