packaging

packaging@lists.fedoraproject.org

2 participants
2909 discussions

RFC: Forge organization for FPC and some packaging-related tools?
by Fabio Valentini 02 Mar '26

02 Mar '26

Hello packagers, There's some tools maintained on pagure.io (rpmdevtools, fedora-review, ...) that don't neatly fit into any SIGs responsibilities. And on the other hand, the Packaging Committee will also need to move the Packaging Guidelines repo from pagure.io at some point. So ... maybe these two things actually fit together - in a "packaging" org on forge.fedoraproject.org? Especially fedora-review is clearly Packaging Guidelines related, so it would fit well with FPC stuff IMO. One thing that would need to be figured out is how to set up the permission structure for the org though, but that could probably be worked out too. What do you think? Fabio

3 5

Handling configuration changes without drop-in support
by Daria Guy 01 Mar '26

01 Mar '26

Hi, I am packaging a server (foo) whose main configuration file under /etc is marked as %config(noreplace). I also have another package (bar) that provides functionality for the server and requires adding a loadmodule directive to foo’s main configuration in order to work. In this case, using a configuration drop-in file is not viable because it can lead to incorrect configuration processing and may prevent the server from starting in certain scenarios. What would be considered an acceptable approach under the Fedora Packaging Guidelines? Would it be permissible for foo or bar to use RPM triggers to add and remove a clearly defined block in foo’s configuration file? Additionally, would the answer differ if bar were packaged as a subpackage of foo rather than as a separate package? Thanks, Daria

2 1

general question about mock build sizes in koji
by Marius Schwarz 28 Feb '26

28 Feb '26

Hi, i have doubts if i will sort of damage koji & the stable repo later, because to fully build the project, it will take up to 40 GB per full-build. The massive data from the vosk voice models is causing this. At the beginning it will be maybe 3 GB , but later, when more laguagues are supported, i'm afraid it will really have 40 GB per fullbuild. Lucky for us, vosk next to never changes the models ;) What do you think, can i pump those into koji, considering that 40GB is per release per architecture , could go up to 400 GB total ( worst case ). I think advice is needed, how to keep that small. My idea: Is it possible to stop koji from building the same model over and over again? It's just a big pile of data, which will be unique for any release & arch. best regards, Marius Schwarz

3 15

general question about mock build sizes in koji
by Marius Schwarz 21 Feb '26

21 Feb '26

