[EPEL-devel] Re: SPDX identifiers in old branches?

On Wed, May 25, 2022 at 12:47 AM Maxwell G wrote: > I don't follow. What "rpm spec file support" are you referring to? I interpreted the proposal as adding a new stanza SPDX: in addition to License: which requires changing the definition. The follow up suggested that the license field be

Re: SPDX identifiers in old branches?

On Wed, May 25, 2022 at 12:47 AM Maxwell G wrote: > I don't follow. What "rpm spec file support" are you referring to? I interpreted the proposal as adding a new stanza SPDX: in addition to License: which requires changing the definition. The follow up suggested that the license field be

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

The following Fedora EPEL 7 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4add1d3059 needrestart-3.6-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d1317f7176 rubygem-git-1.3.0-2.el7 The following builds have

Fedora-Rawhide-20220524.n.1 compose check report

(same test not failed in Fedora-Rawhide-20220524.n.0): ID: 1277730 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1277730 ID: 1277763 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1277763 ID

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

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

[Bug 2086322] perlbrew-0.95 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2086322 Fedora Update System changed: What|Removed |Added Resolution|RAWHIDE |ERRATA Fixed In

[Bug 2086331] perl-Modern-Perl-1.20220515 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2086331 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Modern-Perl-1.20220515 |perl-Modern-Perl-1.20220515

[EPEL-devel] Re: python-passlib for python38 module

On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote: > Sure, except I know nothing about how docs.fp.o works ;) The source code for the EPEL docs page is here[1]. Honestly, I'm not super familiar with it either :). [1]: https://pagure.io/epel/tree/main > It looks like it's hard-coded

[EPEL-devel] Re: SPDX identifiers in old branches?

On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote: > I don't think that is going to work unless the rpm spec > file support would be backported to previous releases > (without another macro that tries to do some magic). I don't follow. What "rpm spec file support" are you referring

Re: SPDX identifiers in old branches?

On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote: > I don't think that is going to work unless the rpm spec > file support would be backported to previous releases > (without another macro that tries to do some magic). I don't follow. What "rpm spec file support" are you referring

Re: SPDX identifiers in old branches?

On 24. 05. 22 22:11, Miroslav Suchý wrote: As reaction to   https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 there were two similar feedbacks: * maintainer of package wants to use SPDX in both new and old branches (including f36, epel7...) * Bodhi cannot recognize old short

[Bug 2086331] perl-Modern-Perl-1.20220515 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2086331 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Modern-Perl-1.20220515 |perl-Modern-Perl-1.20220515

[EPEL-devel] Re: SPDX identifiers in old branches?

Once upon a time, Gary Buhrmaster said: > On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > > Would it make sense to make ALL the new tags be SPDX:, at least for > > an interim period (of years most likely) where both old and new tags are > > allowed? > > I don't think that is going to work

Re: SPDX identifiers in old branches?

Once upon a time, Gary Buhrmaster said: > On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > > Would it make sense to make ALL the new tags be SPDX:, at least for > > an interim period (of years most likely) where both old and new tags are > > allowed? > > I don't think that is going to work

[EPEL-devel] Re: python-passlib for python38 module

