, glibc ABI updates coming to Fedora releases

The types defined in and contain seconds-since-epoch fields. Historically, those fields are 32 bits wide. There are two issues with that: 1. The field width incorrectly changed to 64 bits on i686 when building with _TIME_BITS == 64 (an unusual configuration for Fedora builds). This is

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

Carlos Rodriguez-Fernandez wrote: > Regarding the proposal as a whole, I think the proposal idea makes a lot > of sense, but for apps depending on system jar libraries, there should > be a way to specify that the app depends on a specific java bytecode > version range. System libraries packages

Re: XDG_BASE_DIRECTORY specification

The XDG spec [0] says that, if the env vars are unset, or set to an empty value, a compliant application should fall back to the default value given by the spec. So I guess the answer is that, since we don't need to use non-standard directories, setting the env vars to the same value as the

Introducing Fedora Change Proposal 'Blueprints' (in association with Fedora QA)

Hi Folks, Sumantro Mukherkjee and I have been working on a concept for the last few weeks on how we could try to bridge the gap between changes for the upcoming release(s) of Fedora being announced and developed, and then tested by QA later in the release cycle. What we have come up with is

XDG_BASE_DIRECTORY specification

Hello, I recently received a PR against mame, adding support for XDG_CONFIG_HOME, XDG_STATE_HOME and XDG_DATA_HOME [1]. It appears that these folders are not defined by default in Fedora, at least not in Gnome. Is this expected? If it is something which needs to be defined by the user

[Fedocal] Reminder meeting : ELN SIG

Dear all, You are kindly invited to the meeting: ELN SIG on 2024-05-03 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10568/ -- ___ devel

mock bootstrap broken for EL8-based targets without use_bootstrap_image - what's a proper fix?

Seems like because filelists are no longer part of the default metadata in Fedora's dnf, python3-dnf cannot be installed because it depends on ... /usr/libexec/platform-python This is with ``` config_opts['use_bootstrap_image'] = False ``` as I'm running mock inside a podman container

[Test-Announce] Fedora-IoT 41 RC 20240502.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora-IoT 41 RC 20240502.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see:

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

On Thu, Apr 25, 2024 at 11:42:57AM +0200, Jan Kolarik wrote: > upgrades from F41 to F42. Before executing the system-upgrade, users are > anyway advised to ensure that all installed packages are fully updated. I don't believe GNOME Software enforces this. (There was some debate about whether

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote: > On 5/2/24 14:34, Gary Buhrmaster wrote: > > While I follow the philosophy of updating > > regularly, there are likely some who install Fnn, and > > never update, and then would expect an update to > > Fnn+2 to work without

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

On Thu, May 2, 2024 at 6:59 AM Kevin Kofler via devel wrote: > > Carlos Rodriguez-Fernandez wrote: > > Regarding the proposal as a whole, I think the proposal idea makes a lot > > of sense, but for apps depending on system jar libraries, there should > > be a way to specify that the app depends

Re: Notice of intent to orphan salt

Exactly. --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with Proton Mail secure email. On Thursday, May 2nd, 2024 at 2:03 PM, Michel Lind wrote: > On 5/2/24 1:55 PM, Gwyn Ciesla via

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

On 5/2/24 14:34, Gary Buhrmaster wrote: While I follow the philosophy of updating regularly, there are likely some who install Fnn, and never update, and then would expect an update to Fnn+2 to work without issue(s). -- The CLI update strongly suggests doing 'dnf update --refresh' before

Re: SPDX Statistics - L'Aigle meteorite edition

