packaging December 2024

packaging@lists.fedoraproject.org

7 participants
6 discussions

Packaging Tree-sitter parsers
by Peter Oliver 18 Dec '24

18 Dec '24

I have a couple of questions regarding packaging Tree-sitter parsers for Fedora. Some background. 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. Official bindings are available for using the parsers from a number of languages (https://tree-sitter.github.io/tree-sitter/#language-bindings) 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, pypi.org for Python, etc.). First question. Should we be building all bindings we care about for a parser from a single SRPM (using the upstream source code), rather than making a bunch of duplicate SRPMs (one for each language, from the language-specific releases)? I think a single SRPM per parser makes more sense, but it does have the drawback of making the .spec files more complicated, and prevents us from generating them with, say, rust2rpm. This brings me to my second question. Spec files for different Tree-sitter parsers are pretty-much identical to each other, so should we generate them using macros? I’ve put together some draft macros (https://src.fedoraproject.org/rpms/tree-sitter/pull-request/1#request_diff) and built them into a tree-sitter-srpm-macros package (https://copr.fedorainfracloud.org/coprs/mavit/tree-sitter/) Here is an example complete spec file using these macros: ``` Name: tree-sitter-c Version: 0.21.4 Release: %autorelease License: MIT URL: https://github.com/tree-sitter/%{name} Source: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz BuildSystem: treesitter %{treesitter -l C} %changelog %autochangelog ``` I’m sure the macros are in need of review, but does this seem like a generally good approach? -- Peter Oliver

2 3

Re: Forming a lightweight SIG around MkDocs
by Michel Lind 18 Dec '24

18 Dec '24

On Wed, Dec 18, 2024 at 12:55:07PM +0000, Davide Cavalca wrote: > MkDocs (https://www.mkdocs.org/) is a Markdown-based website maker, geared > towards technical documentation. The CentOS Project has historically used > MkDocs for SIG documentation, and the CentOS Docs SIG has recently > standardized on MkDocs for the overall project, leading to the creation of a > collated documentation site at https://docs.centos.org (sources: > https://gitlab.com/CentOS/docs/docs.centos.org) > > To ease this work, I've been working on getting the MkDocs stack back in > shape in Fedora, with the goal of eventually branching it for EPEL 10. > Because MkDocs is quite sprawling, I'd like to setup a lightweight SIG > around it to ease package maintenance of the stack. By "lightweight" I mean > that I expect this will mostly be used for package ACLs and bug triage. > While I mostly expect folks from the CentOS Docs SIG to join in, this is by > all means open to anybody interested in collaborating. > For completeness, this is the infra request https://pagure.io/fedora-infrastructure/issue/12337 cc Packaging group to see if we should consider making the process of creating a new SIG better documented FESCo has a policy document on specific SIGs' rules https://docs.fedoraproject.org/en-US/fesco/SIG_policy/ but the only document I see for creating a SIG is still only a wiki page https://fedoraproject.org/wiki/Creating_a_Fedora_SIG Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

1 0

Re: F42 libtimezone unannounced removal
by Michel Lind 18 Dec '24

18 Dec '24

On Wed, Dec 18, 2024 at 03:08:25PM -0000, Leigh Scott wrote: > Please readd libtimezone for f42 and give me ownership. > > https://bugzilla.redhat.com/show_bug.cgi?id=2333021 > > https://src.fedoraproject.org/rpms/libtimezonemap/c/3e1e20e5d49c4a3b144f8fb… Indeed, this is actually used by cinnamon $ fedrq whatrequires 'libtimezonemap*' cinnamon-6.4.2-2.fc42.x86_64 $ fedrq whatrequires 'libtimezonemap*' -b f41 cinnamon-6.2.9-1.fc41.x86_64 libtimezonemap-devel-0.4.5.3-2.fc41.i686 libtimezonemap-devel-0.4.5.3-2.fc41.x86_64 cc-ing the packaging list - I notice the retirement process currently does not really mention any requirement to check for affected packages / to provide heads-up, which is a bit surprising since we do that (implicitly) for updating packages at least in stable releases. https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement… Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

1 0

Conditional expansion of source name
by Mattia Verga 15 Dec '24

15 Dec '24

How can I define a source name so that if I set %global prerelease beta1 the source name will expand to something like pkgname-{version}.beta1 or with %global prerelease %{nil} will just be pkgname-{version} (without the ending dot)? I tried with pkgname-{version}{?prerelease:%{expand:.?{prerelease}}} but that's clearly wrong as it's not working... And, yes, I need prerelease to be just "beta1" and not ".beta1" because I need it in other parts of specfile.

2 1

IMA Key Verification
by Isaiah Inuwa 11 Dec '24

11 Dec '24

I am interested in verifying files from packages installed from Fedora's repos. (For context this is related to determining allowed origins for various applications using a new WebAuthn API.) Are there any further docs on verifying signatures? From the Bugzilla linked in https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents, it looks like you need to install rpm-plugin-ima, and then reinstall any packages so that the signatures are written to the locally installed files. The spec page mentions IMA keys being published on the Fedora security page, but only GPG keys are listed. Are those the same keys used to generate the IMA signatures? Thanks for your help, Isaiah Inuwa

4 3

Guidelines changes workflow
by Remi Collet 06 Dec '24

06 Dec '24

Hi, How FPC is now handling Guidelines changes ? I submit a proposal nearly 2 months ago about PHP without any feedback https://pagure.io/packaging-committee/issue/1401 Remi

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging December 2024