On 25. 05. 22 1:56, Orion Poplawski wrote: == Issues == * How to handle %{py3_dist} macro? I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion 3X`. It looks like it's hard-coded to python3dist, so I think it has to change to %{py38_dist}. That could (should?)

[EPEL-devel] Re: SPDX identifiers in old branches?

On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > Would it make sense to make ALL the new tags be SPDX:, at least for > an interim period (of years most likely) where both old and new tags are > allowed? I don't think that is going to work unless the rpm spec file support would be

Re: SPDX identifiers in old branches?

On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > Would it make sense to make ALL the new tags be SPDX:, at least for > an interim period (of years most likely) where both old and new tags are > allowed? I don't think that is going to work unless the rpm spec file support would be

[EPEL-devel] Re: python-passlib for python38 module

On 5/24/22 11:53, Maxwell G via epel-devel wrote: On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote: I've been coming to the thinking that naming the SRPMS python3X-%{srcname}-epel is a better choice. This makes modifying original Fedora specs simpler. I think that makes sense,

[EPEL-devel] Re: SPDX identifiers in old branches?

Once upon a time, Maxwell G via devel said: > I already brought this up previously, but how will we handle license > identifiers such as MIT that are valid in both SPDX and Fedora but have > different meanings? We won't know whether it's specifically referring to the > MIT/Expat License (SPDX)

Re: SPDX identifiers in old branches?

Once upon a time, Maxwell G via devel said: > I already brought this up previously, but how will we handle license > identifiers such as MIT that are valid in both SPDX and Fedora but have > different meanings? We won't know whether it's specifically referring to the > MIT/Expat License (SPDX)

[Bug 2089997] New: perl-CPAN-FindDependencies-3.13 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2089997 Bug ID: 2089997 Summary: perl-CPAN-FindDependencies-3.13 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-FindDependencies Keywords:

[EPEL-devel] Re: SPDX identifiers in old branches?

On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote: > We see no reason why not to do that. It should not cause any harm. If **you** know of any reason we should not propose > this, please tell us now. I already brought this up previously, but how will we handle license identifiers

Re: SPDX identifiers in old branches?

On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote: > We see no reason why not to do that. It should not cause any harm. If **you** know of any reason we should not propose > this, please tell us now. I already brought this up previously, but how will we handle license identifiers

Fedora rawhide compose report: 20220524.n.1 changes

OLD: Fedora-Rawhide-20220524.n.0 NEW: Fedora-Rawhide-20220524.n.1 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 43 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

On ۱۴۰۱/۳/۲ ۱۱:۵۵ بعدازظهر, Sebastian Crane wrote: As something of a typography enthusiast, I'm very much in support of this. For English, the consistent fonts on Fedora Workstation make a noticeable and positive effect on the general aesthetic, so anything that can widen that benefit would be

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

On ۱۴۰۱/۳/۲ ۹:۰۲ بعدازظهر, Michael Catanzaro wrote: On Mon, May 23 2022 at 11:54:30 AM -0400, Ben Cotton wrote: Default Persian font will be changed automatically on upgrades. Good, but how will you achieve this? We finally noticed that noto fonts don't get installed when upgrading F35 ->

Re: SPDX identifiers in old branches?

On Tue, May 24, 2022 at 8:11 PM Miroslav Suchý wrote: > And the Packaging Guidelines will be altered that in old active branches you > may use either the old shortname or the new > SPDX identifiers. What will better work for you. > > We see no reason why not to do that. It should not cause any

Re: PSA: I am not getting all email from Fedora, reach me directly if you need me

On Tue, May 24, 2022 at 07:08:00PM +0200, Miro Hrončok wrote: > Hello Fedorans, > > this is a just a heads up: If I ignored your question in a Pagure issue, or > your pull request, possibly haven't replied to your bugzilla report or a > devel thread... it's because my email is broken and I don't

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote: > > We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, > so we have to. But that is much easier, as the usptream is static within > intree libraries. And we have to run also for 17 and 18/19 as we need this >

[EPEL-devel] Fwd: SPDX identifiers in old branches?

Forwarded here as it will affect old epel branches. Přeposlaná zpráva Předmět:SPDX identifiers in old branches? Datum: Tue, 24 May 2022 22:11:39 +0200 Od: Miroslav Suchý Společnost: Red Hat Czech, s.r.o. Komu: Development discussions related to Fedora

SPDX identifiers in old branches?

As reaction to   https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 there were two similar feedbacks: * maintainer of package wants to use SPDX in both new and old branches (including f36, epel7...) * Bodhi cannot recognize old short names in old branches and new SPDX formulas in

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On Tue, May 24, 2022 at 5:03 PM Jiri Vanek wrote: > I replied it already in that thread, but happy to repeat: > It will help, but less then it seems so. > Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 > is in some 4 years, so fedora will suffer a bit. But it will be

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 24/05/2022 21:00, Jiri Vanek wrote: I repeat what was told several times.We really do no t like this change, especially in its full sound of one static build repacked to all ive fedoras, but we have nto found a better way. 1. Stop doing TCK certification. Most Fedora OpenJDK users don't

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

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

Interested in an updated "Exploring Our Bugs" talk at Nest?

At Nest With Fedora last year, I presented a talk called "Exploring Our Bugs"[1]. In this talk, I took a look at some summary data about Fedora Linux bugs since F19. I'm considering proposing this for Nest 2022. The new talk would mostly be an update with bugs up through F34, but if there were

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 5/24/22 18:37, Vitaly Zaitsev via devel wrote: On 24/05/2022 16:31, Jiri Vanek wrote: The goal is to go as shim and cisco - to build in koji, certify, and repack. shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. Sorry, but I can't treat the laziness of the

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 5/24/22 10:57, Jiri Vanek wrote: > > > On 5/23/22 20:40, Kevin Fenzi wrote: >> So, just replying here since this is a nice monster of a thread. ;( >> >> First, just to clear up some previous coments, shim does build against >> the oldest stable Fedora in koji and then is manually tagged into

[EPEL-devel] Re: python-passlib for python38 module

On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote: > I've been coming to the thinking that naming the SRPMS > python3X-%{srcname}-epel is a better choice. This makes modifying > original Fedora specs simpler. I think that makes sense, especially considering that these packages will

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

Once upon a time, Vitaly Zaitsev said: > Sorry, but I can't treat the laziness of the > maintainers as a good reason. Can you PLEASE stop with the personal attacks? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

PSA: I am not getting all email from Fedora, reach me directly if you need me

Hello Fedorans, this is a just a heads up: If I ignored your question in a Pagure issue, or your pull request, possibly haven't replied to your bugzilla report or a devel thread... it's because my email is broken and I don't get some (many) Fedora emails. Other colleagues from Red Hat report

pghmcfc pushed to perl-MCE-Shared (rawhide). "Update to 1.877 (..more)"

Notification time stamped 2022-05-24 12:13:06 UTC From afac8becb69640cd16f0b39f794ce3c72ceafafa Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: May 24 2022 12:11:27 + Subject: Update to 1.877 - New upstream release 1.877 - Replace http with https in documentation and meta files -

[Test-Announce] Re: Fedora 37 Rawhide 20220524.n.0 nightly compose nominated for testing

On Tue, 2022-05-24 at 09:53 +, rawh...@fedoraproject.org wrote: > Announcing the creation of a new nightly release validation test event > for Fedora 37 Rawhide 20220524.n.0. Please help run some tests for this > nightly compose if you have time. For more information on nightly

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 24/05/2022 16:31, Jiri Vanek wrote: The goal is to go as shim and cisco - to build in koji, certify, and repack. shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. Sorry, but I can't treat the laziness of the maintainers as a good reason. -- Sincerely,

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 5/21/22 13:38, Neal Gompa wrote: On Sat, May 21, 2022 at 7:28 AM Jiri Vanek wrote: On 5/20/22 14:57, Vitaly Zaitsev via devel wrote: On 20/05/2022 14:28, Jiri Vanek wrote: wait, what? What do you mean? And waht give you this impression?

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 5/23/22 20:40, Kevin Fenzi wrote: So, just replying here since this is a nice monster of a thread. ;( First, just to clear up some previous coments, shim does build against the oldest stable Fedora in koji and then is manually tagged into newer ones. This is not at all a good process. It

[Fedocal] Reminder meeting : Fedora Source-git SIG

Dear all, You are kindly invited to the meeting: Fedora Source-git SIG on 2022-05-25 from 14:30:00 to 15:30:00 GMT At meet.google.com/mic-otnv-kse The meeting will be about: Meeting of the Fedora source-git SIG Agenda: https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open SIG

Re: FESCo election nominations are now open

This is your final reminder of the nomination period for FESCo elections. You may nominate yourself (or someone else, with their permission) at https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations . Nominations must be made by 2359 UTC on Wednesday 25 May. We currently have

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On 5/21/22 13:51, Vitaly Zaitsev via devel wrote: On 21/05/2022 13:22, Jiri Vanek wrote: shim? Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for signing. This is a special legal case, just like openh264 and Cisco. Both of them built from sources on Fedora infra.

Re: [HEADS UP] Fedora 37 Boost 1.78 rebuilds starting in a side tag

On Thu, 5 May 2022 at 09:46, Miro Hrončok wrote: > > On 04. 05. 22 1:34, Thomas Rodgers wrote: > > We are starting the rebuilds for > > https://fedoraproject.org/wiki/Changes/F37Boost178 > > in the f37-boost > > side tag. > > > > If your

[Bug 2089521] perl-Math-BigInt-1.999835 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2089521 Jitka Plesnikova changed: What|Removed |Added CC|jples...@redhat.com,|

[Bug 2089613] perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

https://bugzilla.redhat.com/show_bug.cgi?id=2089613 --- Comment #2 from Tom "spot" Callaway --- It feels very much like Switch is unmaintained upstream. I tried making what seemed like the corresponding fix, but it did not resolve the issue. Any help would be greatly appreciated here. --

Fedora-Rawhide-20220524.n.0 compose check report

Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 20 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 113/231 (x86_64), 65/161 (aarch64) New failures

[Bug 2089708] perl-MCE-1.879 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2089708 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Fixed In

[modules] 'fedpkg request-branch' - how ?

Hello, I want to create a new module stream. All the RPMs repos and the Module repo exist. I just need new branches in all of them. However I've run into a deadlock. Non-release branches require SL to be defined. And SL before it is defined checks that such a branch exists. | fedpkg

Fedora rawhide compose report: 20220524.n.0 changes

OLD: Fedora-Rawhide-20220523.n.0 NEW: Fedora-Rawhide-20220524.n.0 = SUMMARY = Added images:6 Dropped images: 0 Added packages: 4 Dropped packages:0 Upgraded packages: 111 Downgraded packages: 0 Size of added packages: 1.70 MiB Size of dropped packages:0 B

[Test-Announce] Fedora 37 Rawhide 20220524.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 37 Rawhide 20220524.n.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

[Bug 2089708] New: perl-MCE-1.879 is available

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

Fedora-Cloud-34-20220524.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220523.0): ID: 1277043 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL:

Help with annocheck output

Hi, I'm trying to understand why annocheck is complaining in [1] about _FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS when these flags are defined (see [2]). A specific example, the first function reported: Hardened: /usr/lib/flexiblas/libflexiblas_fallback_lapack.so: FAIL: fortify test because

Re: Fedora 37: Add kernel parameters that help prevent local exploits

W dniu 19.05.2022 o 05:15, Hellosway Here via devel pisze: Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on randomize_kstack_offset=on vsyscall=none ` as default kernel command line arguments. Some of them are a matter of kernel configuration options. Which is

