devel September 2026

devel@lists.fedoraproject.org

79 participants
49 discussions

Orphaning jql
by h-k-81＠hotmail.com 10 Sep '26

10 Sep '26

Hi all, I have orphaned the following packages: - rust-jql - rust-jql-runner - rust-jql-parser I have never really used this package but somehow took it over a couple years ago. All three packages are in a good shape and upstream is still active. If anyone has interest in keep the package in Fedora then that person has to adopt all three together. Best regards, Hussein

1 0

F45 Beta is GO
by Aoife Moloney via devel-announce 10 Sep '26

10 Sep '26

The Fedora Linux 45 Beta RC 1.3 compose is GO and will be shipped live on Tuesday,15 September, 2026. As a reminder, we will enter Final Freeze on 6 October, 2026. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-09-… [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-09-… -- 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://forge.fedoraproject.org/infra/tickets/issues/new

1 0

Adopting orphaned package: gnome-shell-extension-openweather
by Joaquín Daniel 10 Sep '26

10 Sep '26

Hello, I would like to adopt the orphaned package gnome-shell-extension-openweather. I have experience contributing to open source projects since 2021, including reviving the neofetch package in Fedora. Could you please guide me on the process to adopt this package? Thank you.

2 2

Donate 1 minute of your time to test upgrades from F44 to F45
by Miroslav Suchý 10 Sep '26

10 Sep '26

Do you want to make Fedora 45 better? Please spend 1 minute of your time and try to run: LC_ALL=en_US.UTF-8 dnf --releasever=45 --enablerepo='*-testing' --assumeno distro-sync This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` and ` remove-retired-packages` before running this command. The `--assumeno` will just test the transaction, but does not make the actual upgrade. In case you hit dependency issues, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in next Fedora. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu and also there is lots of "Fails to install" (F45FailsToInstall) reports: https://bugzilla.redhat.com/buglist.cgi?bug_id= <https://bugzilla.redhat.com/buglist.cgi?bug_id=2384425&bug_id_type=anddepen…>*2433836* <https://bugzilla.redhat.com/show_bug.cgi?id=2433836>&bug_id_type=anddependson&bug_status=__open__&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity&order=id%2C%20&query_format=advanced <https://bugzilla.redhat.com/buglist.cgi?bug_id=2384425&bug_id_type=anddepen…> For convenience here is the relevant part of Fedora Guidelines on renaming and replacing packages: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-repl… I myself discovered lots of issues. I will send it as separate email to this thread. Thank you Miroslav

5 5

F45 Change Proposal: Enable Shadow Stack by Default on x86_64 (system-wide)
by Aoife Moloney via devel-announce 10 Sep '26

10 Sep '26

Wiki - https://fedoraproject.org/wiki/Changes/ShadowStack Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-enable-shadow-st… 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 == This change enables Shadow Stack protection on applications and libraries built with gcc (C, C++), clang (C, C++), and rustc (Rust) by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker or static startup routines will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support (marked with ELF metadata), protecting processes by default whenever possible. == Owner == * Name: [[User:submachine| Arjun Shankar]] * Email: arjun(a)redhat.com == Detailed Description == Shadow Stacks are a hardware enforced security feature that maintains a separate, tamper proof list of return addresses to protect against Return-Oriented Programming style exploits. This change enables Shadow Stack protection by default on x86_64 machines that support it on Fedora Linux 45. The dynamic linker, or static startup routines, will activate Shadow Stack for any process whose binary and shared library dependencies are all built with Shadow Stack support, protecting processes by default whenever possible. Shadow Stacks are one of two Control-Flow Enforcement features introduced in Intel CET, alongside Indirect Branch Tracking (IBT), designed to defend against Return-Oriented Programming (ROP) and Jump-Oriented Programming (JOP) attacks by protecting return addresses. This Fedora change only covers enabling Shadow Stack support. Enabling Indirect Branch Tracking by default is not in scope. This change is backward compatible for the most part: `-fcf-protection` is a default compile time flag already enabled in `redhat-rpm-config` for Fedora since 2018 and thus the majority of binaries are already built with the appropriate markup. Thus, after this change is applied, applications whose dependencies carry Shadow Stack markup gain protection transparently while applications that load any non-compliant object at startup continue to run without Shadow Stack protection. The only new failure mode is when a Shadow Stack enabled process attempts to `dlopen` a non-compliant shared object at runtime, which results in a `dlopen` error that looks like `error: dlopen: /path/to/library.so: rebuild shared object with SHSTK support enabled`. Two mitigation strategies can be used, depending on the package: # Where the `dlopen`ed library can be fixed to include Shadow Stack support, the library is fixed and rebuilt with the appropriate markup. This is the preferred fix because it preserves Shadow Stack protection for the calling application. # Where the non-compliant code cannot be fixed in time, the calling application is opted out of Shadow Stack via glibc's [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/… System-Wide Tunables] configuration that can be shipped per-application as a configuration file. This disables Shadow Stack for that specific application while all other processes retain protection. == Feedback == No community feedback has been received yet. This section will be updated as feedback is collected. == Benefit to Fedora == This change provides hardware-enforced protection against Return-Oriented Programming (ROP) style attacks for the majority of Fedora binaries at negligible performance cost. Shadow Stacks are enforced by the CPU and do not require software instrumentation at runtime. The overhead is limited to maintaining a second copy of the return address stack in protected memory, which has no measurable impact on typical workloads. The change is transparent: compliant applications are protected without any code change, rebuild, or user action. Because `-fcf-protection` is already a default compile flag in Fedora, the majority of packages are already built with the appropriate ELF markup. Enabling Shadow Stack in the dynamic linker activates protection for these packages immediately. This also lays groundwork for enabling Indirect Branch Tracking (IBT) in a future release, which together with Shadow Stack would provide full Control-Flow Enforcement Technology (CET) protection. == Scope == * Proposal owners: The glibc maintainers will: # Apply a glibc downstream patch that reverts an upstream change that deactivates Shadow Stack support. # Include the upstream glibc [https://inbox.sourceware.org/libc-alpha/cover.1782444639.git.dj@redhat.com/… System-Wide Tunables] feature, which has obtained upstream consensus and will be part of the next glibc release. This feature enables per-application opt-out via configuration files. # Ship `/etc/tunables.conf` with `include /etc/tunables.conf.d/*.conf` so that individual packages can drop in their own configuration files in order to opt-out. # Validate that SUID/SGID applications correctly sanitize tunables so that unprivileged users cannot disable Shadow Stack for privileged programs. # Open tracking bugs for all known incompatible packages. * Other developers: Most packages built with Fedora's default flags already produce Shadow Stack compatible binaries and no action is needed in this case. Packages that include hand-written assembly or build with different flags might ship ELF objects without Shadow Stack markup. Maintainers of such packages will need to make changes to their package to include Shadow Stack markup (e.g., annotate assembly routines). A special case is applications built with Shadow Stack support that currently `dlopen` shared objects built without it. These applications will encounter a runtime error at `dlopen` unless one of these fixes is applied: # The `dlopen`ed library is compiled with Shadow Stack support enabled. # The application opts out of Shadow Stack support using glibc's System-Wide Tunables feature. For example, a package named `app` providing `/usr/bin/app` would install `/etc/tunables.conf.d/app.conf` containing: <pre> [proc:/usr/bin/app] glibc.cpu.x86_shstk=off </pre> This disables Shadow Stack for that specific application while all other processes retain protection. The drop-in file is owned by the affected package's RPM, so it is added and removed with the package. Once the dependency is fixed, the package update removes the drop-in file and the application gains Shadow Stack protection. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13388 #13388] Most objects are already built with support, and enablement is via a glibc update. For Rust, binary packages need to be rebuilt once the Rust dependency is in place. This can be done as part of the regularly scheduled Fedora 45 mass-rebuild. We will track this as part of the F45 GNU Toolchain release engineering ticket linked to above. * Policies and guidelines: No changes to packaging guidelines are required at this time. Default build configuration already builds objects with support and for the majority of packages, the change is transparent. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This change is in line with Fedora's security posture and commitment to shipping secure-by-default systems. == Upgrade/compatibility impact == After upgrading to Fedora 45, Shadow Stack support will be enabled automatically for processes whose binary and all loaded shared libraries carry the appropriate markup. Processes that load any non-compliant shared object will have Shadow Stack silently disabled at startup. The only exception is applications that are fully Shadow Stack compliant at startup and then use `dlopen` to load a shared object without Shadow Stack markup at runtime. This will lead to a `dlopen` failure. However, affected applications can be configured to opt out of Shadow Stack protection, or have their dependencies fixed. Incompatible packages will be identified by scanning the Fedora package set for ELF objects missing the SHSTK property note, and by testing critical desktop and server workloads against the COPR repository with Shadow Stack enabled. Tracking bugs will be filed for all known incompatible packages. This work has already started and is being tracked in [https://bugzilla.redhat.com/show_bug.cgi?id=2458434 Bugzilla]. # Where the `dlopen`ed library is under Fedora's control, it can either be fixed and rebuilt with support, or the dependent package configured to run with Shadow Stack turned off as described in the Scope section above. # Users who encounter this problem with third party applications can work around it using the System-Wide Tunables feature as described earlier. == Early Testing (Optional) == A COPR repository with the updated glibc (Shadow Stack enabled) is available for Fedora 43, 44, and Rawhide for early testing: https://copr.fedorainfracloud.org/coprs/submachine/glibc-x86_64-SHSTK-Testi… Do you require 'QA Blueprint' support? No  == How To Test == 1. Shadow Stack hardware support is available on Intel 11th Generation and newer CPUs, and AMD Zen3 and newer CPUs, so testing does not require any special hardware except a recent enough x86_64 processor. 2. Machine learning workloads that use GPU acceleration via AMD ROCm are a specific area of interest because the ROCm runtime libraries may lack Shadow Stack markup. Testing these workloads (e.g., pytorch with ROCm) requires access to AMD GPUs. 3. Once the runtime has been enabled for Shadow Stack, testing involves (a) verifying the shadow stack status of running processes (`cat /proc/$pid/status | grep x86_Thread_features`), and (b) verifying that there are no application errors or crashes due to incompatible binaries. 4. The majority of running processes should be protected, with Shadow Stack enabled. == User Experience == This change is transparent to users. No action is required to enable or configure support. Applications that are not compatible with Shadow Stack run without the protection; they continue to function normally but do not benefit from the additional security. In rare cases, an application that loads a non-compliant plugin at runtime may encounter a `dlopen` error. Known affected applications ship with a drop-in configuration file that prevents this. Users who encounter this with other applications can create a file in `/etc/tunables.conf.d/` to opt the application out, and then run `ldconfig`. == Dependencies == 1. Rust: The rust compiler needs to be able to generate Shadow Stack compatible binaries. This affects a significant part of the Fedora runtime and applications, including `rpm` and `firefox`. However, we are collaborating with the Rust team and have already tested a `rustc` change that enables emitting compatible binaries by default (without the use of any flags). The [https://bugzilla.redhat.com/show_bug.cgi?id=2196282 Rust Fedora Bug] tracks this. 2. Firefox and Chrome: Both browsers are currently not compatible with Shadow Stack although the Firefox binary and some objects are built with Shadow Stack enabled. Upstream work, in particular around their JIT compilers, as well as the rust tooling change mentioned above are needed in order to fix this. Until then, we propose to disable Shadow Stack protection flags when building Firefox. Both browsers will gain Shadow Stack protection once their upstream dependencies are resolved, at which point they can be rebuilt with protection turned on. == Contingency Plan == * Contingency mechanism: Downstream patch applied to glibc to enable Shadow Stacks by default in Fedora will be reverted. * Contingency deadline: No deadline. The patch can be reverted as late as necessary in the development cycle. * Blocks release? No. == Documentation == === Guide for package maintainers === ==== Checking an ELF object for CET support ==== Use `readelf` to inspect the GNU property note on any object file, shared library, or binary. e.g.: <pre> readelf -n /usr/lib64/libc.so.6 | grep 'IBT\|SHSTK' </pre> A fully compliant object shows both properties: <pre> Properties: x86 feature: IBT, SHSTK </pre> While this change only requires `SHSTK`, IBT (Indirect Branch Tracking) will be enabled in a future release and fixing both now avoids having to revisit these packages later. For this change, only `SHSTK` is required. An object with `IBT` but not `SHSTK` will still cause Shadow Stack to be disabled for the process. An object with `SHSTK` but not `IBT` is fully compliant with this change. Fixing both properties is recommended so that packages are ready for a future IBT enablement, but only `SHSTK` is needed now. The linker ANDs these bits across all inputs, so a single unmarked object will strip the property from the final binary. Packages are built by default with `-fcf-protection` enabled, so source files when compiled with default flags are automatically built with SHSTK/IBT support. However, hand-written assembly needs annotations in order to be built with the property enabled. This leads to situations where linking against objects built with hand-written assembly without the appropriate annotations strips the final binary or shared object of CET support. ==== Annotating a GAS assembly file ==== Hand-written `.S` files compiled through GCC do not automatically receive the CET property note. To fix this, add one line near the top of the file: <pre> #include <cet.h> </pre> For IBT compatibility, add `_CET_ENDBR` (also defined by `cet.h`) at the entry point of any function that may be reached via an indirect branch (e.g. function pointer): <pre> #include <cet.h> .text .globl my_handwritten_func .type my_handwritten_func, @function my_handwritten_func: _CET_ENDBR /* ..function body */ ret </pre> == 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://forge.fedoraproject.org/infra/tickets/issues/new

19 59

Fedora 45 Candidate Beta-1.3 Available Now!
by rawhide＠fedoraproject.org 10 Sep '26

10 Sep '26

3 2

update of libxml2 and mini mass rebuild in rawhide
by Zbigniew Jędrzejewski-Szmek 10 Sep '26

10 Sep '26

Hi folks, I've adopted the Change Proposal to update libxml2 [1]. I've done a test rebuild in copr [2] and results seem OK. I'll be proceeding with builds for rawhide in a side tag: - libxml2-2.5.4 - libxml2_2.13-2.13.9 - and then everything reported by 'fedrq wr -F src -b rawhide libxml2' [3] with the following exceptions: libxml2 (already built) evolution (ftbfs, missing deps) evolution-ews (ftbfs, missing deps) fpm2 (ftbfs, nettle incompat) gpac (ftbfs, missing deps) gstreamer1-plugins-bad-free (ftbfs, missing deps) gstreamer1-plugins-good (ftbfs, missing deps) kdewebdev (incompat with new libxml2?) kf5-kdoctools (ftbfs, requires extra-cmake-modules 6.30) kf5-kio (ftbfs, requires extra-cmake-modules 6.30) kopete (ftbfs, missing deps) krecipes (ftbfs, missing deps) kronosnet (ftbfs in rahwide, builds in f45) libdigidocpp (ftbfs, something about openssl) lincity-ng (ftbfs, some cmake problem) python-dmidecode (ftbfs, not sure why) qdigidoc (ftbfs, something about openssl?) stoken (ftbfs, nettle incompat) swift-lang (fails with some build error burried in interminable output) vlc (ftbfs, dependency issues) webkitgtk (ftbfs, dependency issues) xmlstarlet (real problem with new libxml2) Previously I pushed build fixes to armacycles-ad, appstream-generator, collectd, liblouisutdml, libisds (all reasons unrelated to libxml2), and have local patches for libosinfo, shigofumi, librsvg2 to fix build with new libxml2 and will push those to before the build. I updated a VM with the new libraries, and things seem to work fine. If something doesn't get rebuilt or fails, usually this would not be problem, because the compat package will be available. An issue would only occur if there's a binary I want to start the builds tonight, around 18:00 GMT. Zbyszek [1] https://fedoraproject.org/wiki/Changes/Libxml215 [2] https://copr.fedorainfracloud.org/coprs/zbyszek/libxml2-soname-update/build… [3] $ fedrq wr -F src -b rawhide libxml2 0ad abiword adobe-afdko akonadi-server anaconda anjuta appstream appstream-generator aqbanking aqualung ardour6 ardour7 ardour8 ardour9 aria2 armacycles-ad artikulate asterisk atomes atril audacious-plugins augeas autofs autogen bijiben bind bind9-next blackbox-terminal bluefish bodr bookworm booth brasero budgie-control-center cairo-dock cairo-dock-plug-ins caja caja-actions caja-extensions cantor caribou castget certmonger cgreen chatty chemical-mime-data cinnamon clamav clang18 collada-dom collectd compiz compizconfig-python compiz-plugins-experimental compiz-plugins-extra compiz-plugins-main conky cptutils createrepo_c ctags cyrus-imapd darktable davix dcmtk ddccontrol denemo dia dicomanonymizer diffmark digikam dleyna dnf5 docbook5-schemas docbook5-style-xsl docbook-dtds docbook-simple docbook-slides docbook-style-xsl dumpet dvdauthor ebook-tools emacs envytools eom epiphany erlang-cowboy erofs-utils evince evolution evolution-data-server evolution-ews evolution-rspam ezstream fcitx fence-agents ffmpeg flam3 flatpak flatpak-builder flickcurl florence folks fontconfig fontforge foomatic foundry fpm2 freewrl frogr fuse-emulator gambas3 GAPDoc gcc GConf2 gdal gdcm gdigi geany-plugins geary gettext gimp gitg glabels glade glusterfs gnome-applets gnome-app-list gnome-boxes gnome-builder gnome-calculator gnome-chemistry-utils gnome-connections gnome-control-center gnome-doc-utils gnome-epub-thumbnailer gnome-maps gnome-online-accounts gnome-panel gnome-radio gnome-vfs2 gnote gnucash gnucobol gnumeric gnustep-base goffice gpac gprconfig-kb gpscorrelate gpx-viewer gq GraphicsMagick gretl gridsite grilo-plugins grisbi gsequencer gssntlmssp gssproxy gst-editing-services gstreamer1-plugins-bad-free gstreamer1-plugins-good gtkpod gtk-sharp2 gtksourceview2 gtksourceview3 gtksourceview4 gtksourceview5 gtranslator guestfs-tools gupnp gupnp-av gupnp-dlna gupnp-tools gvfs happy hidrd hitori hivex httpd hwloc icecast igraph ImageMagick inkscape input-pad intel-lpmd Io-language jgmenu kanatest kdelibs kdelibs3 kdewebdev kf5-akonadi-server kf5-kdoctools kf5-kio kf6-kdoctools kf6-kio khelpcenter kitinerary kopete krecipes ktouch labwc labwc-tweaks lasem lash lasso lastpass-cli libabigail libabw libaccounts-glib libarchive libavif libbluray libbonobo libbonoboui libcmis libcmpiutil libcompizconfig libcomps libdap libdatovka libdigidocpp libeasyfc libe-book libecoli libei libetonyek libgda libgda5 libgdamm libgdl libgedit-gtksourceview libgepub libglade2 libgnomecanvas libgnt libgphoto2 libgpod libgrss libgsf libguestfs libgweather libideviceactivation libiio libisds liblangtag liblouisutdml liblxi libmateweather libmodsecurity libmusicbrainz5 libnbd libodfgen libosinfo libpeas libqalculate libqb libquentier librasterlite2 libreoffice librepo libreport librsvg2 libs3 libsbml libsbw libsexy libsolv libsoup libspatialite libtnc libvirt libvirt-glib libvirt-sandbox libvisio libwebcam libwmf libxkbcommon libxklavier libxml++ libxml2 libxml++30 libxml++40 libxml++50 libxslt libzypp liferea lighttpd lincity-ng linsmith lldpd llvm llvm19 llvm20 llvm21 localsearch logjam lordsawar lttng-tools lxappearance-obconf lxpanel m17n-lib Macaulay2 mail-notification mallard-rng mapnik mapserver mariadb10.11 mariadb11.8 mariadb12.3 mate-applets mate-calc mate-control-center mate-media mate-notification-daemon mate-system-monitor mediaconch mlt mobile-broadband-provider-info mod_auth_mellon mod_security moreutils msitools mstflint nagios-plugins-bonding nagios-plugins-openmanage nemiver netcdf netpbm NetworkManager-openconnect newsboat nexus nfs-utils nghttp2 nginx nip2 noctalia nordugrid-arc nx-libs oath-toolkit obconf obconf-qt ocaml-gettext ochusha oddjob openbabel openbox openconnect opendnssec openlierox openscad openscap opensips openslide open-vm-tools openwsman osc-source_validator osinfo-db-tools osmo ots pacemaker pam_mount pasdoc PDAL perl-RDF-Trine-Node-Literal-XML perl-XML-DifferenceMarkup perl-XML-LibXML perl-XML-LibXML-Devel-SetLineNumber perl-XML-LibXSLT pgmodeler phodav php php-libvirt php-pecl-xmldiff php-pecl-xmlrpc pidgin pidgin-chime pidgin-sipe pluma podofo podofo0.10 postgresql16 postgresql16-postgis postgresql17 postgresql17-postgis postgresql18 postgresql18-postgis postgresql19 pragha pspp pymol python-dmidecode python-firehose python-html5-parser python-igraph python-lxml python-ovirt-engine-sdk4 python-pyside6 python-xmlsec qdigidoc qdl qgis qt5-qtwebkit qt6-qtwebengine ramond raptor2 rarian recoll rest rest0.7 rhythmbox R-igraph root rpminspect rrdtool rubygem-nokogiri R-XML R-xml2 rygel s3fs-fuse sane-airscan sane-backends sbd scribus sgml-common shared-mime-info shigofumi shotwell snapper snownews sooperlooper soundmodem soundtracker sparse spatialite-tools sqliteodbc srcpd sssd stoken strongswan subtitleeditor swift-lang syncevolution synfig synfigstudio systemtap t4k_common teg telepathy-gabble telepathy-salut tellico thermald tinyows tinysparql tiptop tomboy totem-pl-parser transactional-update tuba tuxpaint tvtime twinkle umbrello usbguard uwsgi vcdimager vdr-epg-daemon verbiste vfrnav vhostmd vim-syntastic virt-top virt-v2v virt-viewer vlc vtk warmux wayfire-config-manager wayland webkitgtk wf-config wireshark wmbusmeters wv xar xcb-proto xed xfce4-weather-plugin xgrep xhtml1-dtds xiphos xml2 xmlsec1 xmlstarlet xmms2 xmoto xournalpp xreader xrootd xscreensaver YafaRay yaz yelp yelp-tools zabbix zypper

2 3

libnfs 7.0.0 soname bump
by Xavier Bachelot 10 Sep '26

10 Sep '26

Hi, libnfs 7.0.0 bumps its soname from 16 to 17. Affected packages are: gvfs kodi (RPM Fusion) mpd nbdkit qemu vlc xine-lib Affected maintainers are all CC'ed. I have requested a side tag and built libnfs there. One can use it with: fedpkg build --target=f45-build-side-146733 I already took care of xine-lib. Could you please rebuild the other packages in the side tag ? Regards, Xavier

3 4

rocm-smi: unreviewed dist-git PR fixing a btop crash (rhbz#2417737)
by Igor f4k3r Giamoniano 10 Sep '26

10 Sep '26

Hi, I opened a dist-git PR against rawhide five weeks ago and it hasn't had any review, so I'm raising it here in case pagure PRs aren't on the maintainers' radar: https://src.fedoraproject.org/rpms/rocm-smi/pull-request/4 Neither rocm-smi.spec nor the %cmake macro sets CMAKE_BUILD_TYPE, so NDEBUG is never defined and the shipped librocm_smi64 keeps its assert() calls. On unexpected sysfs data that aborts the calling process — btop dies with SIGABRT on affected machines — instead of returning RSMI_STATUS_UNEXPECTED_DATA, which is what the throw immediately after the assert is there for. Full analysis in rhbz#2417737 comment 14. The change is one line. NDEBUG goes in through CXXFLAGS rather than -DCMAKE_BUILD_TYPE=Release, because Release also enables upstream's post-build strip, which empties debugsourcefiles.list and fails the build. Verified in mock on rawhide (7.14.0): -DNDEBUG on every compile line, debuginfo and debugsource intact. All Packit checks pass. Happy to file the same for f44, or to rework it if there's a preferred way to solve this. Thanks, Igor Giamoniano

2 1

[Fedocal] Reminder meeting : F45 Beta Go/No-Go Meeting
by amoloney＠redhat.com 09 Sep '26

09 Sep '26

Dear all, You are kindly invited to the meeting: F45 Beta Go/No-Go Meeting on 2026-09-10 from 17:00:00 to 20:00:00 UTC The meeting will be about: Please join us for the Fedora Linux 45 Beta Go/No-Go meeting in #fedora-meeting on matrix @ 1700 UTC. In this meeting, we will determine the status of the release candidate for F45 Beta. For more information on this meeting, please visit https://fedoraproject.org/wiki/Go_No_Go_Meeting Source: https://calendar.fedoraproject.org//meeting/11428/

1 0

2026

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 September 2026