Hi, I wrote: > i have doubts if i will sort of damage koji & the stable repo later, because to fully build the project, it will take up to 40 GB per full-build. and now it became a fact.. the 2 GB RPM is not processed in koji.. the upload just stops with a notice. As the upload had only 600KB/s, i assume, it's a webserver timeout. I can send it faster, but koji does not take it in faster. Any ideas how to proceed here? The package is already the absolute minimum. SRPM: Name : vosk-model-de Version : 0.21 Release : 0.fc42 Architecture: noarch Install Date: (not installed) Group : Utils Size : 2031726509 License : Apache License 2.0 Signature : (none) Source RPM : (none) Build Date : Fr 20 Feb 2026 23:22:17 CET Build Host : eve.resellerdesktop.de URL : https://github.com/Cyborgscode/Personal-Voice-Assistent/ Summary : Vosk model: large german Description : The large german vosk model you need to run PVA. * Fr Feb 20 2026 Marius Schwarz <fedoradev(a)cloud-foo.de> - initial build -rw-r--r-- 1 root root 2031725553 Feb 20 01:00 vosk-model-de-0.21.zip -rw-r--r-- 1 root root 956 Feb 20 01:00 vosk-model-de.spec mock RPM: Version : 0.21 Release : 0.fc42 Architecture: noarch Install Date: (not installed) Group : Utils Size : 3349354282 License : Apache License 2.0 Signature : (none) Source RPM : vosk-model-de-0.21-0.fc42.src.rpm Build Date : Fr 20 Feb 2026 23:23:49 CET Build Host : localhost.localdomain URL : https://github.com/Cyborgscode/Personal-Voice-Assistent/ Summary : Vosk model: large german Description : The large german vosk model you need to run PVA. * Fr Feb 20 2026 Marius Schwarz <fedoradev(a)cloud-foo.de> - initial build -rw-r--r-- 1 root root 35 Feb 20 01:00 /etc/pva/conf.d/21-model-german-large.conf drwxr-xr-x 2 root root 0 Feb 20 01:00 /usr/share/licenses/vosk-model-de -rw-r--r-- 1 root root 543 Feb 20 01:00 /usr/share/licenses/vosk-model-de/AUTHOR -rw-r--r-- 1 root root 11358 Feb 20 01:00 /usr/share/licenses/vosk-model-de/LICENSE-2.0.txt drwxr-xr-x 2 root root 0 Sep 15 2021 /usr/share/pva/vosk-model-de-0.21 -rw-r--r-- 1 root root 740 Sep 15 2021 /usr/share/pva/vosk-model-de-0.21/README drwxr-xr-x 2 root root 0 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/am -rw-r--r-- 1 root root 103291412 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/am/final.mdl -rw-r--r-- 1 root root 1 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/am/frame_subsampling_factor -rw-r--r-- 1 root root 1440528 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/am/tree drwxr-xr-x 2 root root 0 Aug 2 2020 /usr/share/pva/vosk-model-de-0.21/conf -rw-r--r-- 1 root root 131 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/conf/mfcc.conf -rw-r--r-- 1 root root 289 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/conf/model.conf drwxr-xr-x 2 root root 0 Aug 9 2020 /usr/share/pva/vosk-model-de-0.21/graph -rw-r--r-- 1 root root 601554029 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/HCLG.fst -rw-r--r-- 1 root root 78 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/disambig_tid.int -rw-r--r-- 1 root root 5 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/num_pdfs drwxr-xr-x 2 root root 0 Aug 18 2020 /usr/share/pva/vosk-model-de-0.21/graph/phones -rw-r--r-- 1 root root 3566 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones.txt -rw-r--r-- 1 root root 43985339 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/align_lexicon.int -rw-r--r-- 1 root root 56351443 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/align_lexicon.txt -rw-r--r-- 1 root root 52 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/disambig.int -rw-r--r-- 1 root root 42 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/disambig.txt -rw-r--r-- 1 root root 2 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/optional_silence.csl -rw-r--r-- 1 root root 2 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/optional_silence.int -rw-r--r-- 1 root root 4 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/optional_silence.txt -rw-r--r-- 1 root root 21 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/silence.csl -rw-r--r-- 1 root root 4506 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/word_boundary.int -rw-r--r-- 1 root root 4906 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/phones/word_boundary.txt -rw-r--r-- 1 root root 16187725 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/graph/words.txt drwxr-xr-x 2 root root 0 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector -rw-r--r-- 1 root root 168048 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/final.dubm -rw-r--r-- 1 root root 8288887 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/final.ie -rw-r--r-- 1 root root 33775 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/final.mat -rw-r--r-- 1 root root 825 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/global_cmvn.stats -rw-r--r-- 1 root root 95 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/online_cmvn.conf -rw-r--r-- 1 root root 35 Aug 21 2020 /usr/share/pva/vosk-model-de-0.21/ivector/splice.conf drwxr-xr-x 2 root root 0 Aug 9 2020 /usr/share/pva/vosk-model-de-0.21/rescore -rw-r--r-- 1 root root 2115929988 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/rescore/G.carpa -rw-r--r-- 1 root root 107992138 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/rescore/G.fst drwxr-xr-x 2 root root 0 Sep 15 2021 /usr/share/pva/vosk-model-de-0.21/rnnlm -rw-r--r-- 1 root root 10070031 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/rnnlm/feat_embedding.final.mat -rw-r--r-- 1 root root 57872445 Sep 14 2021 /usr/share/pva/vosk-model-de-0.21/rnnlm/final.raw -rw-r--r-- 1 root root 60 Sep 15 2021 /usr/share/pva/vosk-model-de-0.21/rnnlm/special_symbol_opts.conf -rw-r--r-- 1 root root 226161198 Sep 13 2021 /usr/share/pva/vosk-model-de-0.21/rnnlm/word_feats.txt

2 1

Re: [JAVA] packaging question
by Marius Schwarz 21 Feb '26

21 Feb '26

> IF i can switch the upstream to jakarta versions, the problem would be solved, cause both packages are allready in Fedora. found a working way by using the compat *1 jakarta packages. Some minor changes had to be made, but it's working. But pls, for future projects, how to proceed with jar files, only used in the app. Best regards, Marius -- _______________________________________________ packaging mailing list -- packaging(a)lists.fedoraproject.org To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject… Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

2 1

Re: [JAVA] packaging question
by Marius Schwarz 20 Feb '26

20 Feb '26

Am 20.02.26 um 19:36 schrieb Tom Callaway: > My Java is a bit rusty, but aren't most/all javax components > long-deprecated and replaced with jakarta components of the same (or > similar) names? Perhaps using those is a better approach. they moved hands to eclipse and got integrated into jakarta, as far as i could find out. From the first sight check the packages they moved to are in Fedora, but do not seem to be compatible oob. Have to dig into that. IF i can switch the upstream to jakarta versions, the problem would be solved, cause both packages are allready in Fedora. In case i can't, and back to the original question, how to proceed with those? Best regards, Marius

