packaging

packaging@lists.fedoraproject.org

2892 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

laurel (take 2)
by Oden Eriksson 26 Nov '24

26 Nov '24

Hello, I wonder if someone would like to adopt my laurel package for inclusion in Fedora and EPEL? https://repo.nux.se/laurel/ https://repo.nux.se/laurel/laurel-0.6.3-6.fc41.src.rpm Some work has been done this week to make it build on RHEL 7, 8 & 9. Should build on Fedora as well but will need proper conditional macros. -- Regards // The penguin whisperer

1 1

Re: [EPEL-devel] Re: Packaging a systemd unit in EPEL
by Dominik 'Rathann' Mierzejewski 20 Nov '24

20 Nov '24

On Tuesday, 19 November 2024 at 16:17, Stephen Smoogen wrote: > On Mon, 18 Nov 2024 at 18:26, Brian Stinson <bstinson(a)redhat.com> wrote: > > > Hey Folks, > > > > I have a goal to get Kepler installable from EPEL but I’m wondering about > > some guidelines here. Upstream is only producing a container, and their > > RPMs simply install a systemd unit that pulls their container from quay.io > > <http://quay.io/> > > > > > I am guessing you are meaning https://sustainable-computing.io/ or > something similar which is a prometheus plugin. Going from my recent > attempts at working this.. making it into an RPM will need a strong > familiarity with the Golang packaging guidelines and a strong stomach for > dealing with vendor-the-universe-to-get-a-2-line-code-snippet. It also > looks like it needs eBPF and some other items for the kernel space. > > I don't have much input outside of that.. my initial take is that it is a > tall ask to get it into EPEL so good luck Apart from the number of Golang deps, it doesn't seem too onerous. They even have a Makefile target to build just the binary and a spec file: https://github.com/sustainable-computing-io/kepler/blob/main/packaging/rpm/… Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan

1 0

Packaging a systemd unit in EPEL
by Brian Stinson 19 Nov '24

19 Nov '24

Hey Folks, I have a goal to get Kepler installable from EPEL but I’m wondering about some guidelines here. Upstream is only producing a container, and their RPMs simply install a systemd unit that pulls their container from quay.io <http://quay.io/> There are a few other services that we may want to consider shipping this way in the future, do we need any special consideration for things like this? —Brian

3 2

Re: A tool to convert Python packages to pyproject RPM macros
by Miro Hrončok 12 Oct '24

12 Oct '24

On 12. 10. 24 0:32, Adam Williamson wrote: > On Fri, 2024-10-11 at 21:29 +0200, Michal Ambroz wrote: >> Hello Miro, >> Thank you very much for the tool - I am adding it to toolbox. >> >> >> >> I actually love the new pyproject macros, but in the past there were some >> discrepancies between >> Fedora and EPEL where not everywhere the situation was ready there to switch >> to pyproject macros. >> Please have you checked recently how EPEL8-9-10 is doing with the Fedora >> pyproject macros? >> Does it make sense to switch over for all current EPELs? > > EPEL 8 can't use them. EPEL 9+ can. This is mentioned at the top of > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ . > > On the whole I'd say it makes sense to use pyproject on all other > branches and have EPEL 8 use the old guidelines, in most cases. You > *probably* don't want to keep an EPEL 8 branch in sync with Rawhide > anyway, we're not supposed to do major version bumps and stuff in EPEL. Pretty much what Adam said. Some details: Python 3.6 in RHEL 8 is probably too old to handle the Python code in pyproject-rpm-macros. This could be fixed by changes in that code of it was the only problem (it isn't). pip 9 in RHEL 8 is too old to support pyproject-based builds. pips for newer Python versions in RHEL 8 are more capable. setuptools 39.2 in RHEL 8 is too old to provide the (default) setuptools.build_meta:__legacy__ backend. setuptools for newer Python versions in RHEL 8 are more capable. RPM 4.14 in RHEL 8 is too old to understand %generate_buildrequires. There is a EPEL 8 version of the pyproject-rpm-macros package, but it is severly limited because of this. tl;dr RHEL 8 is very old. it predates the fundamental principles those macros were build on. Python packaging has evolved in the past 6 years almost beyond recognition. RHEL 8 is too old to catch up. We are at a point where we can no longer build Python RPM packages for EPEL 8 and Fedora form the same spec file, unless we fill it with %if conditionals. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging