date:20240502

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

2024-05-02 Thread Christopher

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 is most
> > likely to strictly enforce correct byte code generation for the target
> > JRE.
>
> The problem is, without ALSO installing the JDK for the targeted version AND
> explicitly pointing -bootclasspath to that JDK, this does NOT catch code
> trying to use class library features (as opposed to language or bytecode

For context, the use of the bootclasspath is only applicable to
building for Java 8. (A related question that I don't know the answer
to: how much longer is Fedora going to include Java 8?)

However, I believe you are incorrect. JEP 247, which added the
`--release` flag, specifically made it replace the need for using
`-bootclasspath`. See https://openjdk.org/jeps/247 ; The problem I
described in the email you're replying to is specifically that the
`-bootclasspath` with JDK 8 will pick up class APIs *outside* of the
"", whereas the use of `--release 8` strictly
enforces that only the "" are available. This
is what I meant when I said that using the `--release` flag more
strictly enforces Java 8 language compliance than building with JDK 8.
I stand by that statement. It is the `-bootclasspath` that leads
people astray, and thus it has been removed for Java 9 and later.

> features) from the newer JDK, and worse, in rare occasions, even if the
> source code is in principle compatible with the targeted older Java, when
> compiled with a newer compiler and older target release, it will fail to
> actually run (!) with the latter (because the compiler picks up a subclass
> override of a method added in the newer Java instead of the baseclass method
> that was always available and, for performance reasons, tries calling the
> override explicitly rather than going through the virtual method lookup).
> One example of that latter issue is NetBeans, where versions 12.5 and 12.6
> were supposed to be compatible with Java 8, but some upstream-published
> binaries of 12.5 and all of 12.6 do not actually work properly on it because
> they were built with Java 11 in "-release 8" mode: some editor features fail
> with runtime exceptions. See
> https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They
> "fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x
> release was ever issued.)

The CharBuffer/ByteBuffer issues mentioned in that are specifically
issues that the use of `--release` resolves. I have fixed this in
several projects already who encountered this same issue. Digging into
the tickets you linked, it looks like the problem with that issue was
that the binaries were built with JDK 11 *without* the use of the
`--release` flag... or rather, it looks like somebody tried to use the
`--release` flag, but they also used `-Xbootclasspath`, which ended up
*disabling* the `--release` behavior. The problem isn't the use of
`--release`, it's the *non*-use of it... or the broken use of it,
because boot class path options are still being used when they
shouldn't. So again, I assert that it's the `-bootclasspath` option
that is leading people astray.

>
> So I am AGAINST systematically using "-release" without "-bootclasspath",
> even though that works in most cases and is often successfully used in
> production (me and my employer use it, too, but on projects we control where
> we will fix the source code or add a workaround to it if any issues come up
> from that, not systematically on repackaging third-party projects). The
> compiler even warns about the missing "-bootclasspath". And the potential to
> cause subtle misbehavior that is a pain to debug is just too high,
> especially if we have the actual older JDK available and could just
> BuildRequire the correct version.

This doesn't make sense. The purpose of the `--release` flag was to
replace the need for `-bootclasspath`. The `-bootclasspath` doesn't
exist anymore for JDK 9 compliance and later, and using it *breaks*
the compliance checks done by `--release` by allowing the built-in
checks to be overridden.

As for the warning you've mentioned... I'm not sure what warning
you're referring to. I've never seen such a warning and have been
using `--release` for a long time now.

Respectfully, I think you're wrong on some of the points you're
raising. Please look into the points I've made, and correct me if it
turns out that I'm the one in error. Getting this correct is important
to me, and I think it matters for Fedora's Java packaging guidelines,
even if it doesn't end up affecting the decision about Requires. So,
I'd like to know if I'm wrong.

>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to

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

2024-05-02 Thread Carlos Rodriguez-Fernandez

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 Kofler via devel wrote:

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 way to detect that case is with
CI.


IMHO, the library should have a:
Requires: (java-devel >= 1:8 with java-devel < 1:11)

Sure, this will not per se prevent you from attempting to use the library
with the Java 17 compiler, but if you do not have Java 8 or 11 installed,
installing the library attempting to install it as a dependency should raise
a red flag.

As a quick check, you could write a specfile for your application with:
BuildRequires: java-devel >= 1:17
BuildConflicts: java-devel < 1:17
and then run mock on that. The latter line should prevent the old version
from being installed in parallel.

One annoyance is that older OpenJDK packages currently drop that virtual
Provides, presumably in an attempt to get all Java packages systematically
built with a newer JDK. That is something that ought to get fixed. (If we
switch to building with the oldest possible Java as I suggest, it will have
to get fixed anyway.) As is, you may need to explicitly:
BuildConflicts: java-1.8.0-devel
BuildConflicts: java-11-devel

 Kevin Kofler
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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

Re: SPDX Statistics - L'Aigle meteorite edition

2024-05-02 Thread John Reiser


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 output of a random date generator.)

Financial markets and other arenas using serious statistical forecasting
have known for decades that it is much better to estimate by assuming
a rate equal to the moving average rate over a fixed-length relevant
period.  Repeatedly estimating based on the entire history does not
meet the fixed-length requirement, because the entire history grows.
Typical periods range from a small number of months to one year.
For Fedora, one relevant period might be six months, the interval 
between scheduled releases.  Also useful are 90 and 120 days.


Graphing the estimated completion date based on such a moving
average rate would be much more informative and useful than the
estimated dates which have been published so far.
--
___
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

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

2024-05-02 Thread bugzilla

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
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.3.2
Upstream release that is considered latest: 3.3.2
Current version/release in rawhide: 3.3.1-4.fc40
URL: https://metacpan.org/dist/Test-Compile/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3388/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Test-Compile


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2278779

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202278779%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread updates

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 public domain libraries for C/C++

Update Information:

Security fix for CVE-2023-45681 / CVE-2023-47212

ChangeLog:

* Thu May  2 2024 Benjamin A. Beasley  - 
0-0.45.20240213gitae721c5
- Patch for GHSL-2023-171/CVE-2023-45681/CVE-2023-47212
* Thu May  2 2024 Benjamin A. Beasley  - 
0-0.44.20240213gitae721c5
- Fix a description to use American English orthography
* Thu May  2 2024 David Abdurachmanov  - 
0-0.42.20240213gitae721c5
- Fix compile error on riscv64

References:

  [ 1 ] Bug #2278401 - CVE-2023-47212 stb: stb_vorbis.c comment heap-based 
buffer overflow vulnerability
https://bugzilla.redhat.com/show_bug.cgi?id=2278401


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread updates

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
stb-0-0.45.20240213gitae721c5.el8

Details about builds:



 libmongocrypt-1.10.0-1.el8 (FEDORA-EPEL-2024-a5c1e0a4d2)
 The companion C library for client side encryption in drivers

Update Information:

Version 1.10.0
New features
Support KMIP delegated option.
Support processing bulkWrite command.

ChangeLog:

* Thu May  2 2024 Remi Collet  - 1.10.0-1
- update to 1.10.0




 mongo-c-driver-1.27.0-1.el8 (FEDORA-EPEL-2024-78cb8d0ff5)
 Client library written in C for MongoDB

Update Information:

libmongoc 1.27.0
Notes:
Raise required version of libmongocrypt to 1.10.0 to support In-Use Encryption
(corresponds to the CMake option: ENABLE_CLIENT_SIDE_ENCRYPTION).
A future minor release plans to raise the minimum supported MongoDB Server
version from 3.6 to 4.0. This is in accordance with MongoDB Software Lifecycle
Schedules.
Fixes:
Fix possible crash when client is configured with empty password.
New Features:
Add database name to command events: mongoc_apm_command_failed_get_database_name
and mongoc_apm_command_succeeded_get_database_name.
Support delegated KMIP protocol for In-Use Encryption.
Enable setting socket timeout per client.
libmongoc 1.26.2
Fixes:
Fix possible hang if mongoc_gridfs_file_readv is called with a corrupt chunk
with incomplete data.
Fix assert with legacy exhaust cursor protocol when connected to server < 4.2.
libmongoc 1.26.1
Fixes:
Fix 32-bit compile with 64-bit time_t
libmongoc 1.26.0
New Features:
Support named KMS providers.
Redirect retries in sharded clusters to another mongos if possible.
Improvements:
Add VERSION_CURRENT file in source to ease building.
Consider more errors retryable.
libmongoc 1.25.4
Fixes:
Restore support for Sphinx 1.7.6 for man page build.
libmongoc 1.25.3
Fixes:
Disable shared libmongoc targets if ENABLE_SHARED=OFF
Fix documentation build with Python 3.9.
libmongoc 1.25.2
Fixes:
Fix data race in mongoc_cursor_get_host.
Accept discouraged timeout values for backwards compatibility.
libmongoc 1.25.1
Fixes:
Add back support for BUILD_VERSION CMake option. BUILD_VERSION was
unintentionally removed in 1.25.0.
libmongoc 1.25.0
Fixes:
Send recoveryToken in transactions when connected to a load balancer.
Improvements:
Remove optional dependency of libicu.
Use OP_MSG exhaust for mongod >= 4.2. Enable exhaust cursors for mongos >= 7.1.
Share cached credentials for SCRAM authentication among all clients to improve
performance.
Use polling monitoring in FaaS environments.
Build Configuration:
Remove ENABLE_SRV=AUTO. Only support boolean values for ENABLE_SRV.
libbson 1.27.0
No changes
libbson 1.25.4
Fixes:
Restore support for Sphinx 1.7.6 for man page build.
libbson 1.25.2
Fixes:
Fix conversion warning with GCC 12.
Include -pthread in pkg-config Libs.
libbson 1.25.1
Fixes:
The BUILD_VERSION CMake option was restored.
Fixes to some format strings in trace logs.
Allow mongoc_buffer_t to be larger than INT_MAX.
libbson 1.25.0
New Features:
Add bson_array_builder_t.

ChangeLog:

* Thu May  2 2024 Remi Collet  - 1.27.0-1
- update to 1.27.0
- raise dependency to libmongocrypt 1.10.0
- drop dependency on libicu
- add dependency on libutf8proc




 stb-0-0.45.20240213gitae721c5.el8 (FEDORA-EPEL-2024-6327fb701b)
 Single-file public domain libraries for C/C++

Update Information:

Security fix for CVE-2023-45681 / CVE-2023-47212

ChangeLog:

* Thu May  2 2024 Benjamin A. Beasley  - 
0-0.45.20240213gitae721c5
- Patch for GHSL-2023-171/CVE-2023-45681/CVE-2023-47212
* Thu May  2 2024 Benjamin A. Beasley  - 
0-0.44.20240213gitae721c5
- Fix a description to use American English orthography
* Thu May  2 2024 David Abdurachmanov  - 
0-0.42.20240213gitae721c5
- Fix compile error on riscv64

References:

  [ 1 ] Bug #2278401 - CVE-2023-47212 stb:

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

2024-05-02 Thread Kevin Kofler via devel

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 way to detect that case is with
> CI.

IMHO, the library should have a:
Requires: (java-devel >= 1:8 with java-devel < 1:11)

Sure, this will not per se prevent you from attempting to use the library 
with the Java 17 compiler, but if you do not have Java 8 or 11 installed, 
installing the library attempting to install it as a dependency should raise 
a red flag.

As a quick check, you could write a specfile for your application with:
BuildRequires: java-devel >= 1:17
BuildConflicts: java-devel < 1:17
and then run mock on that. The latter line should prevent the old version 
from being installed in parallel.

One annoyance is that older OpenJDK packages currently drop that virtual 
Provides, presumably in an attempt to get all Java packages systematically 
built with a newer JDK. That is something that ought to get fixed. (If we 
switch to building with the oldest possible Java as I suggest, it will have 
to get fixed anyway.) As is, you may need to explicitly:
BuildConflicts: java-1.8.0-devel
BuildConflicts: java-11-devel

Kevin Kofler
--
___
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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

2024-05-02 Thread Kevin Kofler via devel

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 target
> JRE.

The problem is, without ALSO installing the JDK for the targeted version AND 
explicitly pointing -bootclasspath to that JDK, this does NOT catch code 
trying to use class library features (as opposed to language or bytecode 
features) from the newer JDK, and worse, in rare occasions, even if the 
source code is in principle compatible with the targeted older Java, when 
compiled with a newer compiler and older target release, it will fail to 
actually run (!) with the latter (because the compiler picks up a subclass 
override of a method added in the newer Java instead of the baseclass method 
that was always available and, for performance reasons, tries calling the 
override explicitly rather than going through the virtual method lookup). 
One example of that latter issue is NetBeans, where versions 12.5 and 12.6 
were supposed to be compatible with Java 8, but some upstream-published 
binaries of 12.5 and all of 12.6 do not actually work properly on it because 
they were built with Java 11 in "-release 8" mode: some editor features fail 
with runtime exceptions. See 
https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They 
"fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x 
release was ever issued.)

So I am AGAINST systematically using "-release" without "-bootclasspath", 
even though that works in most cases and is often successfully used in 
production (me and my employer use it, too, but on projects we control where 
we will fix the source code or add a workaround to it if any issues come up 
from that, not systematically on repackaging third-party projects). The 
compiler even warns about the missing "-bootclasspath". And the potential to 
cause subtle misbehavior that is a pain to debug is just too high, 
especially if we have the actual older JDK available and could just 
BuildRequire the correct version.

Kevin Kofler
--
___
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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

2024-05-02 Thread Carlos Rodriguez-Fernandez

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, I wouldn't want that lib to also bring JRE 11, because I'll 
be running my app in JRE 17, however, ... I'd learn quickly that it fails.


The other way around can happen too, a library runs well in 17, but 
crashes in JRE 11 because of that InetSocketAddress change, for example.


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 way to detect that case is with CI.



On 5/2/24 11:58, Christopher wrote:

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 on a specific java bytecode
version range. System libraries packages could provide compatibility
packages, so couldn't those apps just depend on those compatibility
packages instead? That can become a maintenance burden for those libs,
though.


The safest approach for library JARs would be to always build them against
the lowest possible Java version (the oldest JDK branch that we still ship
if the library supports that, otherwise the oldest the library supports).
And IMHO, if the library is built against a higher version than the lowest
we ship, it needs a versioned Requires on the JRE.

 Kevin Kofler


I have noticed that the `--release` flag on javac (JDK>=9) actually
enforces JLS compliance more strictly than even compiling with the
specific version it targets. For example, it is possible to write a
project that is non-compliant with the Java 8 JLS that the Java 8
compiler will incorrectly permit without error. Such a project will
not work properly on Java 9 and newer JREs. However, if JDK 9 were
used to compile the project with `javac --release 8`, the compiler
will catch the non-compliance with the Java 8 JLS that the JDK 8
compiler failed to catch, forcing compliance with Java 8, and allowing
the resulting byte code to work on JRE 9 and later.

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 target
JRE. But, this requires project maintainers to explicitly add the use
of the `--release` flag if the upstream build does not already set it
in some way. Doing this, it should not matter which of our JDKs it
builds with, but building with the latest available (rather than the
oldest available, as Kevin suggests) will have the best chance for
compliance-related bugs to be fixed (but only if the `--release` flag
is used). Of course, there are many ways to break Java libraries
across JRE versions, but the one I'm focusing on here is one that is
preventable, due to JDK enforcement of JLS compliance during
compilation, which is more strict in newer JDKs than in earlier ones.

