devel May 2025

devel@lists.fedoraproject.org

153 participants
187 discussions

ld: error: triggering the generation of an executable stack
by Orion Poplawski 16 Jun '25

16 Jun '25

With a recent update, plplot is failing to build with: cd /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt --verbose=1 /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -frecursive CMakeFiles/x16af.dir/x16af.f90.o -o x16af -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0 -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the generation of an executable stack (because it has an executable .note.GNU-stack section) /usr/bin/ld: failed to set dynamic section sizes: No such file or directory I have no idea what is up here. Seems to have started with: gcc 14.0.1-0.7.fc41 glibc 2.39.9000-3.fc41 util-linux 2.40-0.9.rc1.fc41 binutils 2.42.50-4.fc41 and lots of others, but that seems the most likely. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

6 6

rpm 4.1 x 4.20 and custom debuginfo packages
by Jiri Vanek 15 Jun '25

15 Jun '25

Hello! We had recently changed how we handle debuginfo in JDK: https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/147#req… Main change is, that we create debuginfo manually. Unluckily it was developed with rpm 4.20, so it built fine in f41-f43, but during porting to epels, I found it build in none. Just for curiosity I tried also in f40, and it failed too. So my guessing pointed to rpm 4.20. The failure in f41/epels is, that they ignore the manual %package debuginfo (debugsource seems fine) and insted they later print: error: Installed (but unpackaged) file(s) found: /usr/lib/debug/usr/lib/jvm/java-24-openjdk/bin/jar.debuginfo /usr/lib/debug/usr/lib/jvm/java-24-openjdk/bin/jarsigner.debuginfo /usr/lib/debug/usr/lib/jvm/java-24-openjdk/bin/java.debuginfo /usr/lib/debug/usr/lib/jvm/java-24-openjdk/bin/javac.debuginfo .... Which is contnet of my debugfiles.list, which is in 4.20 correctly used. In logs is visible that the debuginfo subpkg is not processed at all: ok: https://koji.fedoraproject.org/koji/taskinfo?taskID=133271306 not ok: https://koji.fedoraproject.org/koji/taskinfo?taskID=133347836 Anybody any thoughts please? TY! J.

4 9

Signaling daemons in logrotate configuration snippets
by Marcos Mello 13 Jun '25

13 Jun '25

Some packages install logrotate configuration snippets with postrotate scripts that call: ``` kill -<signal> `cat /run/<pidfile> 2>/dev/null` 2>/dev/null || true ``` A non-comprehensive list: php-fpm, nginx, syslog-ng. The CONFIGURATION FILE section of the logrotate(8) man page includes an example of this type of construction. https://src.fedoraproject.org/rpms/php/blob/rawhide/f/php-fpm.logrotate https://src.fedoraproject.org/rpms/nginx/blob/rawhide/f/nginx.logrotate https://src.fedoraproject.org/rpms/syslog-ng/blob/rawhide/f/syslog-ng.logro… This seems wasteful to me, as systemd *already knows* the daemon's main PID (even when there's no pidfile) and can achieve the same result with: ``` systemctl kill --signal=<signal> --kill-who=main <service> 2>/dev/null || true ``` (since systemd 252, the option has been renamed to `--kill-whom`, and `--kill-who` remains supported for compatibility) A long time ago, I opened a bug to change this for Nginx, but at the time, SELinux policy didn't allow it, and the change was reverted. Adjusting the SELinux policy to allow the use of `systemctl kill` in these cases would be beneficial, as the current policy (selinux-policy-targeted-41.40-1.fc42.noarch) still denies it: type=USER_AVC msg=audit(1748111593.330:131): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { stop } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/php-fpm.service" cmdline="" function="bus_unit_method_kill" scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:httpd_unit_file_t:s0 tclass=service permissive=1 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'UID="root" AUID="unset" AUID="root" UID="root" GID="root" SAUID="root" Does this make sense to you? Should I start filing bugs about this?

2 2

Remove openh264?
by Chris Adams 11 Jun '25

11 Jun '25

Is there any way to remove or replace openh264, without removing a bunch of other things? I thought noopenh264 was supposed to be a no-op replacement, but that doesn't seem to work, at least on Fedora 41: ************************************************************************ # dnf swap openh264 noopenh264 Updating and loading repositories: Repositories loaded. Problem: cannot install the best candidate for the job - conflicting requests Package Arch Version Repository Size Reinstalling: openh264 x86_64 2.4.1-2.fc41 fedora-cisco-op 1.1 MiB replacing openh264 x86_64 2.4.1-2.fc41 fedora-cisco-op 1.1 MiB Transaction Summary: Reinstalling: 1 package Replacing: 1 package ************************************************************************ I'm asking because there's a high-priority CVE on openh264 for months that doesn't seem like it's progressing towards getting resolved in Fedora. -- Chris Adams <linux(a)cmadams.net>

