December 2023 - devel - Fedora Mailing-Lists

by Tomas Hrcka

Hello all, Fedora Linux 37 has gone end of life for updates and support on 2023-12-05. No more updates of any kind, including security updates or security announcements, will be available for Fedora Linux 37 after the said date. All the updates of Fedora Linux 37 being pushed to stable will be stopped as well. Fedora Linux 38 will continue to receive updates until approximately one month after the release of Fedora Linux 40. The maintenance schedule of Fedora Linux releases is documented on the Fedora Project wiki [1]. The Fedora Project wiki also contains instructions[2] on how to upgrade from a previous release of Fedora Linux to a version receiving updates. This email template is also in https://pagure.io/releng if you wish to propose improvements or changes to it. Regards, Tomas Hrcka Fedora Release Engineering [1] - https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Sche... [2] - https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades [3] - https://pagure.io/releng -- Tomas Hrcka fas: humaton libera.CHAT: jednorozec -- _______________________________________________ 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.fedora... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 months, 2 weeks

8
14
0 / 0

F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

by Aoife Moloney

Wiki -> https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_A... 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 == Additional paths will be inserted into the search path used for executables on systems which have a compatible CPU. Those additional paths will mirror the AMD64 "microarchitecture levels" supported by the glibc-hwcaps mechanism: `x86-64-v2`, `x86-64-v3`, `x86_64-v4`. Systemd will be modified to insert the additional directories into the `$PATH` environment variable (affecting all programs on the system) and the equivalent internal mechanism in `systemd` (affecting what executables are used by services). Individual packages can provide optimized libraries via the glibc-hwcaps mechanism and optimized executables via the extended search path. This optimized code will be used if the CPU supports it. ''Which'' packages provide the optimized code and at which level will be made by individual package maintainers based on benchmark results. == Owner == * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] NOTE: I'm writing and filling this proposal on the last day allowed for system-wide proposals. It is too large for one person. If you are interested, please let me know or even add yourself to the list of Owners. I would love to have more people working on this. == Detailed Description == Fedora binaries for the AMD64 architecture are compiled with code-generation flags that support almost all CPU variants. But newer generations of processors gained additional instructions that may be used to generate faster code. A vendor-independent x86-64 psABI supplement defines four "microachitecture levels": `x86-64-v1` (the baseline, our code targets this), `x86-64-v2` (+`SSE3`, CentoOS targets this), `x86-64-v3` (+`AVX`), `x86-64-v4` (+`AVX512`) [1]. When code is compiled for a higher microarchitecture level it will crash (with `SIGILL`, "illegal instruction") on CPUs which do not support it. Benchmark results show small differences in performance: usually in the range from -5% to 10%, with no discernible difference for most code, but '''some''' applications benefit, with gains of 120% in some benchmarks [e.g. 2, 4]. Over the years, various people have expressed interest in raising the required microarchitecture levels. But we have been very conservative in making changes, because support is missing in many older CPUs that are still in use, and in fact, even in some CPUs produced and sold today. By raising the required level we would make Fedora completely unusable on many machines. It also seems that recompiling ''all'' packages with the changed options would largely be a waste of resources, because for most code it makes no difference. But for some of the numerical or cryptographic code there are noticeable gains and it seems to be worth the effort to provide optimized code. This also makes Fedora more attractive to people interested in optimization. The dynamic linker already has the `glibc-hwcaps` mechanism to load optimized implementations of ''shared objects'' [3]. This means that packages can provide optimized libraries and they linker will be automatically load them from separate directories if appropriate. (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.) To extend the glibc-hwcaps mechanism to ''executables'', `systemd` will be modified to extend the search path with appropriate directories. When started, it will check the CPU capabilities and modify the executable search path it has internally and which is also used to set `$PATH` for services. (For AMD64, `/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/`.) Note: the ELF format provides the IFUNC mechanism to dynamically select a variant of a function (symbol) when an executable is loaded [5]. This is in particular used to load code using specific CPU instructions when those are supported. This mechanism is both more general (because it allows arbitrary selection criteria), more fine-grained (because there can be other variants than just a few fixed microarchitecture levels), and more efficient (because only the parts of the code that benefit from this need to be provided in multiple variants). In particular, glibc already makes extensive use of this to provide optimized code, which is then widely used by other libraries and programs. This means that even though we compile code in a way where the lowest baseline is supported, modern CPU instructions are already widely used. This is one of the reasons why compiling for a higher baseline often doesn't make any difference in benchmarks. The IFUNC mechanism or an equivalent mechanism should generally be preferred. Nevertheless, that needs to be implented in the program or library itself, which is not trivial. The two mechanisms in this Proposal are intended for the packages which do not support IFUNCs or some other equivalent mechanism. [1] https://hackweek.opensuse.org/all/projects/support-glibc-hwcaps-and-micro... [2] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0002-march... [3] https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html [4] https://blog.centos.org/2023/08/centos-isa-sig-performance-investigation/ [5] https://jasoncc.github.io/gnu_gcc_glibc/gnu-ifunc.html Glibc-hwcaps together with the new feature in systemd provide a generic mechanism. It will be up to individual packages to actually provide code which makes use of it. Individual package maintainers are encouraged to benchmark their packages after recompilation, and provide the optimized variants if useful. (I.e. the code in question is measureably faster '''and''' the program is ran often enough for this to make a difference.) The Change Owners will implement the packaging changes for a few packages while developing the general mechanism and will submit those as pull requests. Other maintainers are asked to do the same for their packages. Optimized variants of programs and libraries MAY be packaged in a separate subpackage. The general packaging rules should be applied, i.e. a separate package or packages SHOULD be created if it is files are large enough. Available benchmark results [2,4] are narrow and not very convincing. We should plan an evaluation of results after one release. If it turns out that the real gains are too small, we can scrap the effort. On the other hand, we should also consider other architectures. For example, microarchitecture levels `z{14,15}` for `s390x` or `power{9,10}` for `ppc64le`. Other architectures are not included in this Change Proposal to reduce its scope. == Feedback == == Benefit to Fedora == The developers who are interested in this kind of optimization work can perform it within Fedora, without having to build separate repositories. The users who have the appropriate hardware will gain performance benefits. Faster code is also more energy-efficient. The change will be automatic and transparent to users. Note that other distributions use higher microarchitecture levels. For example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use x86-64-v3, and other distros provide optimized variants (OpenSUSE, Arch Linux). We implement the same change in Fedora in a way that is scoped more narrowly, but should provide the same performance and energy benefits. == Scope == * Proposal owners: ** Extend systemd to set the executable search path using the same criteria as the dynamic linker. ** Implement packaging changes for at least one package with a library and at least one package with executables and submit this as pull requests. ** Provide a pull request for the Packaging Guidelines to describe the changes listed in Description above. * Other developers: ** Do benchmarking and implement packaging changes for other packages if beneficial. * Release engineering: [https://pagure.io/releng/issue/11864 #11864] * Policies and guidelines: TBD. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact. == How To Test == * Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system. * Install one or more packages which provide optimized code. * Restart the system or re-login to reinitialize `$PATH`. * Check that appropriate directories are present in `$PATH`. * Run some benchmarks and check that the optimized code is indeed faster. == User Experience == There should be no impact for users. If the optimized code is available and installed for their hardware, various tasks may finish faster and use less energy. == Dependencies == == Contingency Plan == * Contingency mechanism: Undo the changes in packages which introduced them and recompile. * Contingency deadline: Any time. * Blocks release? No. == Documentation == == Release Notes == Packages which benefit from being compiled for higher AMD64 microarchitecture levels (`x86-64-v2`, `x86-64-v3`, `x86_64-v4`) are now provided with optimized variants which will be used automatically on appropriate CPUs. This includes: TBD1, TBD2, TBD3. -- 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.fedora... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 months, 2 weeks

24
35
0 / 0

F40 Change Proposal: Change Firefox Desktop File (System-Wide)

by Aoife Moloney

Wiki -> https://fedoraproject.org/wiki/Changes/RenameFirefoxDesktopFile 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 == Recent Firefox desktop file (firefox.desktop) does not comply with DBus/Gnome search provider rules thus Firefox can't provide DBus Gnome search service. We should change Firefox desktop file from firefox.desktop to org.mozilla.firefox.desktop. == Owner == * Name: [[User:stransky| Martin Stransky]] * Email: <stransky(a)redhat.com> == Detailed Description == Firefox needs to provide desktop file in expected format to pair DBus service and Gnome search service together to make Gnome search service work. == Feedback == == Benefit to Fedora == We'll fix already broken feature. == Scope == * Proposal owners: Desktop file name is changed in Firefox 121.0. * Other developers: Fedora Workstation needs update Firefox desktop name (hardcoded in gnome-shell) to correctly place Firefox to Gnome taskbar as default application. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] No need to coordinate with rel-eng. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == Should not impact. == How To Test == 1) Open Firefox 2) Type something to Gnome search 3) It works Test also KDE/Plasma it doesn't crash (https://bugzilla.redhat.com/show_bug.cgi?id=2017123) == User Experience == Enabled Gnome shell search provider for Firefox. == Dependencies == None == Contingency Plan == * Revert desktop file name change in Firefox package. * Blocks release? No == Documentation == == 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.fedora... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

3 months, 2 weeks

3
2
0 / 0

Mock Configs v39.3 released - DNF5 used for F40+ builds

by Pavel Raiskup

Hello maintainers! Let me announce a new release of Mock Core Configs v39.3, aka the configuration files for Mock, the chroot build environment manager for building RPMs. The notable change in this release is that we are switching the default package_manager from DNF4 to DNF5, according to the F40 change: https://fedoraproject.org/wiki/Changes/BuildWithDNF5 Full release notes: https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3 We plan to push this update into Fedora Copr to get some early testing next week. Then, depending on the releng team, we might push this into Koji soon. The Bodhi updates links are here: F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0 F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930 F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40 EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053 EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46 Note that we **will not** push these updates into Fedora stable earlier than on Monday 2023-12-18 (but very likely we'll wait till the next year, depending on the feedback). Happy (faster) building! Pavel

3 months, 3 weeks

5
14
0 / 0

RFC: OpenScanHub Prototype for Fedora

by Siteshwar Vashisht

Hello, I am writing this email to get feedback from the members of the Fedora development community about OpenScanHub for Fedora. # tl;dr OpenScanHub does static and dynamic analysis of rpm packages and it may be helpful in the Fedora community. Please take a look at our staging proof of concept[4] and provide feedback. The proof of concept is in its early stages so there may be some bugs here or there! If the feedback is positive we may roll this out in official infrastructure and integrate with Fedora CI and Packit. # What OpenScanHub is a service for static and dynamic analysis. It has been in development inside Red Hat[1] for more than 12 years and was open sourced on GitHub[2] earlier this year. You can read a brief explanation of this service on my blog[3]. We would like to deploy this service on the Fedora infrastructure and start scanning packages shipped in the Fedora project through it. # Why I am sharing a prototype[4] of this service to get feedback from the community. This prototype is running on the staging instance of the Fedora infrastructure, so you would have to login[5] to the staging instance before submitting any scan. If you have never logged into that account, it may require you to do a password reset. Once you are logged into the staging instance, you can login through the `krb5login` button[6] on the top right corner of the homepage and submit a scan through this form[7]. There are 3 different types of scans supported by OpenScanHub: - MockBuild performs a full scan of the package including downstream patches. Example[8] mockbuild for `openssl-3.1.1-4.fc39`. - DiffBuild performs a differential scan on the downstream patches. So you can find only the defects that are introduced by the downstream patches. Example[9] diffbuild for `openssl-3.1.1-4.fc39`. This option would not work if the package fails to compile without patches. - VersionDiffBuild performs a differential scan between 2 different versions of the package, and you can see defects introduced by the “newer” version of the package. Example[10] differential build between `openssl-3.1.1-4.fc39` and `openssl-3.0.9-2.fc38`. All the submitted scans can be seen on the tasks[11] page. This prototype is running on very limited resources, so please do not submit scan for any resource consuming package. Not all defects reported by OpenScanHub may be actual bugs, so please avoid fixing reported defects without careful examination. If we receive positive feedback on this prototype, there may be a possibility of integrating this service with the Fedora CI and Packit projects. This is a very early stage prototype and may behave inconsistently. Please keep the discussion in this thread constructive. Thank you! [1] https://kdudka.fedorapeople.org/muni23.pdf [2] https://github.com/openscanhub/openscanhub [3] https://situ.im/posts/openscanhub [4] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/ [5] https://accounts.stg.fedoraproject.org [6] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/auth/krb5login/ <https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/auth/krb5login...> [7] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/scan/new/ [8] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/6/log/ope... [9] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/9/log/ope... [10] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/7/log/add... [11] https://staging-openscanhub.apps.ocp.stg.fedoraproject.org/task/

3 months, 3 weeks

2
2
0 / 0

Review of Matrix Go packages

by Kai A. Hiller

Hello, I’m currently adding Go-based parts of the Matrix ecosystem to Fedora. For that I need reviews of quite a few, but mostly small and auto-generated packages. Help is appreciated, please tell me what you need from me in return. List of package dependencies and bugzilla links: golang-maunium-mautrix (#2250408 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250408>) ├ golang-mau-zeroconfig (#2249896 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249896>) ├ golang-mau-util (#2249878 <https://bugzilla.redhat.com/show_bug.cgi?id=2249878>) ├ golang-maunium-mauflag (#2249890 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249890>) ├ golang-maunium-maulogger-2 (#2249894 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249894>) │ ├ golang-github-tidwall-sjson (#2249874 <#https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249874>) │ │ ├ golang-github-tidwall-gjson (#2249873 <#https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2249873>) │ │ │ ├ golang-github-tidwall-match (#2249868 <#https://bugzilla.redhat.com/show_bug.cgi?id=2249868>) ├ golang-github-matrix-org-gomatrixserverlib (#2250315 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250315>) │ ├ golang-gopkg-macaroon-2 (#2250314 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250314>) │ ├ golang-github-matrix-org-util (#2250311 <https://bugzilla.redhat.com/show_bug.cgi?id=2250311>) │ ├ golang-github-matrix-org-gomatrix (#2250312 <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250312>) │ ├ golang-github-tidwall-sjson Best wishes Kai

4 months

2
2
0 / 0

Obsoleting zlib in Fedora Rawhide

by Tulio Magno Quites Machado Filho

Following the recent approval from Fesco, I'm planning to distribute zlib-ng-compat packages for Rawhide later this week. I hope this will give us enough time to work on the issues before Fedora 40 is released. 🤞 So, keep in mind this will *obsolete zlib in Rawhide*. This update is also known to trigger test failures in the following packages: - binutils - cpp-httplib - git - jose - libpng - openexr1 - openms - python-3.12 - qpdf In general, the failing tests expect that libz will always have the same behavior, e.g. - same output length - identical output - same version string format This will require changes in order to guarantee the tests do succeed. If you have any questions or need help with these issues, let me know. -- Tulio Magno

4 months

7
15
0 / 0

Change of cronie and crontabs CIS compliance

by Ondrej Pohorelsky

Hi everyone, For F40 I would like to change file permissions of few files that are provided by cronie and crontabs and swap deny list for allow list. I'm not really sure if I should make a change proposal. I figured I'll send an email first and see the feedback. The driving force of this change is feedback from RHEL customers, that they would like to have cronie and crontabs CIS compliant out of the box. Which means changing some of the file permissions and swapping `cron.deny` for `cron.allow`. As it stands now, they have to run their own scripts or dnf plugin (post-transaction-actions) to ensure that each update doesn't overwrite the file permissions they manually set. I would like these changes for F40, as this is going to be a branching point for next RHEL and I would like to go with upstream first approach. *cronie* changes: `cron.allow` replaces `cron.deny` (file permission 600) `cron.d` permission change (755 → 700) `cron.hourly` permission change (755 → 700) *crontabs* changes: `crontab` permission change (644 → 600) `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700) Reference for these changes: static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html PR: https://src.fedoraproject.org/rpms/cronie/pull-request/12 https://src.fedoraproject.org/rpms/crontabs/pull-request/6 Let me know what you think. Cheers, -- Ondřej Pohořelský Software Engineer Red Hat <https://www.redhat.com> opohorel(a)redhat.com <https://www.redhat.com>

4 months

11
21
0 / 0

F40 Change Proposal: LLVM 18 (System-Wide)

by Aoife Moloney

Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18 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 == Update all llvm sub-projects in Fedora Linux to version 18. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: <tstellar(a)redhat.com> == Detailed Description == All llvm sub-projects in Fedora will be updated to version 18, and there will be a soname version change for the llvm libraries. Compatibility packages clang17, llvm17, and lld17 will be added to ensure that packages that currently depend on clang and llvm version 17 libraries will continue to work. We may add other compatibility packages too if they're determined to be necessary to maintain functionality in other RPMS that use llvm/clang. We also plan to retire these older compatibility packages (that we own): * llvm14 * llvm15 * llvm16 * clang14 * clang15 * clang16 * lld14 * lld15 * lld16 We will also be asking the maintainers of the following packages to retire them if possible: * llvm7.0 * llvm8.0 * llvm11 * llvm12 * llvm13 Other notable changes: * clang will emit DWARF-5 by default instead of DWARF-4. This matches the upstream default. We have been using DWARF-4 as the default for the last few releases due to: https://bugzilla.redhat.com/show_bug.cgi?id=2064052 * The compatibility packages will now include the same content as the main package. In previous releases, the compatibility packages contained only libraries and headers, and the binaries and other content was stripped out. These packages will be supported for use as dependencies for other RPM packages, but not for general purpose usage by end users. Fedora users should use Clang/LLVM 18. * The compatibility packages added for Fedora 40 will be retired prior to the Fedora 41 branch. * We will be enabling Fat LTO in redhat-rpm-config if this feature is complete in time for the upstream LLVM 18 release. Fat LTO is a feature that allows the compiler to produce libraries that contain LTO bitcode along side the traditional ELF binary code so that the libraries can be linked in both LTO mode and non-LTO mode. gcc also supports this feature and has it enabled in Fedora. In Fedora 39 and older, with LTO enabled, clang produces binaries with only LTO bitcode, so we need to run a post-processing script (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code so they can be used by other packages. Enabling Fat LTO will allow us to remove this script and simplify the build process. ===LLVM Build Schedule=== ====Important Dates==== * Jan 26: Upstream: 18.0.0-rc1 Release * Feb 6: Fedora: f40 branch created * Feb 6: Upstream: 18.0.0-rc2 Release * Feb 20: Fedora: f40 Beta Freeze * Feb 20: Upstream: 18.0.0-rc3 Release * Mar 5: Upstream: 18.0.0 Release * Apr 2: Fedora: f40 Final Freeze ====Plan==== # Build nightly trunk (LLVM 18) snapshots in [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots... copr]. # Build LLVM 18.0.0-rc1 in COPR. # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji. # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji. # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji. # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji. # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not ready) as a Beta Freeze exception. # Continue building new release candidates and pushing them to stable until the Final Freeze. We are not planning to push 18.0.0-rc1 into rawhide because the library ABI is not stabilized at that point. Typically, the ABI stabilizes after -rc3, but there are no guarantees from upstream about this. Given the history of minimal ABI changes after -rc3, we feel like it's safe to push -rc3 into rawhide. The worst case scenario would be an ABI change -rc4 or the final release that we force us to patch LLVM to maintain compatibility with the -rc3 ABI. This scenario would not require rebuilding LLVM library users in Fedora, so this would not require much extra work from our team. Updates after 18.0.0-rc3 will generally be very small and can be done after the Final Freeze is over. If we are late packaging release candidates after -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug. == Feedback == == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build and test early release candidates of LLVM 18 in COPR. * Other developers: ** Fix build issues found with LLVM-18 or switch their package to use the llvm17 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-18. There should be around 6-8 weeks between when -rc1 lands in the koji side-tag and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-18 update. * Release engineering: [https://pagure.io/releng/issue/11845 #11845] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == This change should not impact upgrades. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 18. == User Experience == == Dependencies == Packages that depend on one of the llvm packages will need to be updated to work with LLVM18 or will need to switch to using one of the llvm17 compat packages. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) If there are major problems with LLVM 18, the compatibility package provide a way for other packages to continue using LLVM 17. * Contingency deadline: Final Freeze == Documentation == LLVM sub-projects in Fedora have been updated to version 18: *llvm *clang *lld *lldb *compiler-rt *libomp *llvm-test-suite *libcxx *python-lit *flang *mlir *polly *libclc *llvm-bolt == 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.fedora... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

4 months

4
3
0 / 0

appstream soname bump in Rawhide (special info for AppStreamQt users!)

by Neal Gompa

Hey folks, As part of the work to upgrade to KDE Plasma 6, appstream is being upgraded to a snapshot release as 1.0.0 is arriving soon. There are some consequences for this change: * appstream has gone through an API/ABI breakage, and consumers will need to adapt * appstream-data needs to move its content from /usr/share/app-info/{xmls,icons} to /usr/share/swcatalog/{xml,icons} * Direct consumers of the C API will need to make changes to support appstream 1.0 * Consumers of the Qt bindings moving to Qt6 will need to make changes to support appstream 1.0 * Consumers of the Qt5 bindings will need to build against appstream0.16-qt-devel I've built appstream in a side-tag, and I'd appreciate it if folks could help by adapting their packages and submitting builds into it. This can be done with the following command: fedpkg build --target=f40-build-side-76936 My simple query of the consumers of the libraries in question resulted in this: ngompa@fedora ~> sudo dnf repoquery -q --whatrequires "libappstream.so.4()(64bit)" --qf "%{SOURCE_NAME}" appstream appstream-generator flatpak gnome-software libadwaita malcontent ngompa@fedora ~> sudo dnf repoquery -q --whatrequires "libAppStreamQt.so.2()(64bit)" --qf "%{SOURCE_NAME}" appstream calamares kf5-frameworkintegration plasma-discover plasma-workspace We'll try to help where we can to update things accordingly. -- 真実はいつも一つ！/ Always, there's only one truth!

4 months

5
19
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2023