Re: Use a buildroot override here?
On Mon, Mar 10, 2025 at 09:40:02PM +0900, Mamoru TASAKA wrote: > Untagged gcc-15.0.1-0.9.fc42 from gcc-15.0.1-0.9.fc42 > > (It can be done yourself by > $ koji untag-build f42-build-side-107435 gcc-15.0.1-0.9.fc42 > but for now I did it) Oh... Of course! Somehow, this simple solution didn't even cross my mind. That did the trick [1], thank you very much (also for the quick response)! [1] https://bodhi.fedoraproject.org/updates/FEDORA-2025-7f959f01d8 -- Michal Domonkos / RPM.org / Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F43 Change Proposal RPM 6.0 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855 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 == Update RPM to the upcoming 6.0 major release. == Owner == * Name: [[User:Pmatilai| Panu Matilainen]] * Email: pmati...@redhat.com == Detailed Description == Update RPM to the upcoming 6.0 release for several security improvements. Note: adopting Fedora to the new v6 package package format is explicitly NOT IN SCOPE for this change. RPM 6.0 in Fedora 43 will ship with v4 package generation as default, regardless of the upstream default. == Feedback == == Benefit to Fedora == The major theme in 6.0 is increased security and related improvements: * enforcing signature checking on by default * OpenPGP keys are referred to by their fingerprint or full key id where fingerprint not available (compared to the short keyid in previous versions) * OpenPGP keys can be updated with `rpmkeys --import ` and corresponding API(s) * support for multiple signatures per package (also an enabler for Post-Quantum signatures later on) * support for automatic signing on package build (mainly for local use) * support for signing with Sequoia-sq as an alternative to GnuPG A less direct benefit is enabling the testing of the new v6 package format in the wider ecosystem. Last but not least: with the release of 6.0, the RPM 4.x branch will go into a strict maintenance-only mode, there will be no further development on that branch. == Scope == This is the first RPM version to support the new v6 package format, but adopting Fedora to the new package format is explicitly not in scope for this change. * Proposal owners: ** Rebase RPM ** Assist dealing with incompatibilities * Other developers: ** Test and report issues ** Adjust 3rd party software/tools to work with the new formats and defaults where needed ** Test v6 package behavior with 3rd party software/tools (optional) * Release engineering: [https://pagure.io/releng/issue/12616 #12616] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == * Existing package build+install workflows may need to be adjusted due to enforced signature checking being the default. * 3rd party scripts and tools may need adjusting to the new key addressing format and other signature related output changes. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates, but of particular interest in this release are * updating previously imported keys * manipulating the rpm keyring via rpmkeys * testing the new v6 package format compatibility with 3rd party software (requires building packages with %_rpmformat set to 6) == User Experience == * The most noticeable change is that RPM now refuses to install packages whose signature hasn't been positively verified, whether due to being unsigned, missing key or otherwise. This can be worked around by supplying `--nosignature` on the command line, or more permanently, changing the `%_pkgverify_level` macro to the former default of `digest`, but these should be only temporary measures, users are encouraged to import necessary keys and/or setup automatic signing for their (local) builds instead. * Signature and key related output has changed: upper/lower case is followed consistently in related output, and OpenPGP keys are always addressed either by their fingerpring hash or the full keyid, whereas previously a collision prone, short key id was used. * `rpmkeys` is now the official tool for manipulating the rpm keyring. Other methods such as manipulating `gpg-pubkey` pseudo-packages manually are deprecated and should be updated to either the rpmkeys tool or the newly provided keyring APIs. == Dependencies == * The soname does not change so no rebuilds are required for dependencies or otherwise * There are no dependencies to other Fedora changes. * This is the first version of rpm built as C++, so rpm gains a runtime dependency on libstdc++. * Signing with Sequoia additionally requires sequoia-sq >= 1.0, but this is an optional dependency and even then, only for signing packages. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.20 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == * [https://github.com/rpm-software-management/rpm/discussions/3602 The road to RPM 6.0 blog] * [https://rpm.org/wiki/Releases/6.0.0 Draft release notes] (subject to change) * [https://rpm-software-management.github.io/rpm/manual/ Upstream reference
Re: Konflux: What is the right time?
Hello On Mon, Mar 10, 2025, 12:12 PM Richard W.M. Jones wrote: > On Sun, Mar 09, 2025 at 01:00:38PM -0700, Adam Williamson wrote: > > On Sat, 2025-03-08 at 11:31 -0800, Michel Lind wrote: > > > If this is both too heavy to evaluate on recent hardware, and also not > reproducibly deployable, it seems to currently be in a state where it has > all the drawbacks of Kubernetes but none of the benefits yet? Maybe we > should get to a point where people can reasonably deploy it before > considering it ready to be evaluated. > > > > Well, you don't need to deploy it for yourself, really. There is a > > public test Fedora deployment where you can play with it: > > > > https://github.com/konflux-ci/community/blob/main/sigs/fedora/cluster.md > > Thanks for this link. The instance is: > > > https://konflux.apps.kfluxfedorap01.toli.p1.openshiftapps.com/application-pipeline > > It's very very slow ... Most of the time I'm looking at a spinning > blue circle. I actually thought it was stuck, but it does eventually > render a page (after a minute or two). > > The other sections (like "Applications", "Secrets") didn't render > anything even after waiting 10 minutes. Also if I go to "Services" > and select "All Services" I get a bewildering array of choices which > seem to take me to some different thing entirely? I got loads of > "Sentry error ID" and 404s when I tried to do anything here. > > So it seems like quite an early alpha, which is fine of course, but > I'm still not entirely sure what I'm looking at here. > > Gitlab has a CI pipeline already which we use quite successfully > upstream on several different projects. Is this a replacement for that? > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Konflux: What is the right time?
On Mon, Mar 10 2025 at 11:11:33 AM +00:00:00, Richard W.M. Jones wrote: Thanks for this link. The instance is: https://konflux.apps.kfluxfedorap01.toli.p1.openshiftapps.com/application-pipeline I played around for about 3 minutes and am very confused. The overview page looks like an advertisement for Konflux itself. Why does it not show builds? There are so many menu items, and they are for stuff other than builds: * AI/ML: what does this possibly have to do with builds? * Automation, Containers: I guess this could plausibly be related to builds * Deploy: what would this do? Deployment must be managed by bodhi. * Identity and Access Management: why would packagers need access to this? * Integrations and Notifications * Inventories (what is an inventory?) * Observability and Monitoring (I wonder what this means) * Security (I wonder what this means) * Subscriptions and Spend (???) * System Configuration * Try and Buy I wasn't able to actually view any of these pages because the spinners just keep spinning. I assume this demo instance is so drastically under-resourced as to be effectively broken. But just from looking over the menu items, I'm pretty confused. It doesn't seem like it's designed to be a distro build system. Why would a Fedora packager ever need to Try and Buy or track Subscriptions and Spend? I haven't done more than just look at the overview page and the menu items, but what I see so far seems pretty drastically divorced from Fedora's actual needs. Optimistic take: maybe we could give it a face lift to remove the extraneous stuff. Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal RPM 6.0 (system-wide)
On Mon, 2025-03-10 at 16:42 +0100, Florian Weimer wrote: > > * The most noticeable change is that RPM now refuses to install > > packages whose signature hasn't been positively verified, whether due > > to being unsigned, missing key or otherwise. This can be worked around > > by supplying `--nosignature` on the command line, or more permanently, > > changing the `%_pkgverify_level` macro to the former default of > > `digest`, but these should be only temporary measures, users are > > encouraged to import necessary keys and/or setup automatic signing for > > their (local) builds instead. > > Does this impact installations via “dnf install”? I would assume so, since rpm is still under dnf in the end. > What's the impact on typical Fedora CI tests? We would need to make sure the CI systems download signed packages, somehow. AFAIK they currently don't. openQA certainly doesn't. I've been working on https://github.com/fedora-infra/bodhi/pull/5859 to help with this, but there turned out to be some subtleties that I didn't have time to deal with yet (and then I went on vacation). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is Konflux? What is Fedora Build System was Re: Konflux: What is the right time?
Yeah, I broadly agree with what smooge noted here. The idea isn't to just swap konflux in for koji and call it a day, but rather to use konflux as a build pipeline. The promise of konflux I could see it taking on things that are currently done by: pkgs / src.fedoraproject.org - it could download sources and verify them, removing the need to upload in many cases. robosignatory/sigul - it could handle signing artifacts and coordinating what artifacts are signed when by what. bodhi - bodhi could get out of the business of composing things and move to just being a UI to test and provide info back to konflux and others possibly. The things that I liked about what I have heard include ability for releng to define the pipeline of whats 'official', but at the same time users / sigs could define what they want to produce/distribute. As for other arches, my understanding is that for those all thats required is builder nodes of that arch. konflux will connect to them and build, no need for a bunch of extra clusters. I share some other folks concerns with some things I have seen, like I am not sure if the openshift permissions model will work for us, and the rpm building stuff is still really early, etc. I think there's a lot of promise, but to answer the question in the subject, I think the right time to discuss this in detail is probibly later this year when more things are known/have had time to develop, but by all means folks should look at provide feedback as they can. kevin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: spatialindex 2.1.0 coming to F43/Rawhide
In one week, 2025-03-18, or slightly later, in collaboration with Scott Logan (FAS: cottsay), I plan to update spatialindex from 1.9.3 to 2.1.0 in F43/Rawhide[1]. Upstream reports that “There are no significant major enhancements or refactorings that should change any behaviors. It had been a long time (almost 5 years!) since a release and 2.0.0 was the next version number...”[2][3] Nevertheless, the SONAME version has changed, and therefore I plan to use provenpackager privilege to rebuild the following packages in the same side tag: - minetest - qgis Testing in COPR[4] revealed no incompatibilities. This impact check also covered the python-Rtree package, which will not need to be rebuilt because it does not link the library, instead loading it at runtime using Python’s ctypes module. A similar update for Fedora 42 appears technically feasible, but isn’t planned because it doesn’t seem justified at this point in the release cycle. – Ben Beasley (FAS: music) [1] https://src.fedoraproject.org/rpms/spatialindex/pull-request/3 [2] https://github.com/libspatialindex/libspatialindex/releases/tag/2.0.0 [3] https://github.com/libspatialindex/libspatialindex/releases/tag/2.1.0 [4] https://copr.fedorainfracloud.org/coprs/music/spatialindex/packages/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Installing Forgejo from the Fedora repository doesn't end with a working instance – at least for me
On Sun, Mar 09, 2025 at 07:41:31PM -0400, Neal Gompa wrote: > > We should probably try and get this into Fedora proper, right? Ideally > > everything needed by Fedora infrastructure is in Fedora itself, it took us > > a few years to get there with mailman so the earlier we start the better > > > > Yes indeed, starting now would allow us to start on the right foot. Yes. Normal packaging should be a requirement for tools that are expected to be used by the standard Fedora packager or for Fedora infrastracture. For two separate reasons: - that software is easier to use and deploy, in particular to keep updated. - passing through a packaging review is a proof of minimal quality of the software. Going through the steps for packaging will uncover possible license problems, emedded libraries, and other shenanigans that might not go unnoticed as long as some build&deployment script is being used. And we want to get this info _before_ we commit to the tool. Zbyszek -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20250310.n.0 changes
OLD: Fedora-Rawhide-20250309.n.1 NEW: Fedora-Rawhide-20250310.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 3 Dropped packages:0 Upgraded packages: 20 Downgraded packages: 0 Size of added packages: 569.15 KiB Size of dropped packages:0 B Size of upgraded packages: 1.28 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 4.49 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20250309.n.1.iso = ADDED PACKAGES = Package: libxchange-1.0.0~rc5-1.fc43 Summary: Structured data representation and JSON support for C/C++ RPMs:libxchange libxchange-devel libxchange-doc Size:469.89 KiB Package: rust-strum0.26-0.26.3-1.fc43 Summary: Helpful macros for working with enums and strings RPMs:rust-strum0.26+default-devel rust-strum0.26+derive-devel rust-strum0.26+phf-devel rust-strum0.26+std-devel rust-strum0.26+strum_macros-devel rust-strum0.26-devel Size:50.83 KiB Package: rust-strum_macros0.26-0.26.4-1.fc43 Summary: Helpful macros for working with enums and strings RPMs:rust-strum_macros0.26+default-devel rust-strum_macros0.26-devel Size:48.43 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: asahi-audio-3.1-2.fc43 Old package: asahi-audio-3.1-1.fc43 Summary: PipeWire DSP profiles for Apple Silicon machines RPMs: asahi-audio Size: 1.78 MiB Size change: -14 B Changelog: * Mon Mar 10 2025 Davide Cavalca - 3.1-2 - Require lv2-triforce >= 0.2.0 due to a breaking change Package: ballerburg-1.2.3-1.fc43 Old package: ballerburg-1.2.2-4.fc42 Summary: Two players, two castles, and a hill in between RPMs: ballerburg Size: 392.33 KiB Size change: -1.07 KiB Changelog: * Sun Mar 09 2025 Andrea Musuruane - 1.2.3-1 - Updated to new upstream release Package: ckb-next-0.6.1-1.fc43 Old package: ckb-next-0.6.0-7.fc42 Summary: Unofficial driver for Corsair RGB keyboards RPMs: ckb-next Size: 5.76 MiB Size change: 477.28 KiB Changelog: * Sun Mar 09 2025 Artur Frenszek-Iwicki - 0.6.1-1 - Update to v0.6.1 - Switch to Qt6 Package: dosbox-staging-0.82.0-4.fc43 Old package: dosbox-staging-0.82.0-3.fc42 Summary: Modern continuation of DOSBox with advanced features RPMs: dosbox-staging Size: 10.91 MiB Size change: -41.53 KiB Changelog: * Sat Mar 08 2025 Otto Liljalaakso - 0.82.0-4 - Disable SSE2 and SSSE3 (rhbz#2347233) Package: duply-2.5.5-1.fc43 Old package: duply-2.5.3-3.fc42 Summary: Wrapper for duplicity RPMs: duply Size: 50.47 KiB Size change: -118 B Changelog: * Sun Mar 09 2025 Thomas Moschny - 2.5.5-1 - Update to 2.5.5. Package: kernel-6.14.0-0.rc5.20250307git00a7d39898c8.47.fc43 Old package: kernel-6.14.0-0.rc5.20250306git848e07631744.46.fc43 Summary: The Linux kernel RPMs: kernel kernel-core kernel-debug kernel-debug-core kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules kernel-debug-modules-core kernel-debug-modules-extra kernel-debug-modules-internal kernel-debug-uki-virt kernel-debug-uki-virt-addons kernel-devel kernel-devel-matched kernel-doc kernel-modules kernel-modules-core kernel-modules-extra kernel-modules-internal kernel-selftests-internal kernel-tools kernel-tools-libs kernel-tools-libs-devel kernel-uki-virt kernel-uki-virt-addons libperf libperf-devel perf python3-perf rtla rv Size: 1.18 GiB Size change: 5.55 MiB Changelog: * Fri Mar 07 2025 Fedora Kernel Team [6.14.0-0.rc5.00a7d39898c8.46] - Revert "redhat/configs: automotive: disable CONFIG_AIO" (Davide Caratti) - redhat/configs: automotive disable ARCH_TEGRA_241_SOC (Eric Chanudet) - rhel_files: ensure all qdiscs are in modules-core (Davide Caratti) [RHEL-79818] - redhat/configs: automotive: Disable MRP/8021Q_MVRP Protocol (Dorinda Bassey) - Linux v6.14.0-0.rc5.00a7d39898c8 * Fri Mar 07 2025 Fedora Kernel Team [6.14.0-0.rc5.00a7d39898c8.47] - apply -Wno-error=unterminated-string-initialization temporarily (Thorsten Leemhuis) - include/linux: Adjust headers for C23 (Jakub Jelinek) - x86/insn_decoder_test: allow longer symbol-names (David Rheinsberg) * Fri Mar 07 2025 Justin M. Forbes [6.14.0-0.rc5.20250307git00a7d39898c8.47] - Fix up some debug module loading issues due to BTF mismatch (Justin M. Forbes) Package: kmod-34.1-1.fc43 Old package: kmod-34-1.fc43 Summary: Linux kernel module management utilities RPMs: kmod kmod-devel kmod-libs Size: 987.41 KiB Size change: -309 B Changelog: * Sat Mar 08 2025 Josh Boyer - 34.1-1 - New upstream v34.1 - Resolves: rhbz#2350269 Package: libidn2-2.3.8-1.fc43 Old package: libidn2-2.3.7-3.fc42 Summary: Library to support IDNA2008 internationalized
Re: F43 Change Proposal: Switch to JXL format for Default Wallpaper (self-contained)
This change has been filed with FESCo https://pagure.io/fesco/issue/3376 for F42 as per the change owners guidance. Please note that the F42 change proposal deadline was January 14. Any changes landing after this date are assumed to be intended for F43. I do have a bad habit of assuming that changes in the ReadyForWrangler queue are for the next release if the deadlines have passed by a few weeks, which was the case when this one was submitted, but I didnt double check the release target so apologies for the confusion. On Sat, Mar 1, 2025 at 6:21 PM Luya Tshimbalanga wrote: > > On 2025-02-26 13:12, Michael Catanzaro wrote: > > On Mon, Feb 24 2025 at 01:54:15 PM -05:00:00, Neal Gompa > wrote: > > Didn't we already do this? I adapted KDE Plasma, MiracleWM, LXQt, and > COSMIC for this in F42 already. > > > And now GNOME is switching back to regular JPEG, see: > > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_2360630 > > https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/102 > > So if we're aiming for consistency, we have already failed > > > Author of the proposal here. It looks like the change recently happened > few days ago and the proposal is indeed for Fedora 42 Beta > which should give enough chances to find unexpected bugs before the final > release. Let remind Fedora used PNG format for default wallpaper for a very > long time > instead of JPEG. > > Thanks for sending the ticket here and looking at > > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_2360630 > > upstream JPEG-XL developers are very active investigating the root cause > linking both gdk-pixbuf-loader and djxl to the slowdown as highlighted > on https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_2363790 > > Should the issue fail to get solved upstream before the final release, we > can defer for Fedora 43 and switch back to PNG. It is up to FESCo. > > -- > Luya Tshimbalanga > Fedora Design Team > Fedora Design Suite maintainer > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Replacing regular file with directory on RPM upgrade ?
In the packaging guidelines we call out the problematic upgrades for replacing a directory with a non-directory, or replacing a symlink with a directory. We don't mention replacing a regular file with a directory though. Empirically that appears to be a broken scenario too. # ls -al /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt -rwxr-xr-x. 1 root root 10443848 Aug 29 2024 /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt # dnf update --enablerepo=updates-testing gmic-gimp ...snip... [5/8] Upgrading gmic-gimp-0:3.5.2-4.fc41.x86_64 >>> [RPM] failed to open dir gmic_gimp_qt of >>> /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/: cpio: mkdir failed - File exists >>> [RPM] unpacking of archive failed on file >>> /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/gmic_gimp_qt;67ceae1e: cpio: >>> mkdir failed - Directory not empty >>> Unpack error: gmic-gimp-0:3.5.2-4.fc41.x86_64 Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ? With regards, Daniel [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing regular file with directory on RPM upgrade ?
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a): Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ? It was always this way. The same for replacing a file with symlink. Or vice versa. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing regular file with directory on RPM upgrade ?
On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote: > Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a): > > Did something change in cpio, or has it always been broken for regular file > > to directory replacement too, and our docs were thus always incomplete ? > > It was always this way. > > The same for replacing a file with symlink. Or vice versa. Ok, so the packaging docs should say that /any/ change in file type between dir, regular & symlink needs special handling with lua scriptlets. I'll see about submitting a docs patch. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F43 Change Proposal: Deprecate the Gold Linker (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/DeprecateGoldLinker Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-deprecate-the-gold-linker-system-wide/146851 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 == The goal of this change is to deprecate the binutils-gold subpackage of the binutils package. This will allow its eventual removal from Fedora. == Owner == * Name: Nick Clifton * Email: ni...@redhat.com == Detailed Description == The GOLD linker is no longer being developed in the upstream GNU Binutils project. Given that there are now four linkers available to Fedora users (ld.bfd, ld.gold, lld, mold) deprecating one of them should not cause a lot of disruption and should reduce the maintenance burden for the binutils maintainers. == Feedback == I reached out to the maintainers of the packages that currently use gold. Almost all of them were willing to switch to another linker immediately: * ghc No longer uses gold. * llvm Uses gold for tests. Willing to change. * meson Only used for testing. Willing to drop as the test is not gold specific. * perfetto Uses gold. Might be a hard req. Maintainers checking with upstream developers. * pypy3.10 Willing to drop. Test build in a PR to make this change succeeded. https://src.fedoraproject.org/rpms/pypy3.10/pull-request/33 * python-torch No longer uses gold. * qt5-qtwebengine Willing to switch to another linker if it works * rust Gone as of rust-1.85.0-2.fc43 * swift-lang Uses gold. Package might become deprecated. == Benefit to Fedora == * Reduces the complexity of Fedora by removing a linker that is no longer needed. * Reduces the maintenance burden of the binutils package by removing a component that is no longer being developed upstream. * Simplifies a developer's experience by reducing the number of choices for a linker from 4 to 3. == Scope == * Proposal owners: Add the deprecated() tag to the binutils-gold subpackage of the binutils package in rawhide. Add a comment explaining why the gold linker is being deprecated. Bump the NVR and build. Wait for responses, if any, from other package maintainers. Make an announcement on the devel mailing list, informing developers that gold is now deprecated. Optional (I am not sure if this counts as part of the deprecation, or will require a separate change request): After the next Fedora release is out, change the binutils package so that it does not build gold by default. Instead it would need the builder to add the ''--with gold'' option. A release after that, remove the option to build gold entirely. * Other developers: For developers who are currently using the gold linker in their project(s), a decision will have to be made as to whether they should switch to a different linker or stay with gold. Since deprecation does not actually remove the linker from the distribution, not making any change will still work. For package maintainers who package(s) use gold a similar choice should be made although again not changing anything will still work. * Release engineering: [https://pagure.io/releng/issue/12622] There should be no need to change the installer or update package delivery because of this change. * Policies and guidelines: N/A (not needed for this Change) The packaging guidelines are linker agnostic, so there is no need to alter them because of this change. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: The change aligns with the strategy of increasing the number of active contributors in the sense that it simplifies the binutils package, making it easier to maintain, and it removes one of the linker choices available to developers, making their choice simpler. == Upgrade/compatibility impact == There should be no affect on users or developers upgrading from earlier versions of Fedora. Since the binutils-gold rpms will still be available (albeit marked as deprecated) no-one should notice any change. The only possible exception to this is for developers who are creating new packages for Fedora and who want to use gold. They will need to switch to a different linker. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == No special hardware, data or the like is needed to test this change. In fact in theory no testing is necessary at all. Since the change is to add a ''deprecated()'' tag to the binutils-gold sub-package the only people who will be affected are packagers who want to add a dependency upon gold. So all existing packages should be unaffected. As for actual testing I guess a dummy package could be created that has a ''BuildRequires: binutils-gold'' dependency and
Re: force merging of the remaining pull requests for sysusers
On Mon, Mar 03, 2025 at 10:43:25AM +, Zbigniew Jędrzejewski-Szmek wrote: > Below is the list of PRs to merge. They all pass CI or the CI failed > for unrelated reasons. I'll look at each PR before merging, so if > there is an ongoing discussion or requests from the maintainers, I'll > not merge the PR. (Some are false positives in the sense that there > already are comments there. I don't have a automatic way of filtering > those out.) I merged most of the PRs. A few that remain: https://src.fedoraproject.org/rpms/boinc-client/pull-request/5 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/condor/pull-request/4 - rebased, ftbfs https://src.fedoraproject.org/rpms/copr-dist-git/pull-request/1 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/erlang/pull-request/4 - rebased https://src.fedoraproject.org/rpms/freeipa/pull-request/24 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/ganglia/pull-request/2 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/koji/pull-request/24 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/mariadb10.11/pull-request/14 - unclear ftbfs https://src.fedoraproject.org/rpms/mysql8.0/pull-request/6 - rebased https://src.fedoraproject.org/rpms/nats-server/pull-request/2 - unclear ftbfs https://src.fedoraproject.org/rpms/pcp/pull-request/29 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/smokeping/pull-request/1 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/svxlink/pull-request/3 - rebased https://src.fedoraproject.org/rpms/systemtap/pull-request/31 - maintainer indicated a different approach is wanted https://src.fedoraproject.org/rpms/wesnoth/pull-request/3 - rebased https://src.fedoraproject.org/rpms/znc/pull-request/8 - maintainer indicated a different approach is wanted We're getting close ;) Zbyszek > As discussed previously, those PRs are for rawhide, but also work for > F42. They are not compatible with F41- or EPEL. They can be used as a > good basis for making a version that backwards compatible, for folks > that want to maintain a single branch. Please use/change the PR as you > see fit, just let me know in a comment or close the PR. > > https://src.fedoraproject.org/rpms/NetworkManager-fortisslvpn/pull-request/2 > https://src.fedoraproject.org/rpms/NetworkManager-openvpn/pull-request/6 > https://src.fedoraproject.org/rpms/abrt/pull-request/45 > https://src.fedoraproject.org/rpms/addrwatch/pull-request/3 > https://src.fedoraproject.org/rpms/akmods/pull-request/24 > https://src.fedoraproject.org/rpms/amanda/pull-request/10 > https://src.fedoraproject.org/rpms/anyterm/pull-request/1 > https://src.fedoraproject.org/rpms/apt/pull-request/17 > https://src.fedoraproject.org/rpms/asterisk/pull-request/22 > https://src.fedoraproject.org/rpms/autossh/pull-request/2 > https://src.fedoraproject.org/rpms/avahi/pull-request/18 > https://src.fedoraproject.org/rpms/bacula/pull-request/5 > https://src.fedoraproject.org/rpms/barman/pull-request/2 > https://src.fedoraproject.org/rpms/beanstalkd/pull-request/2 > https://src.fedoraproject.org/rpms/beep/pull-request/2 > https://src.fedoraproject.org/rpms/bind9-next/pull-request/11 > https://src.fedoraproject.org/rpms/bitcoin-core/pull-request/2 > https://src.fedoraproject.org/rpms/boinc-client/pull-request/5 > https://src.fedoraproject.org/rpms/bzflag/pull-request/1 > https://src.fedoraproject.org/rpms/c-icap/pull-request/1 > https://src.fedoraproject.org/rpms/ccache/pull-request/22 > https://src.fedoraproject.org/rpms/cjdns/pull-request/5 > https://src.fedoraproject.org/rpms/clamav/pull-request/41 > https://src.fedoraproject.org/rpms/condor/pull-request/4 > https://src.fedoraproject.org/rpms/copr-backend/pull-request/2 > https://src.fedoraproject.org/rpms/copr-dist-git/pull-request/1 > https://src.fedoraproject.org/rpms/copr-frontend/pull-request/3 > https://src.fedoraproject.org/rpms/copr-keygen/pull-request/3 > https://src.fedoraproject.org/rpms/crack/pull-request/1 > https://src.fedoraproject.org/rpms/darkstat/pull-request/3 > https://src.fedoraproject.org/rpms/davfs2/pull-request/2 > https://src.fedoraproject.org/rpms/dbus-broker/pull-request/15 > https://src.fedoraproject.org/rpms/dhcp-forwarder/pull-request/1 > https://src.fedoraproject.org/rpms/dist-git/pull-request/1 > https://src.fedoraproject.org/rpms/dlt-daemon/pull-request/1 > https://src.fedoraproject.org/rpms/dnsdist/pull-request/1 > https://src.fedoraproject.org/rpms/erlang/pull-request/4 > https://src.fedoraproject.org/rpms/etcd/pull-request/10 > https://src.fedoraproject.org/rpms/fapolicyd/pull-request/12 > https://src.fedoraproject.org/rpms/firebird/pull-request/4 > https://src.fedoraproject.org/rpms/freeipa/pull-request/24 > https://src.fedoraproject.org/rpms/ganglia/pull-request/2
Re: F43 Change Proposal RPM 6.0 (system-wide)
On Mon, Mar 10, 2025, at 5:44 AM, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855 > > 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 == > Update RPM to the upcoming 6.0 major release. > > == Owner == > * Name: [[User:Pmatilai| Panu Matilainen]] > * Email: pmati...@redhat.com > > > == Detailed Description == > Update RPM to the upcoming 6.0 release for several security improvements. > snip > > == Benefit to Fedora == > > The major theme in 6.0 is increased security and related improvements: > snip > * support for signing with Sequoia-sq as an alternative to GnuPG Is this not already supported in the current RPM? I seem to remember dealing with issues due to us using sequoia-sq and it being stricter with some non compliant signatures on third party packages signed with other cryptographic libraries Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://michel-slm.name/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F43 Change Proposal RPM 6.0 (system-wide)
On Mon, Mar 10, 2025 at 12:44:44PM +, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855 > > 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 == > Update RPM to the upcoming 6.0 major release. > > == Owner == > * Name: [[User:Pmatilai| Panu Matilainen]] > * Email: pmati...@redhat.com > == Benefit to Fedora == > > The major theme in 6.0 is increased security and related improvements: > * enforcing signature checking on by default snip > * support for automatic signing on package build (mainly for local use) Can someone elaborate on how this will work in practice ? Will RPM be autogenerate a local key per machine for the purpose of automatic signatures, that is already in the trusted keyring ? ie, so that 'rpmbuild ...spec && sudo rpm -ivh ...' will "just work" ? If so, how will this work if you add mock into the mix? Will the mock env use the local signing key from the "host" install, as opposed to a different local signing key in the mock chroot ? Or will we need to get the key used by mock and register it on the "host", in order to then install the just built package ? Also same question, but building in mock and then transferring the package over to a different machine for installation ? Can the local signing key from mock be easily transferred too ? > == Upgrade/compatibility impact == > > * Existing package build+install workflows may need to be adjusted due > to enforced signature checking being the default. > * 3rd party scripts and tools may need adjusting to the new key > addressing format and other signature related output changes. I presume the intent is that the (probably many) regressions that these changes will trigger, will *not* be considered justification to trigger the contingency plan, unless the impact unexpectedly severe ? IOW, we're fully expecting stuff to break and users are expected to do the work to fix compatibility asap. > == Contingency Plan == > > * Contingency mechanism: Revert back to RPM 4.20 > * Contingency deadline: Beta freeze > * Blocks release? No With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self introduction & looking for sponsor for ccls
Hi all, Yes, Dan was kind enough to tell me exactly this. I will take me some time, though, as I have some other priorities. Thanks and kind regards, Antonio El 8/3/25 a las 14:23, Michel Lind escribió: Hi Antonio, First of all, welcome! On Thu, Mar 6, 2025, at 7:27 AM, Antonio wrote: Hi Dan! This is indeed appreciated. No better sponsor! This will be my first contribution. I've read [1] and followed all instructions there, but I'm stuck. What should I do now? Because the package has been retired for too long, you need to submit it for review request again as if it's a new package (base it on the retired spec with any improvement that's necessary) Mark the issue as blocking FE-NEEDSPONSOR, and probably reply here or to Dan with the issue URL so he sees it. Best regards, -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Schedule for Tuesday's FESCo Meeting (2025-03-11)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2025-03-11 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #3369 [FastTrack] Update Emacs to 30.1 in active non rawhide branches https://pagure.io/fesco/issue/3369 APPROVED (6, 0, 0) #3367 Late Change for F42: The Copilot Runtime Verification Framework https://pagure.io/fesco/issue/3367 APPROVED (5, 0, 0) = Followups = #3364 F42 Incomplete Changes Report https://pagure.io/fesco/issue/3364 = New business = = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Fabio Alessandro "Fale" Locati fale.io -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Next Open NeuroFedora Meeting: Monday, 10 March 2025 (today) at 13:00 UTC
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 10 March at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20250310T13&p1=1440&ah=1 or you can use this command in a terminal: $ date -d 'Monday, March 10, 2025 13:00 UTC' The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2025/03/10/next-open-neurofedora-meeting-10-march-2025-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F43 Change Proposal: Retire gtk3-rs, gtk-rs-core v0.18, and gtk4-rs v0.7 (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Retire_gtk3-rs,_gtk-rs-core_v0.18,_and_gtk4-rs_v0.7 Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-retire-gtk3-rs-gtk-rs-core-v0-18-and-gtk4-rs-v0-7-self-contained/146853 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 == The Rust bindings for GTK3 (and related libraries) are unmaintained upstream, and are no longer updated in lockstep with bindings for GLib and other related libraries. The packages for gtk3-rs were previously [https://fedoraproject.org/wiki/Changes/Deprecate_gtk3-rs deprecated]. This is the next step - the removal of the packages for gtk3-rs, and the compat packages for old versions of gtk-rs-core (v0.18) and gtk4-rs (v0.7) that are associated with them. == Owner == * Name: [[User:Decathorpe| Fabio Valentini]] * Email: decathorpe (at) gmail (dot) com == Detailed Description == The Rust bindings for GTK3 have been officially on basic maintenance only since the release of [https://gtk-rs.org/blog/2023/02/10/new-release.html gtk-rs 0.17], and the last release that included updated GTK3 bindings was [https://gtk-rs.org/blog/2023/08/28/new-release.html gtk-rs 0.18]. As a result, the most recent version continues to pull in compat packages for version 0.18 of gtk-rs-core (Rust bindings for GLib, pango, cairo, etc.), which has not been maintained either, since it was obsoleted by versions 0.19 and 0.20 upstream. These Rust bindings receive regular fixes for safety and correctness issues - continuing to depend on old versions is not ideal, since only critical fixes are backported to the Fedora packages for these obsolete versions (if that is even possible). The upstream project does not backport fixes or release new versions of older release branches at all. This also affects packages that continue to depend on version 0.7 of the bindings for GTK4. However, packages that only depend on crates from gtk-rs-core or gtk4-rs do have a migration path to newer versions of these crates, whereas packages that depend on crates from gtk3-rs need to port from GTK3 to GTK4 first. == Feedback == N/Y == Benefit to Fedora == The Rust bindings for GTK3 - and gtk-rs 0.18 in general - are obsolete. This Change ensures that Fedora ships less obsolete software and / or fewer obsolete versions of packages. == Scope == * Proposal owners: Retire the following packages: gtk3-rs / libhandy-rs packages (unmaintained upstream): rust-atk rust-atk-sys rust-gdk rust-gdk-sys rust-gtk rust-gtk-sys rust-libhandy rust-libhandy-sys gtk-rs-core v0.18 compat packages: rust-cairo-rs0.18 rust-cairo-sys-rs0.18 rust-gdk-pixbuf0.18 rust-gdk-pixbuf-sys0.18 rust-gio0.18 rust-gio-sys0.18 rust-glib0.18 rust-glib-sys0.18 rust-glib-build-tools rust-gobject-sys0.18 rust-graphene-rs0.18 rust-graphene-sys0.18 rust-pango0.18 rust-pango-sys0.18 rust-pangocairo0.18 rust-pangocairo-sys0.18 gtk4-rs v0.7 / libadwaita-rs v0.5 compat packages: rust-gdk4_0.7 rust-gdk4-sys0.7 rust-gsk4_0.7 rust-gsk4-sys0.7 rust-gtk4_0.7 rust-gtk4-sys0.7 rust-libadwaita0.5 rust-libadwaita-sys0.5 The Change Owner(s) will file Pull Requests for dependent packages to move to newer versions of those libraries, where possible. === Other developers === There are some applications in Fedora that depend on these old bindings: * helvum → libadwaita-rs v0.5 and gtk-rs-core v0.18 compat packages * squeekboard → obsolete GTK3 bindings and gtk-rs-core v0.18 compat packages * system76-keyboard-configurator → obsolete GTK3 bindings and gtk-rs-core v0.18 compat packages * wildcard → libadwaita-rs v0.5 and gtk4-rs v0.7 compat packages All of these packages are either co-maintained by the Rust SIG or are maintained by a member of the Rust SIG. Most of these projects already have begun work on porting to a newer version of gtk-rs, or have been aware that continuing to depend on the obsolete GTK3 bindings is a problem for years: * helvum: https://gitlab.freedesktop.org/pipewire/helvum/-/commit/f325595 * squeekboard: https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/64 * system76-keyboard-configurator: https://github.com/pop-os/keyboard-configurator/issues/133 * wildcard: https://gitlab.gnome.org/World/Wildcard/-/issues/42 Packages that will not or cannot be ported to a newer version of gtk-rs in time - for example because it would also involve a port from GTK3 to GTK4 - will be broken, and should likely also be retired from Fedora. === Release engineering === N/A (not needed for this Change) === Policies and guidelines === N/A (not needed for this Change) === Trademark approval === N/A (not needed for this Change) === Alignme
Re: Use a buildroot override here?
Michal Domonkos wrote on 2025/03/10 21:27: Hello, I'd like to submit a F42 update (rpm-4.20.1-1.fc42) but, in order for the build to succeed, it requires a new build of gcc which fixes a failure on i686 [1]. The respective gcc update [2] is, however, currently on hold, due to the pending F42 freeze. Creating a side-tag and tagging the new gcc build in makes my build succeed but I'm not able to submit a bodhi update from such a side-tag, due to that pending gcc update already existing. What's the proper way, if any, to submit my update for testing while the freeze is still in effect? Should I use a buildroot override instead (which seems to be generally discouraged nowadays)? Thanks, [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=130084538 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2025-6a12d86df4 Untagged gcc-15.0.1-0.9.fc42 from gcc-15.0.1-0.9.fc42 (It can be done yourself by $ koji untag-build f42-build-side-107435 gcc-15.0.1-0.9.fc42 but for now I did it) Regards, Mamoru -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F43 Change Proposal: Migrate to lastlog2 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/Migrate_to_lastlog2 Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-migrate-to-lastlog2-system-wide/146854 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 == Migrate lastlog and all functionality associated with it (e.g. pam_lastlog, the PAM service files) to lastlog2. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]] * Email: == Detailed Description == The Year 2038 problem (Y2038) poses a significant threat to systems relying on 32-bit time representations. It's crucial to address this before it impacts Fedora. This proposal suggests replacing the current lastlog utility with lastlog2, a robust and widely adopted solution already integrated into distributions like Debian and openSUSE. lastlog reports the last login of a given user or of all users who did ever login on a system. The standard `/var/log/lastlog` implementation using `lastlog.h` from glibc uses a 32bit time_t in struct lastlog on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries). So even if you have a pure 64bit system, on many architectures using glibc this leads to the [https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ Y2038 problem]. lastlog2 is a Y2038 safe implementation of lastlog and it is considered as the natural replacement. lastlog2 offers a comprehensive solution, including not just the lastlog2 binary for interacting with user login information, but also a dedicated library and a PAM module for seamless integration and accurate user tracking. Critically, lastlog2 provides a migration path for existing lastlog data. == Feedback == This Fedora System-Wide Change is open to feedback and other proposals from the community. == Benefit to Fedora == * Y2038 safe: it addresses the core issue by using a time representation that avoids the Y2038 overflow. * SQLite3 backend: it leverages a modern and efficient database for storing login information. * PAM module integration: data collection is handled exclusively through a PAM module, allowing any tool to utilize the information without requiring modifications to existing packages. This ensures broad compatibility and avoids cascading changes. * Backward compatibility: output is designed to be as compatible as possible with the traditional lastlog format, minimizing disruption to existing workflows. * Data migration: it provides a mechanism to import existing data from the legacy `/var/log/lastlog` file, preserving valuable login history. * Scalability: the database size scales with the number of users, not the largest UID, offering improved performance and resource utilization, especially in environments with sparse UID allocation. This change offers a proactive and well-supported solution to the Y2038 problem within Fedora, ensuring the continued reliability and security of the system. In short, lastlog2 is part of the util-linux project, which Fedora has been using for years, and which has been accepted by different communities such as Debian or OpenSuse as the ideal replacement for lastlog. == Scope == * Proposal owners: shadow-utils, PAM and util-linux projects need to change their configuration to stop providing lastlog functionality and start providing lastlog2. authselect project needs to replace pam_lastlog by pam_lastlog2 in the PAM stack and update fedora content accordingly. Finally, util-linux needs to migrate the existing database from lastlog to lastlog2 format during the upgrade process. * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/12608 #12608] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == Nothing will be affected, since the old database format from lastlog will be automatically migrated to the new lastlog2 format. == How To Test == Two different scenarios come to my mind: # New system: once the system is correctly installed authenticate as a user and run `lastlog2` for this user. The timestamp of the last login should match the one that recently happened. # Old system: once the system is correctly updated authenticate as root and run `lastlog2` for another user. The timestamp of the last login should have happened before the update happened. == User Experience == `lastlog` and `pam_lastlog` don't exist anymore and are replaced by `lastlog2` and `pam_lastlog2`. They should behave in a similar manner to the aforementioned artifacts, thus no other change will be experienced by the user. == Dependencies == There are no other dependencies. == Contingency Plan == * Contingency mechanism: If any change was committed revert it. * Contingency deadline: Just before beta freeze. * Blocks
F42 Change Proposal: Copilot Runtime Verification Framework (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Copilot_Runtime_Verification_Framework Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-copilot-runtime-verification-framework-self-contained/146848 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. In this instance, this proposal has been previewed by the Fedora Engineering Steering Committee and members of Fedora QA as it is a late change, https://pagure.io/fesco/issue/3367, and has been provisionally approved as acceptable for F42 release, pending community feedback. If any feedback is received that alters the change proposal in a significant way, it will be resubmitted to FESCo for a further review and vote. == Summary == [https://copilot-language.github.io/ Copilot Language and Runtime Verification System] is a stream-based runtime-verification framework for generating hard real-time C code. == Owner == * Name: [[User:fdedden|Frank Dedden]] * Email: * Name: [[User:Petersen|Jens Petersen]] * Email: == Detailed Description == Copilot is a realtime programming language and Runtime Verification framework, developed for NASA. It allows users to write concise programs in a simple but powerful way using a stream-based approach. Programs can be interpreted for testing, or translated C99 code to be incorporated in a project, or as a standalone application. The C99 backend ensures us that the output is constant in memory and time, making it suitable for systems with hard realtime requirements. == Feedback == == Benefit to Fedora == This is a new feature in Fedora which will of interest to those developing specific critical embedded systems requiring a high level of software assurance. == Scope == * Proposal owners: ** build the copilot stack for Rawhide/F42: version 3.19 is packaged [done] * 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 == == Early Testing (Optional) == == How To Test == * `sudo dnf install ghc-copilot-devel` * follow the documentation below for tutorial examples == User Experience == Users will be able to easily install the Copilot verification framework and test it. == Dependencies == == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://copilot-language.github.io/documentation.html * https://github.com/Copilot-Language/copilot * https://ntrs.nasa.gov/citations/20240010993 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self introduction & looking for sponsor for ccls
Hi all, So I've been doing some experiments with latest ccls version on COPR [1] and this is what I found: 1.- It won't build on rawhide rawhide currently sports clang/llvm v20, and ccls simply fails to build with that (this would require changes upstream since the LLVM libs have changed). 2.- It builds in _some_ platforms with clang/llvm v17 - Builds go though in fedora40 (aarch64, x86_64), but rpm/check-rpaths complains [2] (even though I used "Requires: llvm17-libs"). - On rawhide/x86_64 the clang c++/v17 compiler seems to be broken. [3] - On rawhide/aarch64 the LLVM17 libraries seem incompatible (even though they are good in fedora 40). [4] So I think in order to have ccls up an running we'll have to build an older clang/llvm combination (ccls tests require clang v6). But building clang & llvm v6 just to have ccls is probably overkill. So things look bad for ccls. I'll do some other experiments, and see if there're any plans to support LLVM20 upstream in the future. Any other ideas/suggestions to have ccls running are welcome. Thanks and kind regards, Antonio [1] https://copr.fedorainfracloud.org/coprs/vieiro/ccls/build/8747711/ [2] ERROR 0010: file '/usr/bin/ccls' contains an empty runpath in [/usr/lib64/llvm17/lib:] https://download.copr.fedorainfracloud.org/results/vieiro/ccls/fedora-40-aarch64/08747711-ccls/builder-live.log.gz https://download.copr.fedorainfracloud.org/results/vieiro/ccls/fedora-40-x86_64/08747711-ccls/builder-live.log.gz [3] https://download.copr.fedorainfracloud.org/results/vieiro/ccls/fedora-rawhide-x86_64/08747711-ccls/builder-live.log.gz -- Check for working CXX compiler: /usr/lib64/llvm17/bin/clang++ - broken CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message): The C++ compiler "/usr/lib64/llvm17/bin/clang++" is not able to compile a simple test program. [4] /usr/lib64/llvm17/include/llvm/ADT/SmallVector.h:582:47: error: no type named 'const_iterator' in 'llvm::SmallVectorTemplateBase' 582 | using const_iterator = typename SuperClass::const_iterator; | ~^~ https://download.copr.fedorainfracloud.org/results/vieiro/ccls/fedora-rawhide-aarch64/08747711-ccls/builder-live.log.gz El 10/3/25 a las 10:15, Antonio escribió: Hi all, Yes, Dan was kind enough to tell me exactly this. I will take me some time, though, as I have some other priorities. Thanks and kind regards, Antonio El 8/3/25 a las 14:23, Michel Lind escribió: Hi Antonio, First of all, welcome! On Thu, Mar 6, 2025, at 7:27 AM, Antonio wrote: Hi Dan! This is indeed appreciated. No better sponsor! This will be my first contribution. I've read [1] and followed all instructions there, but I'm stuck. What should I do now? Because the package has been retired for too long, you need to submit it for review request again as if it's a new package (base it on the retired spec with any improvement that's necessary) Mark the issue as blocking FE-NEEDSPONSOR, and probably reply here or to Dan with the issue URL so he sees it. Best regards, -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