Re: Announcing the Fedora BIOS boot SIG

Hi, On 5/23/22 08:41, Adam Williamson wrote: > On Fri, 2022-05-20 at 12:18 +0200, Hans de Goede wrote: >> Hi All, >> >> Now that FESCo has decided (1) that Fedora will keep supporting BIOS >> booting, the people working on Fedora's bootloader stack will need >> help from the Fedora community to

[Bug 2089521] perl-Math-BigInt-1.999835 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2089521 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Math-BigInt-1.999834

seahorse license change from GPLv2+ and LGPLv2+ to GPLv2+ and LGPLv2+ and CC-BY-SA

While updating seahorse to the latest version, I noticed that the user documentation was incorrectly listed as being under the GFDL. After confirming with upstream, I updated to to the current CC-BY-SA license: https://gitlab.gnome.org/GNOME/seahorse/-/merge_requests/199 --

[Bug 2089613] perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

https://bugzilla.redhat.com/show_bug.cgi?id=2089613 --- Comment #1 from Petr Pisar --- Bisected to this Text-Balanced upstream's commit: commit 7bbb21936fc20ac71c820847e586999c79b3c723 (HEAD, refs/bisect/bad) Author: Ed J Date: Thu Mar 3 06:33:35 2022 + _match_codeblock regex

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

https://bugzilla.redhat.com/show_bug.cgi?id=2062024 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from

[Bug 2089613] New: perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

https://bugzilla.redhat.com/show_bug.cgi?id=2089613 Bug ID: 2089613 Summary: perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21 Product: Fedora Version: rawhide