25 68

Slowness of installing *-selinux subpackages
by Richard W.M. Jones 09 Jun '25

09 Jun '25

[This is a general moan / observation ... Sorry!] SELinux policy is sometimes now split so that packages can carry their own policy subpackage. Examples include: https://src.fedoraproject.org/rpms/passt/blob/rawhide/f/passt.spec#_36 https://src.fedoraproject.org/rpms/nbdkit/blob/rawhide/f/nbdkit.spec#_751 I've recently been installing a lot of VMs with virt-v2v, and of the approximately 3 minutes spent installing the required packages, I'd estimate that around 2 minutes is spent running the *-selinux post-install scripts for swtpm-seinux, passt-selinux and nbdkit-selinux. For some reason passt-selinux is particularly excessive (I eyeballed it at around 75 seconds). I wonder if there's a way we could have RPM rebuild the SELinux policy just once in this situation? And asking another level of "why", why is rebuilding the policy so slow in the first place? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

9 10

Tekton pipeline for Fedora RPM builds in Konflux
by Pavel Raiskup 08 Jun '25

08 Jun '25

Hello maintainers, I'm happy to share that we now have a Konflux Pipeline for building Fedora packages. Ralph wrote a blog post about it today on the containers-sig: https://discussion.fedoraproject.org/t/konflux-fedora-update-may-2025/154784 The code lives here: https://gitlab.com/fedora/infrastructure/konflux/rpmbuild-pipeline Feel free to experiment, contribute, report bugs, and get involved! Happy building! Pavel

4 5

wget1 in Fedora
by Michal Ruprich 08 Jun '25

08 Jun '25

Hi, I've re-added the original wget as wget1 in Rawhide and also in F41 and F42 (updates now in Bodhi). wget binary is provided by wget1-wget subpackage. Once these updates get to the compose, if you want to start using wget1 instead of wget2, either swap the packages via dnf: # dnf swap wget2-wget wget1-wget OR use --allowerasing: # dnf --allowerasing install wget1-wget Regards, Michal Ruprich

6 5

[HEADS UP] Fedora 43 Python 3.14 rebuilds to start in a side tag (hopefully) next week
by Karolina Surma 07 Jun '25

07 Jun '25

Hello, To deliver Python 3.14 with Fedora Linux 43, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.14 Python 3.14.0b2 has been released on Monday, May 26th, 2025 and shipped in all Fedoras. We hope to start the mass rebuild beginning next week. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.14. Details: If you see a "Rebuilt for Python 3.14" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f43-python $ koji wait-repo f43-python --build <nvr> --request It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies. When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us. Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f43-python&inheri… Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks! Karolina

2 2

F42 Elections Voting is now Open!
by Aoife Moloney via devel-announce 03 Jun '25

03 Jun '25

The computer did not beat me, but it came close ;-) Im pleased to announce that voting for the F42 elections is now open[1]! Voting will remain open until June 2, 2025 at 23:59 UTC. Please take some time to read through the interviews by our great candidates this year for FESCo, Council, Mindshare and EPEL* and cast your vote to claim your badge[2]! *As the number of candidates equals the number of open seats for the EPEL Steering Committee, these candidates will be elected by default on June 2, 2025. Best of luck to our great candidates, and thank you all for making this election cycle very exciting! Kindest regards, Aoife [1] https://communityblog.fedoraproject.org/f42-elections-voting-is-now-open/ [2] https://elections.fedoraproject.org/ -- 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

1 2

RPM %doc directive
by Mattia Verga 02 Jun '25

02 Jun '25

I'm struggling with RPM's %doc directive... I have a package which installs a doc file in the buildroot, so I want to mark it as documentation. According to the RPM guide [1], the %doc directive can be used "in “special” form on a path relative to the build directory which causes the files to be installed and packaged as documentation", which is commonly used: '%doc README' will copy the README file from the build directory to the buildroot. But if a package already installs a file in the appropriate place of the buildroot, it should be possible to just mark that as documentation ("Can be used as a regular attribute on an absolute path")... But using '%doc %{_pkgdocdir}/python_module/README.md' returns 'Can't mix special %doc with other forms: /usr/share/doc/siril/python_module/README.md' How can I make %doc use that as absolute patch instead of special form? Am I wrong or it's a bug? [1] https://rpm-software-management.github.io/rpm/manual/spec.html

5 7

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 May 2025