On Fri, Apr 26, 2024 at 08:20:43PM +0200, Miroslav Suchý wrote: > Graph of these data with the burndown chart: > > https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing [...] > New projection when we will be finished is 2025-04-06 (+5 days from last

Notice of intent to orphan salt

salt-master has been broken on Fedora since Fedora 39, when we moved to Python 3.12.  https://bugzilla.redhat.com/show_bug.cgi?id=2250197 Upstream doesn't seem particularly interested in supporting anything outside of their 'onedir' packaging, which bundles it's own Python stack. Most of the

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

On Thu, May 2, 2024 at 6:14 PM Matthew Miller wrote: > I don't believe GNOME Software enforces this. (There was some debate about > whether doing two updates in a row was really useful, if I remember.) That > may be a big source of pain. As I recall, *much* of the time it does not matter, but

Re: Notice of intent to orphan salt

On 5/2/24 1:55 PM, Gwyn Ciesla via devel wrote: salt-master has been broken on Fedora since Fedora 39, when we moved to Python 3.12. https://bugzilla.redhat.com/show_bug.cgi?id=2250197 Upstream doesn't seem particularly interested in

Re: SPDX Statistics - L'Aigle meteorite edition

On Thu, May 2, 2024 at 8:11 PM Matthew Miller wrote: > > If we extrapolate linearly just from 2023-09-29 on, that gives an end-date > of 2026-02-22. And linearly is probably optimistic too, given the classic > "last 10% is 90% of the time" thing. That sounds reasonable, but we'll also be

Re: SPDX Statistics - L'Aigle meteorite edition

On Thu, May 2, 2024 at 6:11 PM Matthew Miller wrote: > Just eyeballing the prediction graph in the Google doc, it looks like the > linear approximation is distorted by the big drop in "non-trivial" last > September. And, the slope for "converted" is pretty steep before that, but > significantly

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

I have dealt with bugs where a library runs well in JRE 11, but crashes when run in JRE 17 because the InetSocketAddress implementation changed. Totally unrelated with the language features or bytecode versions. Nevertheless, even in that case, if I bring in that library from the distro repo,

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

Christopher wrote: > So, I actually think that building with the *latest* JDK that we ship, > and using the `--release` flag during compilation is actually safer > than building against the lowest that we support, because it is most > likely to strictly enforce correct byte code generation for the

Fedora rawhide compose report: 20240502.n.0 changes

OLD: Fedora-Rawhide-20240501.n.0 NEW: Fedora-Rawhide-20240502.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 8 Dropped packages:2 Upgraded packages: 60 Downgraded packages: 2 Size of added packages: 405.57 KiB Size of dropped packages

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

Sorry, with "package" I mean a *new* package for jdk 17, depending on a lib built and tested only for jdk 8 to 11. Basically, that metadata in the rpm for the lib would not have that runtime information for any new package wanting to depend on it targeted for jdk 17. On 5/2/24 18:35, Kevin

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

Carlos Rodriguez-Fernandez wrote: > How could that be expressed so that those are caught quickly at build > time? Someone wants to depend on a java lib that has been tested only in > JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa, > for example. Perhaps, the only feasible

Re: SPDX Statistics - L'Aigle meteorite edition

On 4/26/24 11:20, Miroslav Suchý wrote: New projection when we will be finished is 2025-04-06 (+5 days from last report).  Pure linear approximation. Such a linear approximation, based on the entire tracked history, is the second worst possible estimate. (The worst possible estimate is the

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

On Thu, May 2, 2024 at 9:24 PM Kevin Kofler via devel wrote: > > Christopher wrote: > > So, I actually think that building with the *latest* JDK that we ship, > > and using the `--release` flag during compilation is actually safer > > than building against the lowest that we support, because it

[Bug 2278602] New: perl-Gtk3-0.038-11.fc41 FTBFS: t/overrides.t fails: loader: Image type “xpm” is not supported

https://bugzilla.redhat.com/show_bug.cgi?id=2278602 Bug ID: 2278602 Summary: perl-Gtk3-0.038-11.fc41 FTBFS: t/overrides.t fails: loader: Image type “xpm” is not supported Product: Fedora Version: rawhide URL:

[rpms/perl] PR #13: fixed perl_requires and libperl_requires macros

mspacek commented on the pull-request: `fixed perl_requires and libperl_requires macros` that you are following: `` @huakim Again, what are you trying to do? The duplicate PR, new macros without discussion and usage. We need a discussion about it before merging. `` To reply, visit the link

[Bug 2264428] perl-Net-DNS-1.45 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2264428 --- Comment #5 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Net-DNS-1.45-1.fc38.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=117153193 -- You are

[Bug 2277612] perl-Test-Smoke-1.82 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2277612 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from

[Bug 2264428] perl-Net-DNS-1.45 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2264428 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Net-DNS-1.44 is|perl-Net-DNS-1.45 is

[Bug 2264428] perl-Net-DNS-1.45 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2264428 --- Comment #4 from Upstream Release Monitoring --- Created attachment 2030870 --> https://bugzilla.redhat.com/attachment.cgi?id=2030870=edit Update to 1.45 (#2264428) -- You are receiving this mail because: You are on the CC list for

[Bug 2278464] perl-Devel-CheckOS-2.01 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2278464 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Devel-CheckOS-2.00 is |perl-Devel-CheckOS-2.01

[Bug 2277612] perl-Test-Smoke-1.82 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2277612 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version|

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following builds have been pushed to Fedora EPEL 7 updates-testing stb-0-0.45.20240213gitae721c5.el7 Details about builds: stb-0-0.45.20240213gitae721c5.el7 (FEDORA-EPEL-2024-c66806f4ad) Single-file

[Bug 2278779] New: perl-Test-Compile-3.3.2 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2278779 Bug ID: 2278779 Summary: perl-Test-Compile-3.3.2 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Compile Keywords: FutureFeature, Triaged

[EPEL-devel] Fedora EPEL 8 updates-testing report

The following Fedora EPEL 8 Security updates need testing: Age URL 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f282573e05 et-6.2.8-2.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing libmongocrypt-1.10.0-1.el8 mongo-c-driver-1.27.0-1.el8