If upstream's oldest supported JRE is still supported by the
`--release` flag by the JDK used in Fedora's build, then it should be
fine to just specify that version, even if it is older than the oldest
JRE that Fedora ships. In such cases, it might not technically be
necessary to specify a Requires for the JRE. However, if the oldest
supported JRE in the upstream project is newer than Fedora's oldest
shipped JRE, then having the Requires >= would still be needed. For
example, if Fedora ships JRE 11, 17, and 21, and the upstream project
targets Java 8, then it should be fine to build that project using JDK
21 with `--release 8` and have no Requires. However, if upstream
targets Java 11, then building using JDK 21 with `--release 11` would
be okay, but you'd need Requires >= 11 (or maybe Recommends >= 11 ?).

I don't object to the original proposal, though. There have been times
I've wanted to install a Java library not to run it, but to inspect
the jar with a third-party tool (or even just vim). But, I think it's
important for Java package maintainers to be aware of what versions
their packages' upstream projects are targeting, and make sure they
are built correctly for Fedora using Fedora's JDKs. I also think it's
important that Fedora packagers communicate the JRE requirements for
each package *if* it were to be run. Maybe that can be done with
Recommends instead of Requires? I'm not sure about that part, but I
acknowledge that installing a library is not the same as intending for
it to be run.

Christopher
--

Re: SPDX Statistics - L'Aigle meteorite edition

2024-05-02 Thread Gary Buhrmaster

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 flatter after. I think this is making the prediction a little
> too optimistic.
>
> 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.

Linear approximation is almost always wrong, it is just
also hard to predict by how much (we could make a
linear prediction on how bad it will be?).  If one only
looks at the graph for the last six months or so the
linear estimate for completion is more towards the
end of the century.

Joking aside, I do agree the non-trivial conversions are
likely to be the hard ones, and there will be a very long
tail (many years more) for 100% as the work to deal with
some of those hard ones may require expertise that is
in limited or even unavailable supply, and when they
require new (legal) license reviews and SPDX definitions
they can take quite some time.  Alternatively, it is possible
that there is a target (say, 95%) after which the SPDX
conversion project will be stated to be "essentially"
complete and is ended even if not 100%.
--
___
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: SPDX Statistics - L'Aigle meteorite edition

2024-05-02 Thread Alexander Ploumistos

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 enjoying the "SPDX
statistics - X edition" tidbits for quite some time!
--
___
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: 20240502.n.0 changes

2024-05-02 Thread Fedora Rawhide Report

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:59.74 MiB
Size of upgraded packages:   13.27 GiB
Size of downgraded packages: 10.01 GiB

Size change of upgraded packages:   205.97 MiB
Size change of downgraded packages: -20.44 MiB

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240502.n.0.iso

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240501.n.0.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240501.n.0.ociarchive

= ADDED PACKAGES =
Package: golang-github-frostbyte73-core-0.0.10-1.fc41
Summary: Golang function throttler
RPMs:golang-github-frostbyte73-core-devel
Size:13.35 KiB

Package: python-hid-1.0.6-1.fc41
Summary: Python ctypes bindings for hidapi
RPMs:python3-hid
Size:17.27 KiB

Package: rust-core2-0.4.0-1.fc41
Summary: Bare essentials of std::io for use in no_std. Alloc support is optional
RPMs:rust-core2+alloc-devel rust-core2+default-devel rust-core2+std-devel 
rust-core2-devel
Size:63.19 KiB

Package: rust-dary_heap-0.3.6-1.fc41
Summary: D-ary heap
RPMs:rust-dary_heap+default-devel rust-dary_heap+extra-devel 
rust-dary_heap+serde-devel rust-dary_heap-devel
Size:51.03 KiB

Package: rust-libflate1-1.4.0-1.fc41
Summary: Rust implementation of DEFLATE algorithm and related formats
RPMs:rust-libflate1+default-devel rust-libflate1-devel
Size:55.91 KiB

Package: rust-libflate_lz77_1-1.2.0-1.fc41
Summary: LZ77 encoder for libflate crate
RPMs:rust-libflate_lz77_1+default-devel rust-libflate_lz77_1-devel
Size:20.74 KiB

Package: rust-minreq-2.11.2-1.fc41
Summary: Simple, minimal-dependency HTTP client
RPMs:rust-minreq+base64-devel rust-minreq+default-devel 
rust-minreq+https-devel rust-minreq+https-rustls-devel 
rust-minreq+https-rustls-probe-devel rust-minreq+json-using-serde-devel 
rust-minreq+once_cell-devel rust-minreq+proxy-devel rust-minreq+punycode-devel 
rust-minreq+rustls-devel rust-minreq+rustls-native-certs-devel 
rust-minreq+rustls-webpki-devel rust-minreq+serde-devel 
rust-minreq+serde_json-devel rust-minreq+urlencoding-devel 
rust-minreq+webpki-roots-devel rust-minreq-devel
Size:154.29 KiB

Package: rust-simple_asn1_0.5-0.5.4-1.fc41
Summary: Simple DER/ASN.1 encoding/decoding library
RPMs:rust-simple_asn1_0.5+default-devel rust-simple_asn1_0.5-devel
Size:29.79 KiB


= DROPPED PACKAGES =
Package: libicu73-73.2-1.fc40
Summary: Compat package with icu libraries
RPMs:libicu73
Size:52.86 MiB

Package: libvpx8-1.13.1-1.fc40
Summary: Compat package with libvpx libraries
RPMs:libvpx8
Size:6.88 MiB


= UPGRADED PACKAGES =
Package:  algol68g-3.5.1-2.fc41
Old package:  algol68g-3.5.1-1.fc41
Summary:  Algol 68 Genie compiler-interpreter
RPMs: algol68g
Size: 2.57 MiB
Size change:  90.86 KiB
Changelog:
  * Wed May 01 2024 Oleg Girko  - 3.5.1-2
  - Add patch to make configure detect glibc again
  - Run autoreconf again: we have patches to configure,ac


Package:  ansible-9.5.1-1.fc41
Old package:  ansible-9.4.0-1.fc41
Summary:  Curated set of Ansible collections included in addition to 
ansible-core
RPMs: ansible
Size: 48.73 MiB
Size change:  532.30 KiB
Changelog:
  * Thu May 02 2024 Maxwell G  - 9.5.1-1
  - Update to 9.5.1.


Package:  ansible-core-2.16.6-1.fc41
Old package:  ansible-core-2.16.5-1.fc41
Summary:  A radically simple IT automation system
RPMs: ansible-core ansible-core-doc
Size: 5.15 MiB
Size change:  -2.79 KiB
Changelog:
  * Tue Apr 16 2024 Maxwell G  - 2.16.6-1
  - Update to 2.16.6. Fixes rhbz#2261507.


Package:  apostrophe-1:3.0-2.fc41
Old package:  apostrophe-1:2.6.3-16.fc40
Summary:  Distraction free Markdown editor for GNU/Linux made with GTK+
RPMs: apostrophe
Size: 428.14 KiB
Size change:  -2.18 MiB
Changelog:
  * Thu May 02 2024 Packit  - 1:3.0-1
  - Update to 3.0 upstream release
  - Resolves: rhbz#2278247

  * Thu May 02 2024 Artem Polishchuk  - 1:3.0-2
  - packit: Update config


Package:  chromium-124.0.6367.118-1.fc41
Old package:  chromium-124.0.6367.91-1.fc41
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless
Size: 417.09 MiB
Size change:  24.63 KiB
Changelog:
  * Wed May 01 2024 Than Ngo  - 124.0.6367.118-1
  - update to 124.0.6367.118
* High CVE-2024-4331: Use after free in Picture In Picture
* High CVE-2024-4368: Use after free in Dawn
  - use system highway


Package:  emacs-1:29.3-10.fc41
Old package:  emacs-1

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

2024-05-02 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2277612

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Test-Smoke-1.82-1.fc41
 Resolution|--- |ERRATA
Last Closed||2024-05-02 20:50:54



--- Comment #2 from Fedora Update System  ---
FEDORA-2024-3e80c8a5d6 (perl-Test-Smoke-1.82-1.fc41) has been pushed to the
Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2277612

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202277612%23c2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread Adam Williamson

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 issue(s).
> > --
> 
> The CLI update strongly suggests doing 'dnf update --refresh' before 
> system-upgrade. It doesn't require it though.
> 
> I always thought it's an odd workflow; why doesn't it just force it? 
> While it might take a long while to complete on a stale system, it's 
> recommended anyway, isn't it?

I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.
-- 
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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

2024-05-02 Thread Przemek Klosowski via devel


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 
system-upgrade. It doesn't require it though.


I always thought it's an odd workflow; why doesn't it just force it? 
While it might take a long while to complete on a stale system, it's 
recommended anyway, isn't it?


On an updated system it's fairly quick turnaround; I usually lose more 
time by sitting with an unanswered, unnoticed prompt.

--
___
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: Notice of intent to orphan salt

2024-05-02 Thread Gwyn Ciesla via devel

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 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
> > 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 
> > work
> > required to work on 3.12, I THINK, involves unbundling twisted, which is 
> > non-trival.
> 

> Sigh... they're going the Chef 'omnibus' route huh :(
> 

> Best regards,
> 

> --
> _o) Michel Lind
> _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
> --
> ___
> 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

signature.asc
Description: OpenPGP digital 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

Re: Notice of intent to orphan salt

2024-05-02 Thread Michel Lind


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 supporting anything outside of 
their 'onedir' packaging, which bundles it's own Python stack. Most of the work 
required to work on 3.12, I THINK, involves unbundling twisted, which is non-trival.



Sigh... they're going the Chef 'omnibus' route huh :(

Best regards,

--
 _o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


OpenPGP_0x8B229D2F7CCC04F2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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

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

2024-05-02 Thread Christopher

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 on a specific java bytecode
> > version range. System libraries packages could provide compatibility
> > packages, so couldn't those apps just depend on those compatibility
> > packages instead? That can become a maintenance burden for those libs,
> > though.
>
> The safest approach for library JARs would be to always build them against
> the lowest possible Java version (the oldest JDK branch that we still ship
> if the library supports that, otherwise the oldest the library supports).
> And IMHO, if the library is built against a higher version than the lowest
> we ship, it needs a versioned Requires on the JRE.
>
> Kevin Kofler

I have noticed that the `--release` flag on javac (JDK>=9) actually
enforces JLS compliance more strictly than even compiling with the
specific version it targets. For example, it is possible to write a
project that is non-compliant with the Java 8 JLS that the Java 8
compiler will incorrectly permit without error. Such a project will
not work properly on Java 9 and newer JREs. However, if JDK 9 were
used to compile the project with `javac --release 8`, the compiler
will catch the non-compliance with the Java 8 JLS that the JDK 8
compiler failed to catch, forcing compliance with Java 8, and allowing
the resulting byte code to work on JRE 9 and later.

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 target
JRE. But, this requires project maintainers to explicitly add the use
of the `--release` flag if the upstream build does not already set it
in some way. Doing this, it should not matter which of our JDKs it
builds with, but building with the latest available (rather than the
oldest available, as Kevin suggests) will have the best chance for
compliance-related bugs to be fixed (but only if the `--release` flag
is used). Of course, there are many ways to break Java libraries
across JRE versions, but the one I'm focusing on here is one that is
preventable, due to JDK enforcement of JLS compliance during
compilation, which is more strict in newer JDKs than in earlier ones.

If upstream's oldest supported JRE is still supported by the
`--release` flag by the JDK used in Fedora's build, then it should be
fine to just specify that version, even if it is older than the oldest
JRE that Fedora ships. In such cases, it might not technically be
necessary to specify a Requires for the JRE. However, if the oldest
supported JRE in the upstream project is newer than Fedora's oldest
shipped JRE, then having the Requires >= would still be needed. For
example, if Fedora ships JRE 11, 17, and 21, and the upstream project
targets Java 8, then it should be fine to build that project using JDK
21 with `--release 8` and have no Requires. However, if upstream
targets Java 11, then building using JDK 21 with `--release 11` would
be okay, but you'd need Requires >= 11 (or maybe Recommends >= 11 ?).

I don't object to the original proposal, though. There have been times
I've wanted to install a Java library not to run it, but to inspect
the jar with a third-party tool (or even just vim). But, I think it's
important for Java package maintainers to be aware of what versions
their packages' upstream projects are targeting, and make sure they
are built correctly for Fedora using Fedora's JDKs. I also think it's
important that Fedora packagers communicate the JRE requirements for
each package *if* it were to be run. Maybe that can be done with
Recommends instead of Requires? I'm not sure about that part, but I
acknowledge that installing a library is not the same as intending for
it to be run.

Christopher
--
___
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

Notice of intent to orphan salt

2024-05-02 Thread Gwyn Ciesla via devel

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 work 
required to work on 3.12, I THINK, involves unbundling twisted, which is 
non-trival.

The good news is that they do that with the 3007.x series. The bad news is that 
that requires a recent version of python-cryptography that breaks several other 
packages:

https://bugzilla.redhat.com/show_bug.cgi?id=2257380

Since I needed something that works for config management, I've migrated my own 
stuff from salt to something that works with distro packaging and doesn't have 
odd version constraints¹.

As a consequence, I can no longer sufficiently test new releases. As a result, 
I've just sent 3006.8 to updates-testing for rawhide-f38, and will orphan salt 
on May 21 2024, when f38 is EOL.

If someone wants to take ownership before then, please let me know.

-Gwyn


1.  Ansible.





-- 
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.

signature.asc
Description: OpenPGP digital 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

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

2024-05-02 Thread bugzilla

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 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Releases retrieved: 2.01
Upstream release that is considered latest: 2.01
Current version/release in rawhide: 1.96-4.fc40
URL: http://search.cpan.org/dist/Devel-CheckOS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2824/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Devel-CheckOS


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2278464

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202278464%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread Gary Buhrmaster

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
if someone has not kept up with updates the upgrade
programs themselves might be too old to properly
complete the update (such as if dnf-command(system-upgrade)
or rpm needed to be updated).  In some previous
versions a blocker for release did require that fixes
be made available for previous versions for successful
updates.  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).
--
___
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: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

2024-05-02 Thread Matthew Miller

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 doing two updates in a row was really useful, if I remember.) That
may be a big source of pain.


-- 
Matthew Miller

Fedora Project Leader
--
___
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: SPDX Statistics - L'Aigle meteorite edition

2024-05-02 Thread Matthew Miller

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
> report).  Pure linear approximation.

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 flatter after. I think this is making the prediction a little
too optimistic.

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.

On the other hand, if we have some other big conversion efforts (like a
virtual hackfest or something), maybe factoring in a big jump _is_ right.

-- 
Matthew Miller

Fedora Project Leader
--
___
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

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

2024-05-02 Thread Michel Lind

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 running Fedora.

```
Error:
 Problem 1: conflicting requests
  - nothing provides /usr/libexec/platform-python needed by 
python3-dnf-4.7.0-19.el8.alma.noarch from baseos
 Problem 2: package python3-dnf-plugins-core-4.0.21-23.el8.alma.1.noarch from 
baseos requires python3-dnf >= 4.7.0-6, but none of the providers can be installed

  - cannot install the best candidate for the job
  - nothing provides /usr/libexec/platform-python needed by 
python3-dnf-4.7.0-19.el8.alma.noarch from baseos
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use 
not only best candidate packages or '--setopt=optional_metadata_types=filelists' 
to load additional filelists metadata)

ERROR: Command failed:
 # /usr/bin/dnf-3 --installroot 
/var/lib/mock/alma+epel-8-x86_64-bootstrap/root/ --releasever 8 
--setopt=deltarpm=False --setopt=allow_vendor_change=yes --allowerasing 
--disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock 
install python3-dnf python3-dnf-plugins-core
No matches found for the following disable plugin patterns: local, spacewalk, 
versionlock

```

Adding `--setopt=optional_metadata_types=filelists` as suggested and scrubbing 
the mock chroot seems to work (scrubbing is necessary, otherwise the existing 
metadata does not have /usr/libexec indexed)


```
config_opts['dnf_common_opts'] = ['--setopt=deltarpm=False', 
'--setopt=allow_vendor_change=yes', '--allowerasing', 
'--setopt=optional_metadata_types=filelists']

```
(taking the existing value from /usr/share/doc/mock/site-defaults.cfg and adding 
the suggested option)


This seems to only affect those running recent Fedora on the host (where 
filelists are no longer indexed in the default metadata), who also need to 
generate their own bootstrap (because `use_bootstrap_image` is disabled), who 
are working on EL8 (because python3-dnf has a dependency on 
/usr/libexec/platform-python -- no such thing on EL9 and above) - so I'm not 
sure if this can be fixed upstream or should just be documented somewhere.


e.g. we could fix it in /etc/mock/templates/{almalinux,centos-stream,rhel}-8.tpl 
but that would presumably slow down those who just use the bootstrap image?


My workaround now is sticking that dnf_common_opts hack in ~/.config/mock.cfg, 
and commenting it out when I'm not bootstrapping an EL8 chroot.


Best regards,

--
 _o) Michel Lind
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


OpenPGP_0x8B229D2F7CCC04F2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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

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

2024-05-02 Thread rawhide

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:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/41iot

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_41_RC_20240502.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_41_RC_20240502.0_General

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

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

2024-05-02 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2277612

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2024-3e80c8a5d6 (perl-Test-Smoke-1.82-1.fc41) has been submitted as an
update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3e80c8a5d6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2277612

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202277612%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread bugzilla

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 receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread bugzilla

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 the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread bugzilla

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
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Releases retrieved: 1.45
Upstream release that is considered latest: 1.45
Current version/release in rawhide: 1.43-1.fc40
URL: https://metacpan.org/dist/Net-DNS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3147/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Net-DNS


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264428

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264428%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedocal] Reminder meeting : ELN SIG

2024-05-02 Thread sgallagh

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

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

2024-05-02 Thread Aoife Moloney

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
called a ‘Change Proposal Blueprint’ - a fancy way of saying if a change
proposal owner wants some initial testing for their change, Fedora QA will
try to support them by helping write and run initial basic tests.



This 'blueprint' concept is proposed as an optional step for change
proposal owners, with the condition that Fedora QA can provide assistance
if available. While QA has shown enthusiasm for the idea, it's important to
note that support is likely but not guaranteed. The concept is primarily
aimed at System Wide and Mass Rebuild changes. By integrating this option
into the change proposal template, proponents hope to enhance proposals,
making them clearer and more likely to be accepted by the Fedora community
and FESCo. This approach also benefits QA by involving them earlier in
changes, particularly those with uncertainties or extensive scopes. By
facilitating early feedback and testing, potential issues can be identified
sooner, giving developers more time to address them before Beta or Final
releases. Additionally, offering a supported method for creating a minimal
version of the change for testing enables users to identify potentially
hidden breaking dependencies that may only surface during the Rawhide
builds.This early detection capability, coupled with the option for
preliminary testing, provides developers with more time to address any bugs
before reaching the Beta or Final stages. Given the stress typically
experienced as release time approaches, providing assistance with early
testing at the outset of a change proposal could significantly alleviate
pressure on developers and QA teams, making it a worthwhile endeavor to
explore.


Our change proposal is such a powerful process,  so we wanted to leverage
this by introducing the option of requesting early testing support by
adding it to our change proposal template. You will now see a section in
the template called Early Testing (Optional)

