The following Fedora EPEL 8 Security updates need testing:
Age URL
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f7310355bb
djvulibre-3.5.28-5.el8
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ac000e6379
chromium-124.0.6367.155-1.el8
0
The following Fedora EPEL 9 Security updates need testing:
Age URL
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ff0fd23aa7
djvulibre-3.5.28-4.el9
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f74fbce604
chromium-124.0.6367.155-1.el9
The following builds
Florian Festi wrote:
> We have an even easier solution for you: You can just run the script at
> [3] with -n on your own spec files to get them changed to the %patch N
> variant. If you do that right now they will not break nor will they be
> touched during the mass change.
>
> As I said the
On 10. 05. 24 18:59, Tulio Magno Quites Machado Filho wrote:
Siddhesh Poyarekar writes:
_FORTIFY_SOURCE (any level) should work perfectly with -O (any level).
Is this new? Or do you mean any level where optimization is enabled?
i.e. -On, where n >= 1
Anyway, a warning should be printed
On 10. 05. 24 15:58, Siddhesh Poyarekar wrote:
On 2024-05-10 06:41, Miro Hrončok wrote:
Hello,
when we build Python 3.13 with -O3
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
I see the following annocheck problem:
Hardened: /usr/bin/python3.13: MAYB: test: fortify,
On Fri, May 3, 2024 at 9:40 AM Miroslav Suchý wrote:
> The current change
>
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4
>
> is planned to be the last one. At the end of this phase - scheduled to
> 2024-08-06 - we plan to mark this conversion as "done". My estimation is that
OLD: Fedora-Rawhide-20240509.n.2
NEW: Fedora-Rawhide-20240510.n.1
= SUMMARY =
Added images:1
Dropped images: 2
Added packages: 2
Dropped packages:1
Upgraded packages: 29
Downgraded packages: 3
Size of added packages: 617.48 KiB
Size of dropped packages
Dne 10. 05. 24 v 11:29 dop. Miro Hrončok napsal(a):
So we can now have packages with uppercase AND/ORs and packages with lowercase and/ors and we can no longer quickly
recognize SPDX expression by observing uppercase AND/ORs?
That does not sound like improvement to me :/
This is very very
Announcing the creation of a new nightly release validation test event
for Fedora 41 Rawhide 20240510.n.1. 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
Siddhesh Poyarekar writes:
> _FORTIFY_SOURCE (any level) should work perfectly with -O (any level).
Is this new? Or do you mean any level where optimization is enabled?
i.e. -On, where n >= 1
Anyway, a warning should be printed when using -O0 unless -Wno-cpp is
also used.
annocheck's source
Version 24.5.10 of the ecl package has been released, and includes an
soname bump. I intend to build it and rebuild its sole Fedora
consumer, maxima, in a week, for Rawhide only.
In addition, this release changes the base license of the package from
LGPL-2.0-or-later to LGPL-2.1-or-later.
--
The following Fedora EPEL 8 Security updates need testing:
Age URL
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f7310355bb
djvulibre-3.5.28-5.el8
0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ac000e6379
chromium-124.0.6367.155-1.el8
The following builds
Hi -
> [...]
> > My idea is to split systemtap-sdt-devel into two packages: one with all the
> > content but without the python script (/usr/bin/dtrace) and a new one
> > containing only the mentioned script.
No objection here.
> > [...]
> > I also did a test rebuild of all packages directly
On 2024-05-10 06:41, Miro Hrončok wrote:
Hello,
when we build Python 3.13 with -O3
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
I see the following annocheck problem:
Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason:
-D_FORTIFY_SOURCE=2 detected, expected
On 5/10/24 14:10, Vít Ondruch wrote:
> I'd actually prefer the `%patch 1` syntax (which is also the first on
> the list [1]). Yes, I understand that `%patch -P1` is to stay on the
> safe side, but this is Fedora change, not RHEL or EPEL change.
>
> But if you insist on `-P1`, then please skip all
V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a):
> I might have an idea how to make building Perl packages faster and their
> buildroot a little bit smaller.
>
> perl-devel depends on systemtap-sdt-devel and that package contains a single
> script written in Python and using
I'd actually prefer the `%patch 1` syntax (which is also the first on
the list [1]). Yes, I understand that `%patch -P1` is to stay on the
safe side, but this is Fedora change, not RHEL or EPEL change.
But if you insist on `-P1`, then please skip all packages I am
associated with. I'd prefer
Hi All,
Due to licensing changes beginning with Hyperscan 5.5[0] to a
proprietary/closed license and general lack of support for the 5.4.x
branch I will be retiring Hyperscan from rawhide.
The intent is to replace the hyperscan package with the vectorscan[1]
package that is currently in the last
https://bugzilla.redhat.com/show_bug.cgi?id=2230255
Emmanuel Seyman changed:
What|Removed |Added
CC||emman...@seyman.fr
--- Comment #9
Hi everyone!
RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature
was not enabled right away [2] as it requires some care to properly
transition to it. Also going back to 4.18 was technically still the
fallback option during this change.
I just noticed in an issue in the RPM
Hi.
I might have an idea how to make building Perl packages faster and their
buildroot a little bit smaller.
perl-devel depends on systemtap-sdt-devel and that package contains a
single script written in Python and using pycparser. The single script
bring python3-pycparser and therefore the
Hello,
when we build Python 3.13 with -O3
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
I see the following annocheck problem:
Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2
detected, expected -D_FORTIFY_SOURCE=3 (lto)
The C flags have:
> SPDX v3 has been published. The biggest change for us is that license
> expression
> allows lowercase operators (and, or, with).
Worth noting is that the spec [0] says thse should be
either all-lowercase or ALL-UPPERCASE:
> License expression operators (AND, and, OR, or, WITH and with)
>
On 10. 05. 24 10:55, Miroslav Suchý wrote:
Hot news:
SPDX v3 has been published. The biggest change for us is that license
expression allows lowercase operators (and, or, with). This got into the
specification because of your (Fedora maintainers) feedback!
So we can now have packages
Hot news:
SPDX v3 has been published. The biggest change for us is that license expression allows lowercase operators (and,
or, with). This got into the specification because of your (Fedora maintainers) feedback!
And there is new terminal AdditionRef-* which can be used for custom
https://bugzilla.redhat.com/show_bug.cgi?id=2230255
--- Comment #8 from Artem S. Tashkinov ---
In Fedora 40 perl-base is now needed for perl-Getopt-Long-1:2.57-3.fc40.noarch
So the list has become shorter:
perl-AutoLoader perl-Digest perl-Digest-MD5 perl-IO-Socket-IP
perl-IO-Socket-SSL
26 matches
Mail list logo