1 0

[JAVA] packaging question
by Marius Schwarz 20 Feb '26

20 Feb '26

Hi, I'm building a java app with jar dependencies : -rw-r--r--. 1 root root 78030 6. Jul 2022 javax.activation-1.2.0.jar -rw-r--r--. 1 root root 659031 2. Jul 2022 javax.mail-1.6.2.jar javax.activation is not packaged yet by anyone else in F42 javax.mail is not packaged yet by anyone else in F42 I have to assume, my project is the only in Fedora that will use those jars. So, according to the java guidelines, i can keep them in a lib/ folder. Correct? Do the licences have to be externaly readable? means: Do i need to create a file i.e. named javax.mail-1.6.2.LICENSE ? or are the LICENSE files inside the jars enough? best regards Marius Schwarz

1 0

Conflicting guidelines for alternative manpages
by Peter Oliver 15 Nov '25

15 Nov '25

https://docs.fedoraproject.org/en-US/packaging-guidelines/ says: > When installing man pages, note that RPM will re-compress them into > its preferred format. So the %files section MUST reference manpages > with a pattern that takes this into account: > > %files > %{_mandir}/man1/foo.1* However, https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ says: > the links set up by alternatives MUST be listed as %ghost in the file > list and proper Requires: MUST be added, like in the examples below. … > %ghost %{_mandir}/man8/sendmail.8.gz Notice that the .gz is hard-coded, because the %ghost macro treats * literally. Sooner or later, someone will want to swap gzip for, say, zstd, and this will break. Do we need a macro specifying the extension, that we can use in such cases? For example: %__brp_compress_ext .gz I could do something along the lines of the following to discover the extension, but it seems potentially fragile: bash -c 'export RPM_BUILD_ROOT=/tmp PREFIX=/no/such/dir; . "$(rpm -E %{__brp_compress})"; echo $COMPRESS_EXT'

2 1

Ownership of rpminspect-data-fedora and rpminspect-data-centos
by Dave Cantrell 01 Oct '25

01 Oct '25

I am trying this again. No one has responded to my requests for help here and I get the feeling that either no one cares or no one really cares. It's somewhat depressing to me given the amount of time I've put in to these tools actually trying to save people time and make workflows easier. I just need help maintaining some text files. The TL;DR is that these data packages need new ownership. It cannot be just me. It also shouldn't fall on the software management team. The data packages are policy, not code. The whole idea here is that policy decisions can be made and implemented independent of the code. The logical point of ownership to me is the FPC. There can be multiple maintainers of the package, but the point is it should be maintained by policymakers and not me. I am not on the FPC and my maintenance of these data packages is unfortunately reactive, which makes for a less useful tool for everyone. Can someone please help me here? Upstream projects and developers within Fedora and CentOS Stream make use of rpminspect and submit PRs to the data projects to adjust the packaging policy rules it checks for. That was the intent when I wrote rpminspect. It's meant to be a collaborative tool to ensure we are capturing packaging policies in a format that rpminspect can use. I am still upstream for rpminspect and have no problems with that. People submit PRs there, which I appreciate. But when a policy changes or a new release is made, the data package needs updating. Without maintenance of the config files, then it leads devs to think "ugh, rpminspect is broken and a total piece of s***, why won't someone fix this?!". No, it's just that no one is taking responsibility for maintaining the config files. You can be that person! Please help? Anyone. Thanks, -- Dave Cantrell <dcantrell(a)redhat.com> Red Hat, Inc. | Boston, MA | EST5EDT

4 5

Please do not convert KDE stack packages to RPMAutoSpec
by Neal Gompa 19 Aug '25

19 Aug '25

Hello folks, While we in the PSWG/KDE SIG have been working on extending our automation to support snapshot builds in COPR/OBS, we've come across a few packages in the KDE stack that have been inappropriately switched to RPMAutoSpec. It is the position of the KDE SIG that packages that are part of the KDE stack *must not* use RPMAutoSpec as it is problematic for package builds outside of Fedora Koji. Notably, neither COPR nor OBS handle RPMAutoSpec packages properly, and this results in wonky issues with upgrade paths and other things being broken. This has been observed many times for us and it results in unusable results for testers and developers. Please do not convert any packages governed by the KDE SIG to RPMAutoSpec, especially if it is released by the KDE community. Thank you. -- Neal Gompa (FAS: ngompa)

5 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging