devel June 2025

devel@lists.fedoraproject.org

132 participants
171 discussions

Is the chromium debuginfo package exists?
by Mikhail Gavrilov 08 Oct '25

08 Oct '25

Hi folks! Is the chromium debuginfo package exists? Quick searching in repos didn't find any debuginfo packages for chromium. # dnf search chromium | grep debuginfo Last metadata expiration check: 0:08:12 ago on Mon 26 Jul 2021 02:25:19 AM +05. chromium-bsu-debuginfo.x86_64 : Debug information for package chromium-bsu lightspark-chromium-plugin-debuginfo.x86_64 : Debug information for package lightspark-chromium-plugin And of course I enabled "rawhide-debuginfo" repo.

5 4

fedup upload failure
by Martin Gansser 29 Sep '25

29 Sep '25

Hello, I'm getting the following error when I'm uploading a new tarball: $ kinit martinkg(a)FEDORAPROJECT.ORG $ fedpkg new-sources vdr-plugin-epg2vdr-1.1.86.tar.bz2 Could not execute new_sources: Request is unauthorized. Any ideas as to why I can not do an fedpkg upload? I'm able to do a fedpkg clone so my rsa keys are good...

2 3

replace memtest86+ with pcmemtest, needs maintainer
by Chris Murphy 01 Sep '25

01 Sep '25

[Bug 1988142] memtest boot entry on Fedora install media does not work since Fedora-Rawhide-20210728.n.3 https://bugzilla.redhat.com/show_bug.cgi?id=1988142 This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. Neal Gompa mentioned pcmemtest earlier this year https://github.com/martinwhitaker/pcmemtest It would need a maintainer. Any takers? Fedora doesn't have a release criterion covering the memory tester, or really any option appearing in the install media's boot menu other than the one that launches the installer. But I think it's better to not ship a memory tester at all, than to ship a broken one (given the options). Memtest86+ is bios only, where pcmemtest can be compiled to run on either firmware type. If we want it to work with UEFI Secure Boot enabled, it'd need to be signed with Fedora's key (I think the same as the one used for GRUB and/or the kernel?). This would be in scope for Fedora 36, assuming the above bug can be easily fixed. But if that bug is hard to fix, and pcmemtest could be a drop-in replacement (i.e. bios only, just like now) maybe that's doable for Fedora 35, and better than having no memory tester. Chris Murphy -- Chris Murphy

15 33

F42 Change Proposal: Deprecation of STI Tests (self-contained)
by Aoife Moloney via devel-announce 26 Aug '25

26 Aug '25

Wiki - https://fedoraproject.org/wiki/Changes/DeprecateSTI Discussion Thread - https://discussion.fedoraproject.org/t/f42-change-proposal-deprecation-of-s… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Display a deprecation warning for Fedora 41 for all STI tests. Deprecate execution of STI tests in all CI pipelines for Fedora 42. * CI for bodhi updates * CI for dist-git pull requests All users of STI tests will need to [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… migrate to the new tmt format]. '''The change will affect 281 components'''. The list of components affected can be found via [https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org+… this sourcegraph query]. All references to STI will be removed from the Fedora CI documentation. == Owner == * Name: [[User:mvadkert| Miroslav Vadkerti]], [[User:lecris| Cristian Le]], * Email: mvadkert(a)redhat.com, fedora(a)lecris.me == Detailed Description == For some time CI testing in Fedora can be defined using two different formats: * Standard Test Interface (STI) * Test Management Tool (tmt) As tmt has matured to a state it can fully replace the STI functionality, we are proposing to drop STI as the supported format. STI format is not actively developed and is causing us a maintenance burden. More and more STI test failures are starting to appear as the Fedora packages evolve out of sync with the test scripts. Tmt provides various advantages over STI that would make it easier to manage in the long term: * Better organization of `tests` and test environments (referred to as `plans` in tmt) * Local reproducible environment thanks to testing-farm reproducer script, allowing to thinker locally without pushing to dist-git * Tests can be defined in the local dist-git repo, inside the srpm archive, [https://src.fedoraproject.org/projects/tests/%2A `tests/*`] dist-git namespace, or in the upstream repo, allowing it to be reused more freely between packages and with upstream directly * Tmt tests are integrated with packit allowing it to be executed with upstream and better migrate to the new dist-git environment Hopefully this list can help inspire some better ways of reorganizing the tests during the migration. == Feedback == == Benefit to Fedora == Having two formats for executing the tests is an unnecessary duplication and causes confusion for the Fedora maintainers and community. STI tests have limited functionality and are harder to develop and maintain, when compared to tmt. == Scope == * Proposal owners: [[User:mvadkert| Miroslav Vadkerti]], [[User:lecris| Cristian Le]] * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == This is a change to the development experience, no changes to Fedora distribution are made. == How To Migrate == To find out if you package has STI tests, check if `tests/tests*.yml` files are present in your dist-git repository. Follow the [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… sti to tmt migration guide]. For the majority of tests involve just executing the already provided script you only need to: 1. Initialize `tmt` structure using `tmt init` 2. Create a minimal plan <pre> # /plan.fmf # Boilerplate to indicate tmt to run any tests files it finds in the repo discover: how: fmf execute: how: tmt # Prepare test environment, e.g. install packages # Note: the current packages in the spec file will already be installed by default prepare: how: install packages: - foo - bar </pre> 3. Migrate individual tests <pre> # /tests/foo.fmf test: ./foo.sh </pre> For more complex needs feel free to discuss in the [https://matrix.to/#/#fedora-ci:fedoraproject.org `#fedora-ci`] or [https://matrix.to/#/#tmt:fedoraproject.org `#tmt`] matrix channels. You can also explore [https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org/… other project's tmt tests] (identified by having a `.fmf` folder) using `tmt tests show` and `tmt plans show` == User Experience == For Fedora 41 users will be presented with a deprecation warning in the Testing Farm artifacts. For Fedora 42 users who have setup gating on STI tests will be obligated to migrate to be able to push their packages to stable repositories. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No (not a System Wide Change) We will keep the STI support until all references to STI tests are gone in case all users have not migrated to tmt until Fedora 42. See the description for the list of the affected components. == Documentation == * [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… How to migrate STI tests to tmt] * [https://src.fedoraproject.org/tests/python/tree/main Example test repo implemented in both STI and tmt format] (see for example the `smoke/venv.fmf` file and `smoke_default` test in `tests.yml` file) * [https://tmt.readthedocs.io/en/stable/spec.html Tmt specs] (reference for the available keys defining `plans` or `tests`) * Example project with shared [https://github.com/containers/aardvark-dns upstream]+[https://src.fedoraproject.org/rpms/aardvark-dns downstream] tests == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-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/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

2 1

Remove old GPG keys?
by Miroslav Suchý 13 Aug '25

13 Aug '25

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

17 31

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 06 Aug '25

06 Aug '25

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

pdftk retired?
by Michael J Gruber 06 Aug '25

06 Aug '25

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 06 Aug '25

06 Aug '25

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

Packaging Guidelines for Applications using Git Submodules
by Gerald B. Cox 06 Aug '25

06 Aug '25

I'm trying to figure out the best way to handle the situation where a project decides to use submodules in Git. The archive generated doesn't incorporate the submodule files. I've done some searching on this, and haven't really come up with much. I've reviewed: Packaging:Github <https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…> ; but that really doesn't address the submodule issue. I looked through some packages that are currently in the Fedora repository and found where a few folks have rebuilt the tarball and referenced that version as the Source in the spec file; then they put in a comment stating: The source of this package was pulled from upstreams' vcs. Use the following commands to generate the tarball: ... - git clone ... - git submodule init - git submodule update ... This approach is the best that I've found. Any other suggestions? Thanks much!

8 11

Intel's Clear Linux optimizations
by František Zatloukal 06 Aug '25

06 Aug '25

Hi, Phoronix recently release article[1] about Intel's Clear Linux with some cool graphs showing nice performance gain compared to Xubuntu. I didn't have time to dig in and look how it's performing against Fedora, but I'd assume Fedora can be compared to Xubuntu in terms of compiler settings. I think i'll be interesting to look into it and find out if Fedora can't tweak compiler settings (eg use LTO for critical things like Mesa, Kernel, ...). I think it could be interesting fo Fedora users to have this enabled if there are not any disadvantages other than compile time, compile memory usage and so on. What do you think? [1] http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1 -- Best regards / S pozdravem, František Zatloukal Project Coordinator Red Hat

15 50

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2025