packaging November 2024

packaging@lists.fedoraproject.org

9 participants
5 discussions

IMA Key Verification
by Isaiah Inuwa 29 Nov '24

29 Nov '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

3 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

Packaging Tree-sitter parsers
by Peter Oliver 06 Nov '24

06 Nov '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 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging November 2024