packaging

packaging@lists.fedoraproject.org

11 participants
2895 discussions

File and Directory Ownership and ShellCompletions
by Sérgio Basto 27 Mar '25

27 Mar '25

Hi, https://docs.fedoraproject.org/en-US/packaging-guidelines/ShellCompletions/ contradicts https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_direct… and https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectorie… But in this specific case is not to much own all sub-directories i.e. %files %dir %{_datadir}/zsh/ %dir %{_datadir}/zsh/site-functions/ %{_datadir}/zsh/site-functions/_%{name} shouldn't be enough ? %files %{_datadir}/zsh/site-functions -- Sérgio M. B.

4 3

Preferring a package for a provide when several are available
by Peter Oliver 20 Mar '25

20 Mar '25

Let’s say there are three packages, foo-a, foo-b, and foo-c, that each `Provides: foo`. If I `dnf install foo`, it seems that one of these is selected more-or-less at random (although I’m sure there’s more to it than that). Is there some agreed way of specifying that foo-a should be the default? Is it acceptable for foo-a to say, e.g., `Enhances: fedora-release-common` (or some other package that is sure to already be installed)? I found a discussion that touched on this at https://github.com/openSUSE/libsolv/issues/66, but no conclusions there.

5 6

Scriptlet to replace a directory can cause infinite loop in update
by Jarek Prokop 06 Mar '25

06 Mar '25

Hi, recently we were faced with a bug that caused an infinite loop in a container. It was from a package (node.js) retaining a scriptlet to replace a directory as recommended in Fedora Guidelines [0]. There the errno and reason returned [1] is effectively ignored. Only whether the operation succeed is checked. There is no differentiation whether the rename failed because the directory exists which will correctly cause a rename with a numerical index appended to the directory name. Or if the rename failed due to any of the other reasons we might consider as a fail where jumping out of a scriptlet is preferable to even attempting a rename. The next numerical index is found with a trial-and-error that runs in a loop until some index succeeds in the rename, therein lies the potential for infinite loop. Conclusion, before I get to the long longer "why". I propose we change the form from: ~~~ path = "/path/to/dir" st = posix.stat(path) if st and st.type == "directory" then status = os.rename(path, path .. ".rpmmoved") if not status then suffix = 0 while not status do suffix = suffix + 1 status = os.rename(path .. ".rpmmoved", path .. ".rpmmoved." .. suffix) end os.rename(path, path .. ".rpmmoved") end end ~~~ to something along the lines of: ~~~ path = "/path/to/dir" st = posix.stat(path) reason = nil if st and st.type == "directory" then status, reason, errno = os.rename(path, path .. ".rpmmoved") if not status and errno == 17 then suffix = 0 while not status and errno == 17 do suffix = suffix + 1 status, reason, errno = os.rename(path .. ".rpmmoved", path .. ".rpmmoved." .. suffix) if errno ~= 17 then print("Failed to rename a directory. " .. reason) break end end os.rename(path, path .. ".rpmmoved") else print("Failed to rename a directory. " .. reason) end end ~~~ Not the best I have ever written but it adds checks that it failed for an expected reason where we intend to continue. A bit of Lua & overlayFS background of why this is happening. The scriptlet uses `os.rename`, which maps quite closely, from what I can tell from the behavior, to the C function `rename`. OverlayFS does not like to rename directories from lower layers (which could be a layer created by let's say `RUN mkdir /opt/foo` directive in a Containerfile) to upper layers without some specific mount options, like `metacopy` or `redirect_dir` enabled that enables the rename operation to succeed [2]. If there is not metacopy or redirect_dir, the operation will fail with errno 18 EXDEV. From what I understand, when one `podman run`s a container, there is a new upper layer for separating what happens in the running container, giving the temporary nature to changes in a running container. Or this "new" layer atop lower layers can also be observed when attempting to build a container. So this is a concern for both the situation of container build and the situation of container running. In both of those cases, if we attempt to rename a directory with that call it will fail without the mentioned mount options. However thanks to the loop that ignores the exact errno and just blindly tries to find an index until the `os.rename` returns `true` instead of `nil`, we get into a situation where the scriptlet, on package upgrade, goes into an infinite loop. A simple reproducer for this issue: ~~~ podman run -it --rm quay.io/fedora/fedora:41 bash -c 'dnf install -y lua >/dev/null && lua -e "status, str, code = os.rename(\"/var/games\", \"/var/games.moved\"); print(status, str, code)"; cat /proc/mounts | grep overlay' ~~~ This will attempt the rename close to what we'd expect in a scriptlet, and print the reason and specific errno code. Additionally prints how the overlay is mounted, to inspect options. This operation will succeed if there is either `redirect_dir=on` or the `metacopy=on` present in the mount options on the last line printed from running the container. `/var/games` was chosen due to no particular reason other than the directory being present on lower layers and not strictly necessary for runtime, allowing for experimentation. Specifically with node.js, it happened simply because there was already an existing container, similar to quay.io/fedora/nodejs-22 and an attempt to update via build was made in style of: ~~~ FROM quay.io/fedora/nodejs-22 USER 0 RUN dnf update -y USER default ~~~ This was enough to trigger the problem. This is very similar to the reproducer: `os.rename` was called on an already existing directory. However the directory was in a lower layer, making the fail related to the errno 18 EXDEV instead of errno 17 EEXIST which we would regard as a valid errno where we can continue. Thoughts? Feedback? Regards, Jarek Prokop [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replace… [1] https://www.lua.org/manual/5.3/manual.html#pdf-os.rename [2] https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#renaming-…

4 4

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

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