and instructions on how to reach out to Fedora QA - it's basically send an
email to t...@lists.fedoraproject.org  with a link
to your change proposal and a member of QA (likely Sumantro) will reply to
you :) You can also reach out to Sumantro directly too, but preference will
be to email the list as this will give you more coverage.

Some anti-goals of this idea are not to fully test a change before it goes
through the process, nor is it a shortcut to land an un-approved change in
Fedora either,  but rather an opportunity to bring a quality mindset into
the development process much earlier so Fedora can benefit from iterative
development backed by quality. We expect changes to be built in a COPR and
tested here where possible, and not built in rawhide directly from scratch,
as Rawhide is the next Fedora release and we would rather not break that
too much :)

Sumantro is the lead on this, and I will be supporting him and QA as we
work together to see if this helps enhance the project's release cycle. You
can reach out to either or both of us if you would like to chat in detail
about it, and we would love to hear your feedback on this idea!



Kind regards,
Aoife & Sumantro

-- 

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

Re: XDG_BASE_DIRECTORY specification

2024-05-02 Thread Artur Frenszek-Iwicki

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 fallback/default doesn't make much sense
(apart from maybe working as a band-aid solution for
programs that don't follow the spec fully and
don't implement the fallback).

Sincerely,
A.FI.

[0] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
--
___
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

XDG_BASE_DIRECTORY specification

2024-05-02 Thread Julian Sikorski


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 regardless, I am not clear on the added value of adding the 
support. Thanks for clearing the confusion in advance.


Best regards,
Julian

[1] https://src.fedoraproject.org/rpms/mame/pull-request/2
--
___
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: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

2024-05-02 Thread Kevin Kofler via devel

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 could provide compatibility
> packages, so couldn't those apps just depend on those compatibility
> packages instead? That can become a maintenance burden for those libs,
> though.

The safest approach for library JARs would be to always build them against 
the lowest possible Java version (the oldest JDK branch that we still ship 
if the library supports that, otherwise the oldest the library supports). 
And IMHO, if the library is built against a higher version than the lowest 
we ship, it needs a versioned Requires on the JRE.

Kevin Kofler
--
___
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

, glibc ABI updates coming to Fedora releases

2024-05-02 Thread Florian Weimer

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 wrong because these files describe on-disk data structures.
   This has been fixed for glibc 2.40 upstream, and I'm working on
   backports all the way to glibc 2.34 (which will eventually land
   in all supported Fedora releases).

2. 31 bits aren't enough for some downstream distributions.  We can
   recover one bit if we make the types unsigned.  Such a change will be
   part of glibc 2.40, and it has already landed in rawhide.  I do not
   plan to backport this change upstream, but for downstream use cases,
   we have to backport it into Fedora 40.  (I plan to stop there, and
   not update 39 and 38.)  I did a mass-rebuild rebuild of all packages
   that use the utmp functions, and at least there weren't any build
   failures.  With just glibc rebuilt, the graphical desktop appears to
   work just fine (which isn't unexpected, given that glibc treats these
   timestamps as opaque).

Long term, we expect that applications switch away from these
interfaces, and use session information from systemd.  It's not just
that the fields have the wrong size, the whole facility is designed for
a fixed number of terminals.  It is not really compatible with a large
(effective unbounded) number of pseudo-terminals, or more generally,
client sessions.  It is also not possible to correctly implement utmp
file locking without help from a daemon.

Thorsten Kukuk is leading the migration, and has submitted patches to
many upstream projects:

  Y2038, glibc and utmp/utmpx on 64bit architectures
  

Thanks,
Florian
   
   
--
___
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

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

2024-05-02 Thread bugzilla

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: https://koschei.fedoraproject.org/package/perl-Gtk3
Status: NEW
 Component: perl-Gtk3
  Assignee: ser...@serjux.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com,
perl-devel@lists.fedoraproject.org, ser...@serjux.com
Blocks: 2260875 (F41FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Gtk3-0.038-11.fc41 fails to build in Fedora 41 because a test fails:

(overrides.t:692): GdkPixbuf-WARNING **: 08:33:21.912: Error loading XPM image
loader: Image type “xpm” is not supported
#   Failed test 'undef isa 'Gtk3::Gdk::Pixbuf''
#   at t/overrides.t line 748.
# undef isn't defined
Can't call method "get_colorspace" on an undefined value at t/overrides.t line
749.
# Looks like your test exited with 25 just after 179.
t/overrides.t .. 
Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 55/233 subtests 

A difference between passing and failing build roots is at
.

This failure is probably triggered by upgrading gdk-pixbuf2-modules from
2.42.10-8.fc40 to 2.42.11-1.fc41. gdk-pixbuf2 disabled a support for XPM format
(bug #2276464).

Reading a code of t/overrides.t reveals it tests loading XPM without checking
whether gkd-pixbuf supports XPM.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260875
[Bug 2260875] Fedora 41 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2278602

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202278602%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-05-02 Thread Michal Josef Špaček


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 below
https://src.fedoraproject.org/rpms/perl/pull-request/13
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

37 matches

Mail list logo