[Bug 2091242] New: perl-Devel-REPL-1.003029 is available

[bugzilla]

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

Bug ID: 2091242
   Summary: perl-Devel-REPL-1.003029 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-REPL
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.003029
Current version/release in rawhide: 1.003028-20.fc36
URL: http://search.cpan.org/dist/Devel-REPL/

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://fedoraproject.org/wiki/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/7075/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2091242
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2090500] [EPEL9] Please branch and build perl-Cache-FastMmap in EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-73fc3c9dea has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73fc3c9dea

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2090500
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2090501] [EPEL9] Please branch and build perl-Number-Format in EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-93d3fc036a has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-93d3fc036a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2090501
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: ImageMagick in EPEL 8

[Nico Kadel-Garcia]

On Fri, May 27, 2022 at 3:01 PM Sérgio Basto  wrote:

> I'm going change this thread to epel-devel ,
>
> On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
>
> Shared message to address an issue below.
>
>
>  Forwarded Message 
> Subject: ImageMagick in EPEL 8
> Date: Wed, 25 May 2022 15:20:54 -0700
> From: Patrick J. LoPresti  
> To: l...@fedoraproject.org
>
> Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major version
> number 7, as in "libMagickWand-6.Q16.so.7".
>
> I have a number of binaries compiled for RHEL7 against ImageMagick, where
> the major number was 6, as in "libMagickWand-6.Q16.so.6". These binaries do
> not run on RHEL8 because of this major version mismatch.
>
>
Recompile them for RHEL 8. A *lot* of libraries changed. If you'd like
structure on how to do that sort of thing, look at my pretty potent setup
for ansible, at https://github.com/nkadel/ansiblerepo/ .


>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2088118] perl-libwww-perl-6.66 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-libwww-perl-6.66-1.fc3 |perl-libwww-perl-6.66-1.fc3
   |6   |6
   ||perl-libwww-perl-6.66-1.fc3
   ||4



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-540d328b79 has been pushed to the Fedora 34 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=2088118
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2088118] perl-libwww-perl-6.66 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-libwww-perl-6.66-1.fc3
   ||6
 Resolution|--- |ERRATA
Last Closed||2022-05-28 01:14:58



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-106205a321 has been pushed to the Fedora 36 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=2088118
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

[Stephen Snow]

On Fri, 2022-05-27 at 13:13 -0400, Robert Marcano via devel wrote:
> On 5/27/22 12:52 PM, Brian C. Lane wrote:
> > On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote:
> > > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:
> > > > 
> > > > The rescue mode has always been on the traditional installer
> > > > images,
> > > > not the lives. It's still there.
> > > > 
> > > Unfortunately there is no rescue option on the Fedora Linux
> > > Workstation
> > > installer just the Server and the Everything.
> > > Is this a part of Anaconda or a different package in Fedora
> > > Linux?
> > 
> > Rescue is an Anaconda feature:
> > 
> > https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py
> > 
> > https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst
> > 
> > It is not supported on live media since most of the steps just
> > don't
> > make sense -- live already sets up the network and you should be
> > able to
> > use the regular desktop tools to mount your existing partitions.
> > 
> > https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93
> 
> True, but the Live image needs something like a command like 
> "fedora-prepare-rescue-image" or something like that that just do
> what 
> the Fedora rescue option do and mount what it can find on
> /mnt/sysimage.
> 
> The steps to mount a complete /mnt/sysimage are a more than a few and
> it 
> could help a lot not needing to type many things that an untrained 
> person could make a big mistake.
> 
Agreed 100%!

Stephen
> > 
> > Brian
> > 
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

[Stephen Snow]

On Fri, 2022-05-27 at 09:52 -0700, Brian C. Lane wrote:
> On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote:
> > On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:
> > > 
> > > The rescue mode has always been on the traditional installer
> > > images,
> > > not the lives. It's still there.
> > > 
> > Unfortunately there is no rescue option on the Fedora Linux
> > Workstation
> > installer just the Server and the Everything. 
> > Is this a part of Anaconda or a different package in Fedora Linux?
> 
> Rescue is an Anaconda feature:
> 
> https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py
> 
> https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst
> 
> It is not supported on live media since most of the steps just don't
> make sense -- live already sets up the network and you should be able
> to
> use the regular desktop tools to mount your existing partitions.
> 
Sorry but how does someone with a disability navigate that?
The rescue mode while maybe unnecessary for developers and those well
verse in Fedora Linux, but the inexperienced and the disadvantged don't
get any consideration by your statement. And in the case of this
particular example I cited at the beginning, the person is having MUCH
difficulty navigating the Live USB approach to rescuing their system.


Stephen 
> https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93
> 
> Brian
> 
> -- 
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Cleaning up EPEL9 duplicate packages

[Troy Dawson]

There are 4 packages that are in epel9 that were also released with RHEL
9.0.
This isn't that big of a surprise, we knew about them.  Three managed to
get branched and built before we had the check in place.  One had a race
condition with the build in RHEL.

Two are easy to remove:
** pybind11
- Nothing in epel9 currently depends on it.
- I will remove it today
- https://bugzilla.redhat.com/show_bug.cgi?id=2091185
** tesseract
- Although a few things depend on it in epel9, nothing depends on it's
specific version.
- I will remove it today.
- https://bugzilla.redhat.com/show_bug.cgi?id=2091183

Two are harder
** libwmf
- epel9 release version is lower than RHEL, thus doesn't get installed.
- RHEL is missing libwmf-devel, thus things that depend on it to build,
will not be able to once it is removed.
- I did a check and nothing depends on libwmf-devel in runtime or
buildtime.  But I know that sometimes the buildtime checks don't always
work.
- I am waiting a week (possibly two) before I remove this package.
- https://bugzilla.redhat.com/show_bug.cgi?id=2091184
** tesseract-tessdata
- epel9 release version is lower than RHEL, thus doesn't get installed.
- There are about 150 binary sub-packages that get built, but RHEL 9.0 only
releases 2 of them.  The epel9 version has all of them.  Thus, removing
this package is rather huge.
- My opinion is that we get it moved over to tesseract-tessdata-epel and
built it without those two packages that RHEL provides.

Troy
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Fwd: ImageMagick in EPEL 8

[Sérgio Basto]

ImageMagick now provides libMagickWand-6.Q16.so.7()(64bit)  and not provides 
anymore  libMagickWand-6.Q16.so.6()(64bit) , that is called soname bump So I'm 
sorry , ImageMagick-6.9.10 -97 was release more than 2 years ago
(2020-02-29 09:40) while ImageMagick-6.9.12 still supported by
ImageMagick and have all security the fixes . 
you just need rebuild yours packages against the new ImageMagick or
just not update ImageMagick with , dnf update --exclude="ImageMagick*"
or add the line exclude="ImageMagick*" in the /etc/yum.repos.d

Sometimes we need that things change but is nothing todo with libc and
is not us which decide when dynamic libraries change his API . 




On Fri, 2022-05-27 at 12:17 -0700, Patrick J. LoPresti wrote:
> Can you explain the rationale for bumping the soname? That is
> supposed to represent a non-backwards-compatile change; i.e. rare to
> never (cf. libc.so.6 soon to enter its third decade). This just
> sounds like a security fix (?)
> 
> It kind of sucks when RHEL7 and RHEL8 cannot run the same binaries.
> 
>  - Pat
> 
> 
> On Fri, May 27, 2022 at 12:07 PM Sérgio Basto 
> wrote:
> > yes, now its provide libMagickWand-6.Q16.so.7()(64bit) [2] , you
> > need
> > rebuild your packages 
> > 
> > ImageMagick soname bump was approved [0] in EPEL Steering Committee
> > meeting. and I'm continuing with the process for incompatible
> > upgrades
> > from step 4 forward [1]. and 81 security bugs will be fixed
> > 
> > [0]
> > https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
> > [1]
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> > 
> > [2]
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158
> > 
> > 
> > On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
> > > Shared message to address an issue below.
> > > 
> > >  
> > >   Forwarded Message     Subject:  ImageMagick in
> > EPEL
> > > 8  Date:  Wed, 25 May 2022 15:20:54 -0700  From:  Patrick J.
> > LoPresti
> > >   To:  l...@fedoraproject.org 
> > >  
> > > Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major
> > > version number 7, as in "libMagickWand-6.Q16.so.7".
> > > 
> > > I have a number of binaries compiled for RHEL7 against
> > ImageMagick,
> > > where the major number was 6, as in "libMagickWand-6.Q16.so.6".
> > These
> > > binaries do not run on RHEL8 because of this major version
> > mismatch.
> > > 
> > > Has the .so really changed in a backwards-incompatible way? (When
> > I
> > > symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled
> > > applications appear to run.) If not, can I request that the
> > version
> > > in EPEL change to use .so.6?
> > > 
> > > Thanks!
> > > 
> > >  - Pat
> > > 
> > >  
> > > ___
> > > devel mailing list -- de...@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/de...@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> > 


-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Fwd: ImageMagick in EPEL 8

[Sérgio Basto]

yes, now its provide libMagickWand-6.Q16.so.7()(64bit) [2] , you need
rebuild your packages 

ImageMagick soname bump was approved [0] in EPEL Steering Committee
meeting. and I'm continuing with the process for incompatible upgrades
from step 4 forward [1]. and 81 security bugs will be fixed

[0]
https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html
[1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades

[2]
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62b1a9e158


On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
> Shared message to address an issue below.
> 
>  
>   Forwarded Message Subject:  ImageMagick in EPEL
> 8  Date:  Wed, 25 May 2022 15:20:54 -0700  From:  Patrick J. LoPresti
>   To:  l...@fedoraproject.org 
>  
> Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major
> version number 7, as in "libMagickWand-6.Q16.so.7".
> 
> I have a number of binaries compiled for RHEL7 against ImageMagick,
> where the major number was 6, as in "libMagickWand-6.Q16.so.6". These
> binaries do not run on RHEL8 because of this major version mismatch.
> 
> Has the .so really changed in a backwards-incompatible way? (When I
> symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled
> applications appear to run.) If not, can I request that the version
> in EPEL change to use .so.6?
> 
> Thanks!
> 
>  - Pat
> 
>  
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: ImageMagick in EPEL 8

[Sérgio Basto]

I'm going change this thread to epel-devel , 

On Fri, 2022-05-27 at 11:40 -0700, Luya Tshimbalanga wrote:
> Shared message to address an issue below.
> 
> 
>  Forwarded Message  Subject: ImageMagick in EPEL 8
> Date: Wed, 25 May 2022 15:20:54 -0700 From: Patrick J. LoPresti
>  To: l...@fedoraproject.org 
> 
> Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major
> version number 7, as in "libMagickWand-6.Q16.so.7".
> 
> I have a number of binaries compiled for RHEL7 against ImageMagick,
> where the major number was 6, as in "libMagickWand-6.Q16.so.6". These
> binaries do not run on RHEL8 because of this major version mismatch.
> 
> Has the .so really changed in a backwards-incompatible way? (When I
> symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled
> applications appear to run.) If not, can I request that the version
> in EPEL change to use .so.6?
> 
> Thanks!
> 
>  - Pat
> 
> 
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fwd: ImageMagick in EPEL 8

[Luya Tshimbalanga]

Shared message to address an issue below.



 Forwarded Message 
Subject:ImageMagick in EPEL 8
Date:   Wed, 25 May 2022 15:20:54 -0700
From:   Patrick J. LoPresti 
To: l...@fedoraproject.org



Hi. I just noticed that ImageMagick in EPEL for RHEL8 uses major version 
number 7, as in "libMagickWand-6.Q16.so.7".


I have a number of binaries compiled for RHEL7 against ImageMagick, 
where the major number was 6, as in "libMagickWand-6.Q16.so.6". These 
binaries do not run on RHEL8 because of this major version mismatch.


Has the .so really changed in a backwards-incompatible way? (When I 
symlink the .so.6 -> .so.7 libraries, all of my RHEL7-compiled 
applications appear to run.) If not, can I request that the version in 
EPEL change to use .so.6?


Thanks!

 - Pat
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Rhel 9 + Epel 9 - Amavis can't install

[Filip Bartmann]

Hello,
I make temporary build of perl net libidn via copr -
https://copr.fedorainfracloud.org/coprs/filbar/Amavis/package/perl-Net-LibIDN/
- FIY

st 18. 5. 2022 v 13:37 odesílatel Petr Pisar  napsal:

> V Wed, May 18, 2022 at 06:49:48AM -0400, Josh Boyer napsal(a):
> > On Wed, May 18, 2022 at 6:21 AM Filip Bartmann 
> wrote:
> > >
> > > Hello,
> > > I try to install amavis in epel for RedHat 9 Stable:
> > >
> > > dnf install amavis
> > > Updating Subscription Management repositories.
> > > Last metadata expiration check: 0:02:16 ago on Wed 18 May 2022
> 12:16:52 PM CEST.
> > > Error:
> > >  Problem: conflicting requests
> > >   - nothing provides perl(Net::LibIDN) needed by
> amavis-2.12.2-3.el9.noarch
> > > (try to add '--skip-broken' to skip uninstallable packages or
> '--nobest' to use not only best candidate packages)
> > > It want's package Net::LibIDN, but it was not found. How can I install
> amavis for RHEL 9?
> >
> > The perl-Net-LibIDN package will need to be built for EPEL 9.
> >
> It's a known issue since February
> . I wish rpmdeplint
> tests
> were performed for EPEL packages
> ,
> too.
>
> -- Petr
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2091187] New: Please build perl-File-Tail for EPEL 9

[bugzilla]

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

Bug ID: 2091187
   Summary: Please build perl-File-Tail for EPEL 9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-File-Tail
  Assignee: spo...@gmail.com
  Reporter: n...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please build perl-File-Tail for EPEL 9.  This package is needed so I can build
imapsync for EPEL 9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2091187
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 20f26bb71fe0b3b28e7683dd3f6aef46e6f5cd02 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jan 21 2022 01:24:56 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index c7791f6..5518a4c 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:17%{?dist}
+Release:18%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri Jan 21 2022 Fedora Release Engineering  - 
1.05-18
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
+
 * Thu Jul 22 2021 Fedora Release Engineering  - 
1.05-17
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/20f26bb71fe0b3b28e7683dd3f6aef46e6f5cd02?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 5be1c0c2e40925969ac90452973e2d4d786664dc Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 28 2020 15:25:17 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 3959393..a79a609 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Tue Jul 28 2020 Fedora Release Engineering  - 
1.05-14
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
+
 * Tue Jun 23 2020 Jitka Plesnikova  - 1.05-13
 - Perl 5.32 rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/5be1c0c2e40925969ac90452973e2d4d786664dc?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Perl 5.34 rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 6065512ba56ca9a6e80f1f1d53a1958c42929245 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: May 21 2021 22:22:50 +
Subject: Perl 5.34 rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 7d3027f..fe28d9b 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:15%{?dist}
+Release:16%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri May 21 2021 Jitka Plesnikova  - 1.05-16
+- Perl 5.34 rebuild
+
 * Wed Jan 27 2021 Fedora Release Engineering  - 
1.05-15
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/6065512ba56ca9a6e80f1f1d53a1958c42929245?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Perl 5.32 rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From a6be3135949216cfa58d566999361feb753c0900 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 23 2020 08:12:24 +
Subject: Perl 5.32 rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 47554e8..3959393 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:12%{?dist}
+Release:13%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Tue Jun 23 2020 Jitka Plesnikova  - 1.05-13
+- Perl 5.32 rebuild
+
 * Wed Jan 29 2020 Fedora Release Engineering  - 
1.05-12
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/a6be3135949216cfa58d566999361feb753c0900?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From afb44d7d3207a52f60ef6df79aa20886c29f33ca Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jan 29 2020 23:56:23 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index e9bc2a4..47554e8 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:11%{?dist}
+Release:12%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Wed Jan 29 2020 Fedora Release Engineering  - 
1.05-12
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
1.05-11
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/afb44d7d3207a52f60ef6df79aa20886c29f33ca?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 784cf9448263c233381d233503a5a49976a9ba4a Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jan 27 2021 01:07:27 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index a79a609..7d3027f 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Wed Jan 27 2021 Fedora Release Engineering  - 
1.05-15
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
+
 * Tue Jul 28 2020 Fedora Release Engineering  - 
1.05-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/784cf9448263c233381d233503a5a49976a9ba4a?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 585d19d41e3bd0d3961c541c5beb834b74529dd1 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 22 2021 20:05:35 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index fe28d9b..c7791f6 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:16%{?dist}
+Release:17%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Thu Jul 22 2021 Fedora Release Engineering  - 
1.05-17
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
+
 * Fri May 21 2021 Jitka Plesnikova  - 1.05-16
 - Perl 5.34 rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/585d19d41e3bd0d3961c541c5beb834b74529dd1?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 7765365c6cd4272385f1b7a94885f77a3076899d Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 13 2018 17:12:28 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 4b1392a..819a442 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:7%{?dist}
+Release:8%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri Jul 13 2018 Fedora Release Engineering  - 
1.05-8
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
+
 * Thu Jun 28 2018 Jitka Plesnikova  - 1.05-7
 - Perl 5.28 rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/7765365c6cd4272385f1b7a94885f77a3076899d?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Perl 5.30 rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 6cddf4b024ef1efa0cc6339aea717d52ba7abf97 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: May 31 2019 05:01:58 +
Subject: Perl 5.30 rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index e3d1419..128900e 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri May 31 2019 Jitka Plesnikova  - 1.05-10
+- Perl 5.30 rebuild
+
 * Fri Feb 01 2019 Fedora Release Engineering  - 
1.05-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/6cddf4b024ef1efa0cc6339aea717d52ba7abf97?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "cpan.org addresses moved to MetaCPAN "

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From f3edab4c7d0a0f9dde15dccf4b9b16136669d1f8 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:43:47 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index dc7f660..bed6b4b 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -5,8 +5,8 @@ Version:1.05
 Release:6%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
-Source0:
http://www.cpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
+URL:https://metacpan.org/release/Encode-IMAPUTF7
+Source0:
https://cpan.metacpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  make perl-interpreter perl-generators



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/f3edab4c7d0a0f9dde15dccf4b9b16136669d1f8?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 94b84b57cd57a7c4ffb2f2660db614c3f36404c1 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 01 2019 20:27:17 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 819a442..e3d1419 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri Feb 01 2019 Fedora Release Engineering  - 
1.05-9
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
+
 * Fri Jul 13 2018 Fedora Release Engineering  - 
1.05-8
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/94b84b57cd57a7c4ffb2f2660db614c3f36404c1?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Perl 5.28 rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From e8b13c9ec0f81b403793e064c5e21294bf9ffd15 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 28 2018 10:29:25 +
Subject: Perl 5.28 rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index bed6b4b..4b1392a 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Thu Jun 28 2018 Jitka Plesnikova  - 1.05-7
+- Perl 5.28 rebuild
+
 * Thu Feb 08 2018 Fedora Release Engineering  - 
1.05-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/e8b13c9ec0f81b403793e064c5e21294bf9ffd15?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 47771aa8c0c75f1e6d7ddcfac31718cf02b1323a Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 26 2019 02:42:18 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 128900e..e9bc2a4 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Fri Jul 26 2019 Fedora Release Engineering  - 
1.05-11
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
+
 * Fri May 31 2019 Jitka Plesnikova  - 1.05-10
 - Perl 5.30 rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/47771aa8c0c75f1e6d7ddcfac31718cf02b1323a?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 28a22af4b27bd9e8d72856b2f38a7618fe9d22a2 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 27 2017 03:46:27 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 1e70263..f8ffda1 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:4%{?dist}
+Release:5%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Thu Jul 27 2017 Fedora Release Engineering  - 
1.05-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
+
 * Sun Jun 04 2017 Jitka Plesnikova  - 1.05-4
 - Perl 5.26 rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/28a22af4b27bd9e8d72856b2f38a7618fe9d22a2?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From d8f8560f4b2b16d69317ba4b4407275925a36693 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 11 2017 02:53:36 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 4a334ac..900a3a4 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Sat Feb 11 2017 Fedora Release Engineering  - 
1.05-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
+
 * Wed Nov 09 2016 Jason L Tibbitts III  - 1.05-2
 - Add more build dependencies.
 - Use DESTDIR instead of cpanspec-provided PERL_INSTALL_ROOT.



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/d8f8560f4b2b16d69317ba4b4407275925a36693?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Perl 5.26 rebuild"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 842869d5b0a259892784f3dcf0fb0fb6272c00b9 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Jun 04 2017 19:32:30 +
Subject: Perl 5.26 rebuild


---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 900a3a4..bb5f779 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:3%{?dist}
+Release:4%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Sun Jun 04 2017 Jitka Plesnikova  - 1.05-4
+- Perl 5.26 rebuild
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
1.05-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/842869d5b0a259892784f3dcf0fb0fb6272c00b9?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2091186] New: Please build perl-PAR-Packer for epel9

[bugzilla]

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

Bug ID: 2091186
   Summary: Please build perl-PAR-Packer for epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-PAR-Packer
  Assignee: ppi...@redhat.com
  Reporter: n...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Please build perl-PAR-Packer for EPEL 9.  This package is needed so I can build
imapsync for EPEL 9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2091186
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Initial spec and sources import."

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 27bceff70f472202375e19e7d79996a992532666 Mon Sep 17 00:00:00 2001
From: Jason Tibbitts 
Date: Nov 11 2016 01:02:24 +
Subject: Initial spec and sources import.


---

diff --git a/.gitignore b/.gitignore
index e69de29..6cf6477 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1,3 @@
+*.src.rpm
+/Encode-IMAPUTF7-1.05.tar.gz
+results-*/
diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
new file mode 100644
index 000..4a334ac
--- /dev/null
+++ b/perl-Encode-IMAPUTF7.spec
@@ -0,0 +1,52 @@
+%global remove_lf() for i in %*; do tr -d '\\r' < $i > $i. && touch $i $i. && 
mv -f $i. $i; done
+
+Name:   perl-Encode-IMAPUTF7
+Version:1.05
+Release:2%{?dist}
+Summary:Process the special UTF-7 variant required by IMAP
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
+Source0:
http://www.cpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
+BuildArch:  noarch
+
+BuildRequires:  make perl perl-generators
+BuildRequires:  perl(base) perl(Encode) perl(Encode::Encoding)
+BuildRequires:  perl(ExtUtils::MakeMaker) perl(File::Basename) perl(File::Spec)
+BuildRequires:  perl(MIME::Base64) perl(strict) perl(Test::More)
+BuildRequires:  perl(Test::NoWarnings) perl(warnings)
+
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+This module is able to encode and decode IMAP mailbox names using the UTF-7
+modification specified in RFC2060 section 5.1.3.
+
+%prep
+%autosetup -n Encode-IMAPUTF7-%{version}
+%remove_lf README Changes
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+%make_build
+
+%install
+make pure_install DESTDIR=%buildroot
+%_fixperms %buildroot/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%_mandir/man3/*
+
+%changelog
+* Wed Nov 09 2016 Jason L Tibbitts III  - 1.05-2
+- Add more build dependencies.
+- Use DESTDIR instead of cpanspec-provided PERL_INSTALL_ROOT.
+- Build with NO_PACKLIST=1 and don't bother deleting .packlist files.
+
+* Wed Nov 02 2016 Jason Tibbitts  1.05-1
+- Specfile autogenerated by cpanspec 1.78.
+- Cleaned up the generated spec to meet current guidelines.
diff --git a/sources b/sources
index e69de29..acd2c53 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+2ef9d1a438f3fa29771d24f9e587fd2a  Encode-IMAPUTF7-1.05.tar.gz



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/27bceff70f472202375e19e7d79996a992532666?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "Tweak .gitignore."

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 0b386f3a26b2d06fe1f1a6b0146b58f91e5b3cff Mon Sep 17 00:00:00 2001
From: Jason Tibbitts 
Date: Nov 14 2016 15:37:42 +
Subject: Tweak .gitignore.


---

diff --git a/.gitignore b/.gitignore
index 6cf6477..d981021 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,3 @@
 *.src.rpm
 /Encode-IMAPUTF7-1.05.tar.gz
-results-*/
+results_*/



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/0b386f3a26b2d06fe1f1a6b0146b58f91e5b3cff?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From e6957e3841181ffa4b0b9dbb256b95796ecd3dd3 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Feb 08 2018 20:54:48 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index f8ffda1..dc7f660 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
@@ -42,6 +42,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Thu Feb 08 2018 Fedora Release Engineering  - 
1.05-6
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
+
 * Thu Jul 27 2017 Fedora Release Engineering  - 
1.05-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/e6957e3841181ffa4b0b9dbb256b95796ecd3dd3?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

nb pushed to perl-Encode-IMAPUTF7 (epel9). "perl dependency renamed to perl-interpreter "

[notifications]

Notification time stamped 2022-05-27 17:59:04 UTC

From 8d4722e7598a3338c72154d75bec86b3dabc3e5a Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jul 12 2017 12:52:20 +
Subject: perl dependency renamed to perl-interpreter 



---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index bb5f779..1e70263 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -9,7 +9,7 @@ URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
 Source0:
http://www.cpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
 BuildArch:  noarch
 
-BuildRequires:  make perl perl-generators
+BuildRequires:  make perl-interpreter perl-generators
 BuildRequires:  perl(base) perl(Encode) perl(Encode::Encoding)
 BuildRequires:  perl(ExtUtils::MakeMaker) perl(File::Basename) perl(File::Spec)
 BuildRequires:  perl(MIME::Base64) perl(strict) perl(Test::More)



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/8d4722e7598a3338c72154d75bec86b3dabc3e5a?branch=epel9
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

[Robert Marcano via devel]

On 5/27/22 12:52 PM, Brian C. Lane wrote:

On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote:

On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:


The rescue mode has always been on the traditional installer images,
not the lives. It's still there.


Unfortunately there is no rescue option on the Fedora Linux Workstation
installer just the Server and the Everything.
Is this a part of Anaconda or a different package in Fedora Linux?


Rescue is an Anaconda feature:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py

https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst

It is not supported on live media since most of the steps just don't
make sense -- live already sets up the network and you should be able to
use the regular desktop tools to mount your existing partitions.

https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93


True, but the Live image needs something like a command like 
"fedora-prepare-rescue-image" or something like that that just do what 
the Fedora rescue option do and mount what it can find on /mnt/sysimage.


The steps to mount a complete /mnt/sysimage are a more than a few and it 
could help a lot not needing to type many things that an untrained 
person could make a big mistake.




Brian


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

[Brian C. Lane]

On Fri, May 27, 2022 at 09:38:43AM -0400, Stephen Snow wrote:
> On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:
> > 
> > The rescue mode has always been on the traditional installer images,
> > not the lives. It's still there.
> > 
> Unfortunately there is no rescue option on the Fedora Linux Workstation
> installer just the Server and the Everything. 
> Is this a part of Anaconda or a different package in Fedora Linux?

Rescue is an Anaconda feature:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/rescue.py

https://github.com/rhinstaller/anaconda/blob/master/docs/rescue.rst

It is not supported on live media since most of the steps just don't
make sense -- live already sets up the network and you should be able to
use the regular desktop tools to mount your existing partitions.

https://github.com/rhinstaller/anaconda/blob/master/data/liveinst/liveinst#L93

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Feedback on New Anaconda Installer

[Florencia Forno]

Hi everyone,

The User Experience Research team at Red Hat is conducting a study on
Anaconda Installer's new interface. If you are interested in an opportunity
to influence the future of Anaconda Installer, please fill out this brief
survey .

Browser link:
https://redhatdg.co1.qualtrics.com/jfe/form/SV_3wVqDVLem1HPyK2

We will contact you if your experience matches what we need for this study.
We expect to begin in mid June.

Thank you,
*Flo Forno*
UX Researcher
*Dallas, TX*
--
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Peter Boy]

> Am 27.05.2022 um 17:37 schrieb Vitaly Zaitsev via devel 
> :
> 
> On 27/05/2022 15:30, Peter Boy wrote:
>> Really sorry, but such a statement is simply intellectual bullshit. 
>> Unfortunately, it is not possible to formulate this in a more friendly yet 
>> unambiguous way. And in this thread in particular, the many allegations, 
>> unclouded by any expertise but made all the more decisively, are simply 
>> annoying - and a huge waste of everyone’s time in the long run.
> 
> But it's true.
> 
> One of my packages had a bundled library with 6 critical vulnerabilities 
> (outdated for 5 years). The upstream developers said they didn't care because 
> they needed their app to run under Ubuntu 12.04 LTS. Fixed it manually by 
> switching to the packaged version.
> 
> Another package had bundled OpenSSL, which was 3 years out of date.

Yes, but your examples and experiences are not related to a lib bundled or not, 
but it is about the effort a maintainer puts in their package. We had also 
(unbundled) libs, which were outdated and we had to wait a long time until a 
vulnerability was fixed.

And given the high quality of our openjdk packages and given experiences of the 
last nearly 2 decades with the regularity of updates, I’m sure we get an 
openjdk update as soon as an issue with one of the bundled libs arises. 


And as an afterthought:
Sorry for the wording. I was (and I am) seriously annoyed by this thread (and 
some others of that kind). 

We have had such excellent Java JDKs for years and right now in the last 4 
major JDK versions in parallel, that is just great!  It is allowing any 
developer to test their software in a comprehensive and enterprise ready 
manner. 

This deserves unrestricted respect and not this nagging about problems that are 
claimed but do not exist. If someone is not so well versed in Java universe, no 
problem. Everyone is welcome to ask questions, but not to throw any wild 
assertions into the room. 


Thanks
Peter



--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring Python 3.7 before Python 3.6?

[Neal Gompa]

On Fri, May 27, 2022 at 11:35 AM Miro Hrončok  wrote:
>
> On 27. 05. 22 14:34, Neal Gompa wrote:
> > While unfortunate, I think it makes sense to retire Python 3.7 when
> > Debian 10 goes EOL.
>
> I don't understand why do you consider this unfortunate.
>

The situation is unfortunate, not the result.

> > I think the larger question is how do we write
> > down a multi-Python maintenance policy to codify this?
>
> It has been so far implicitly (but indeed not written) somehow like this:
>
> "We keep a Python version in Fedora as long as:
>
> 1) A "significant enough" platform that our users could be deploying into runs
> that Python version. That has always been at least RHEL, Debian and Ubuntu 
> LTS.
>
> 2) It is bearable for the maintainers."
>
> 1 means we drop it when it's no longer useful.
> 2 means we drop when we cannot longer make it work with the current resources.
>
> > The implicit
> > assumption here is that we're going to be able to leverage security
> > support work in other distributions to keep other Python runtimes
> > alive, but I don't think we've got that written down anywhere.
>
> At least for RHEL, we still use Fedora as upstream for our patches. So as long
> as a Python is supported in RHEL, we would (in most cases) try to fix Fedora
> together with RHEL.
>
> For upstream EOLed Pythons that are not in RHEL but are supported in other
> distros (e.g. Python 3.7 will  be supported in Debian for ~1 additional year
> after upstream EOL, but is not included in RHEL), we don't know yet (it never
> happened until now).
>
> > Moreover, we don't have anything written down for where to reference
> > and source security fixes across distributions for multi-Python
> > (assuming that's a goal here).
>
> Not necessarily my goal, but a nice goal nevertheless.
>
> > If we're not doing any of that, then I'm not sure why other
> > distributions matter for our multi-Python support beyond just making
> > it easier to target those distributions. And if that's true, then we
> > should have that codified too.
>
> Making it easier to use Fedora when you target those distributions was my
> primary goal here.
>

Makes sense to me.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 11/231 (x86_64), 14/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220526.n.0):

ID: 1280864 Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1280864
ID: 1280890 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1280890
ID: 1280934 Test: x86_64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/1280934
ID: 1280949 Test: aarch64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1280949
ID: 1280998 Test: aarch64 Server-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1280998
ID: 1281042 Test: x86_64 Workstation-upgrade 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1281042
ID: 1281056 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1281056
ID: 1281059 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1281059
ID: 1281060 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1281060
ID: 1281062 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1281062
ID: 1281064 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1281064
ID: 1281073 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1281073
ID: 1281081 Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/1281081
ID: 1281083 Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1281083
ID: 1281149 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1281149
ID: 1281189 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1281189
ID: 1281278 Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/1281278

Old failures (same test failed in Fedora-Rawhide-20220526.n.0):

ID: 1280898 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1280898
ID: 1280903 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1280903
ID: 1280952 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1280952
ID: 1280983 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/1280983
ID: 1280985 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/1280985
ID: 1281040 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1281040
ID: 1281041 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1281041
ID: 1281266 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1281266

Soft failed openQA tests: 8/231 (x86_64), 8/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20220526.n.0):

ID: 1280855 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/1280855
ID: 1281066 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1281066
ID: 1281122 Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/1281122
ID: 1281178 Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1281178
ID: 1281277 Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/1281277

Old soft failures (same test soft failed in Fedora-Rawhide-20220526.n.0):

ID: 1280870 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1280870
ID: 1280916 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1280916
ID: 1280917 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1280917
ID: 1280922 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1280922
ID: 1280923 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1280923
ID: 1280931 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1280931
ID: 1280946 Test: aarch64 Server-boot-iso 

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

[Vitaly Zaitsev via devel]

On 27/05/2022 15:30, Peter Boy wrote:

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run.


But it's true.

One of my packages had a bundled library with 6 critical vulnerabilities 
(outdated for 5 years). The upstream developers said they didn't care 
because they needed their app to run under Ubuntu 12.04 LTS. Fixed it 
manually by switching to the packaged version.


Another package had bundled OpenSSL, which was 3 years out of date.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring Python 3.7 before Python 3.6?

[Miro Hrončok]

On 27. 05. 22 14:34, Neal Gompa wrote:

While unfortunate, I think it makes sense to retire Python 3.7 when
Debian 10 goes EOL.


I don't understand why do you consider this unfortunate.


I think the larger question is how do we write
down a multi-Python maintenance policy to codify this?


It has been so far implicitly (but indeed not written) somehow like this:

"We keep a Python version in Fedora as long as:

1) A "significant enough" platform that our users could be deploying into runs 
that Python version. That has always been at least RHEL, Debian and Ubuntu LTS.


2) It is bearable for the maintainers."

1 means we drop it when it's no longer useful.
2 means we drop when we cannot longer make it work with the current resources.


The implicit
assumption here is that we're going to be able to leverage security
support work in other distributions to keep other Python runtimes
alive, but I don't think we've got that written down anywhere.


At least for RHEL, we still use Fedora as upstream for our patches. So as long 
as a Python is supported in RHEL, we would (in most cases) try to fix Fedora 
together with RHEL.


For upstream EOLed Pythons that are not in RHEL but are supported in other 
distros (e.g. Python 3.7 will  be supported in Debian for ~1 additional year 
after upstream EOL, but is not included in RHEL), we don't know yet (it never 
happened until now).



Moreover, we don't have anything written down for where to reference
and source security fixes across distributions for multi-Python
(assuming that's a goal here).


Not necessarily my goal, but a nice goal nevertheless.


If we're not doing any of that, then I'm not sure why other
distributions matter for our multi-Python support beyond just making
it easier to target those distributions. And if that's true, then we
should have that codified too.


Making it easier to use Fedora when you target those distributions was my 
primary goal here.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: remove-retired-packages feedback

[stan via devel]

On Thu, 26 May 2022 15:52:06 +0200
Miroslav Suchý  wrote:

> If you already upgraded to Fedora 36 - what is your feedback about
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
> 
> Did you run the command `remove-retired-packages`? Do you find it
> useful? Comments and ideas are welcome either here or at:
> 
> https://github.com/xsuchy/fedora-upgrade/issues
> 
> Just be sure that you have latest version, i.e.,
> remove-retired-packages-36.3.

Thanks for creating this, a nice tool.  I run rawhide, and it found no
retired packages for f36 or f37.  I think that would be expected by
default.  I agree that deciding on removal of each package individually
is the right choice.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: remove-retired-packages feedback

[Gary Buhrmaster]

On Thu, May 26, 2022 at 1:52 PM Miroslav Suchý  wrote:
>
> If you already upgraded to Fedora 36 - what is your feedback about
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
>
> Did you run the command `remove-retired-packages`? Do you find it useful? 
> Comments and ideas are welcome either here or at:

I used to (irregularly) manually go
through my systems that have been
upgraded through many versions to
remove old packages.  I never
bothered to script it since I always
thought I would be doing it so rarely
since I believed the next upgrade I
would install the system from scratch,
and which I said to myself every time
I performed that manual process.

Having someone else do that
scripting is welcome.  Thanks.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: How to remove builds from EPEL 9 Next?

[Troy Dawson]

On Fri, May 27, 2022 at 5:38 AM Neal Gompa  wrote:

> On Fri, May 27, 2022 at 8:00 AM Miro Hrončok  wrote:
> >
> > Hey EPEL folks,
> >
> > The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0
> GA, as
> > the frozen set of packages from CentOS Stream made it segfault during
> build.
> >
> > So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
> >
> > Now, it builds in regular EPEL 9 successfully (as the segfault was fixed
> in the
> > meantime).
> >
> > So, we should probbaly build and ship the package in EPEL 9.
> > But we should also remove/obsolete/replace the EPEL 9 build somehow.
> >
> > I suppose there are multiple options here:
> >
> >
> > 1. bump and build in epel9, so the EVR is higher, do nothing with
> epel9-next
> > 2. build in epel9, untag the old epel9-next build
> >
>
> Generally, you bump to raise the EVR and then the automation Troy has
> can untag everything in EPEL next that's lower than what's in EPEL.
>
>
If you have a package, or list of packages that you want me to untag out of
epel9-next, let me know.
I think either (1) or (2) is a valid way to do things.
1 - If you bump and build in epel9 and just leave it in epel9-next, it will
get cleaned up next time I "purge" the epel9-next repo.
2 - If you build in epel9, and untag it in epel9-next, that's great too.
Just know that CentOS Stream users that already had the -next packages
installed, won't automatically get updated.  That may, or may not, matter
to you.

>
> > What is the general guideline in this situation?
> >
> > Related, but not necessarily blocking question: Should EPEL 9 Next be
> purged
> > after each RHEL 9.Y release and all the purged builds built in regular
> EPEL 9
> > instead?
> >
>
> Yes, please, for the sake of my mirror hosting space...
>
>
Yes, I plan on doing this at each release.  And I did it before the RHEL
9.0 release.  I sent an email making sure everyone was ok with what I was
removing.
It isn't a complete purge.
- I checked to see if there were any epel9-next packages that had the same,
or older NVR's.
- I verified that the regular epel9 packages in that list were installable
in CentOS Stream 9.
- I sent an email to epel-devel to double check.
That cleared out everything but two packages.

epel8-next numbers are fairly small, and I know that about half of them are
for RHEL 8.7, but I'll give it a pass as well, see what can be cleared out.
Troy
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Peter Boy]

> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel 
> :
> 
> Bundled libraries are always outdated and even vulnerable. 

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run. 

With technically correct workflow, there is at least a time x where the 
included libs are not outdated and where vulnerability is unknown at worst. How 
someone comes up with "always" is beyond me.

And whether to include a lib in a package is a tradeoff between various pros 
and cons. Depending on the circumstances, the result is different. 

The Change proposal correctly includes several reasons for consideration. And 
no viable argument has yet been put forward as to why the consideration given 
is *necessarily* incorrect. 

Several conceivable alternatives would also be viable. But as long as no one is 
directly affected in a negative way and no one comes forward to do the work 
involved with an alternative,  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Peter Boy]

> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel 
> :
> 
> Bundled libraries are always outdated and even vulnerable. 

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run. 

With technically correct workflow, there is at least a time x where the 
included libs are not outdated and where vulnerability is unknown at worst. How 
someone comes up with "always" is beyond me.

And whether to include a lib in a package is a tradeoff between various pros 
and cons. Depending on the circumstances, the result is different. 

The Change proposal correctly includes several reasons for consideration. And 
no viable argument has yet been put forward as to why the consideration given 
is *necessarily* incorrect. 

Several conceivable alternatives would also be viable. But as long as no one is 
directly affected in a negative way and no one comes forward to do the work 
involved with an alternative,  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Live USB rescue mode, do we still have one? Does it work?

[Stephen Snow]

On Wed, 2022-05-25 at 14:02 -0700, Adam Williamson wrote:
> On Wed, 2022-05-25 at 16:40 -0400, Stephen Snow wrote:
> > Hello,
> > I was doing my usual round of reading comments on ask.fp.o and came
> > across an individual having difficulty getting their system
> > (?back?) up
> > and running, after update? 
> > This prompted me to open a discussion at
> > https://discussion.fedoraproject.org/t/we-really-do-need-to-have-a-working-rescue-option-for-fedora-linux/39415
> > which also has a link to the original discussion on ask.fp.o if
> > anyone
> > is interested. 
> > I haven't used the live image system rescue option since almost
> > forever
> > , so I am assuming that it isn't working or is somehow difficult to
> > use
> > for this person, or maybe not an option anymore. 
> > I'm burning a F36WS installation with media writer to try out the
> > rescue option, if it is still there.
> 
> The rescue mode has always been on the traditional installer images,
> not the lives. It's still there.
> 
Unfortunately there is no rescue option on the Fedora Linux Workstation
installer just the Server and the Everything. 
Is this a part of Anaconda or a different package in Fedora Linux?

Regards,

Stephen
> -- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: How to remove builds from EPEL 9 Next?

[Ben Beasley]

Thanks for asking this question (and for the heads-up that the problem 
is fixed). I’ll do as Neal suggested for python-Rtree, as well as a 
couple of other packages (python-mapbox-earcut, iml) that were in a 
similar situtation.


– Ben

On 5/27/22 08:37, Neal Gompa wrote:

On Fri, May 27, 2022 at 8:00 AM Miro Hrončok  wrote:

Hey EPEL folks,

The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as
the frozen set of packages from CentOS Stream made it segfault during build.

So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.

Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the
meantime).

So, we should probbaly build and ship the package in EPEL 9.
But we should also remove/obsolete/replace the EPEL 9 build somehow.

I suppose there are multiple options here:


1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next
2. build in epel9, untag the old epel9-next build


Generally, you bump to raise the EVR and then the automation Troy has
can untag everything in EPEL next that's lower than what's in EPEL.


What is the general guideline in this situation?

Related, but not necessarily blocking question: Should EPEL 9 Next be purged
after each RHEL 9.Y release and all the purged builds built in regular EPEL 9
instead?


Yes, please, for the sake of my mirror hosting space...



___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: How to remove builds from EPEL 9 Next?

[Neal Gompa]

On Fri, May 27, 2022 at 8:00 AM Miro Hrončok  wrote:
>
> Hey EPEL folks,
>
> The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as
> the frozen set of packages from CentOS Stream made it segfault during build.
>
> So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
>
> Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in 
> the
> meantime).
>
> So, we should probbaly build and ship the package in EPEL 9.
> But we should also remove/obsolete/replace the EPEL 9 build somehow.
>
> I suppose there are multiple options here:
>
>
> 1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next
> 2. build in epel9, untag the old epel9-next build
>

Generally, you bump to raise the EVR and then the automation Troy has
can untag everything in EPEL next that's lower than what's in EPEL.

>
> What is the general guideline in this situation?
>
> Related, but not necessarily blocking question: Should EPEL 9 Next be purged
> after each RHEL 9.Y release and all the purged builds built in regular EPEL 9
> instead?
>

Yes, please, for the sake of my mirror hosting space...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring Python 3.7 before Python 3.6?

[Neal Gompa]

On Fri, May 27, 2022 at 6:07 AM Miro Hrončok  wrote:
>
> Hey Pythonistas,
>
> let me include you in my dilemma I have wrt different Python versions we
> support in Fedora for testing.
>
> tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for
> RHEL 8, but 3.7 will no longer be "needed". However, retiring mid-order might
> be confusing.
>
> Note that this topic is not urgent at all, I am just curious about what is the
> best plan for the future.
>
>
> Python 3.7 retirement date
> ==
>
> Python 3.7 has security support upstream until June, 2023.
>
> It is also used in Debian 10 “Buster” -- LST ends June, 2024.
>
> Ubuntu seem to have skipped this Python version, so no LTS to consider there.
> Same with the SUSE Linux Enterprise Server.
>
> If nothing changes significantly, Fedora 40 will be released in April 2024,
> hence the natural thing to do would be to retire Python 3.7 in Fedora 40.
>
> (I might have made an error, evaluating the dates. Please, do correct me if
> there is a significant platform that supports Python 3.7 beyond Debian 10 LTS
> EOL or if some dates are wrong.)
>
>
> Python 3.6 retirement date
> ==
>
> Python 3.6 will be supported until RHEL 8 goes EOL. Which will likely not
> happen until 2029 [1]. That means, we might consider retiring it in Fedora 50
> (wow).
>
>
> My dilemma
> ==
>
> If we retire 3.7 before 3.6, the situation will be harder to explain to our
> users. Why is there a gap, they might ask. In the future, the list of 
> supported
> Python versions might look weird and contain multiple gaps as we are 
> eventually
> going to face this situation again with 3.8, 3.10...
>
> If we keep 3.7 around until 3.6 goes down, it will be harder to maintain. If 
> it
> was just 3.7, that would probably be acceptable, but assuming no release
> schedules change, we will likely have Python 3.18 in Fedora 50. That means we
> would need to support 12 different Python 3.X versions by then if we haven't
> started introducing those gaps. Now we support 6.
>
> As I written this down, I think the better thing to do is to accept the gaps
> and retire Python 3.7 before Python 3.6 right away and not decide to "keep it
> around, as we still support both 3.6 and 3.8". WDYT?
>
>
> [1] https://access.redhat.com/support/policy/updates/errata
>

While unfortunate, I think it makes sense to retire Python 3.7 when
Debian 10 goes EOL. I think the larger question is how do we write
down a multi-Python maintenance policy to codify this? The implicit
assumption here is that we're going to be able to leverage security
support work in other distributions to keep other Python runtimes
alive, but I don't think we've got that written down anywhere.
Moreover, we don't have anything written down for where to reference
and source security fixes across distributions for multi-Python
(assuming that's a goal here).

If we're not doing any of that, then I'm not sure why other
distributions matter for our multi-Python support beyond just making
it easier to target those distributions. And if that's true, then we
should have that codified too.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Miro Hrončok]

On 26. 05. 22 17:16, Maxwell G via devel wrote:

On Thursday, May 26, 2022 9:14:14 AM CDT Petr Pisar wrote:

Does a marker of the conversion need to be visible in the binary packages?


I think it should be. According to the Change Proposal, "the use of a standardized 
identifier for license will align Fedora with other distributions. And allows efficient 
and reliable identification of licenses." If we want to effectively accomplish the 
second goal, we should try to make the license identifiers *less* ambiguous than before. 
In order to do that, I think the RPMs we distribute should clearly state whether they 
have been converted to use SPDX identifiers.


If we want to do that (and I am not saying we should), and we want to avoid 
"polluting" the actual license information  with a prefix, we can add provides:


License: MIT
Provides: this-package-uses-a-spdx-license-tag()

However, the License tag is imlicitly inherited from the base package to all 
subpackages, while the Provides are not, so this would probably be a bit harder 
to do automatically and packagers will forget about that or even easily get it 
wrong.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Vitaly Zaitsev via devel]

On 26/05/2022 20:29, Stephen Snow wrote:

Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported?


OpenJDK is a native ELF binary, not a JAR.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

CPE Weekly Update – Week 21 2022

[Lenka Segura]

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering) Team.
If you have any questions or feedback, please respond to this report or
contact us on #redhat-cpe channel on libera.chat (https://libera.chat/).

Week: 23rd May - 27th May 2022

If you wish to read this in form of a blog post, check the post on Fedora
community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update---week-21-2022/

# Highlights of the week

## Infrastructure & Release Engineering
Goal of this Initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure
and preparing things for the new Fedora release (mirrors, mass branching,
new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives
that CPE might take on.
Link to planning board: https://zlopez.fedorapeople.org/I

Update
--
* Infra and releng team was investigating Openshift in AWS for communishift
and CentOS CI

### Fedora Infra
* Ocp3 certs expired, had to renew/push new ones (~20min outage)
* Finished up a mass update/reboot. Things up on 8.6 now.
* Hit bug in new ansible-freeipa and filed it upstream
* Got first RHEL9 staging virthost installed
* Bunch of email issues to/from redhat.com, hopefully almost all solved now.
* OCP4 clusters moved to 4.10.
* Some compose machines moved to f36 already.


### CentOS Infra including CentOS CI
* CentOS Stream storage migration spike (Netapp for nfs/iscsi) (blocked :
no news)
* Duffy/CI progress:
* Site-to-site vpn tunnel between VPC (us-east-1) and CI infra
* delegated/hosted (dynamic) pool.ci.centos.org zone on route53
* Dns forwarding (both directions : vpc ⇔ ci infra)
* Ansible playbooks ready
* Git.centos.org pagure upgrade/migration (blocked, waiting on internal -
EXD)
* Business as usual (mirrors, tags)


### Release Engineering
* f32/33 archived. Old rc’s cleaned up


## CentOS Stream
Goal of this Initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this new
distribution a reality. The goal of this initiative is to prepare the
ecosystem for the new CentOS Stream.

Updates
---
* Working on first modules and software collections for CentOS Stream 9
* Changing the Fedora ELN Everything repository to only contain what's not
in AppStream, BaseOS, and CRB, and renaming it to Extras
* Getting CentOS Stream 8 workflow closer to 9:
* Currently testing "import latest modules", expect to have modules
imported early next week.
* Updating is currently manual for both modules and normal RPMs, also
working on an automated import script to run at regular intervals.  Expect
to be finished next week.


## CentOS Duffy CI
Goal of this Initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to provision
and access bare metal resources of multiple architectures for the purposes
of CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks
which can be used to create VMs using the OpenNebula API, but due to the
current state of how Duffy is deployed, we are blocked with new dev work to
add the VM checkout functionality.

Updates
---
* Skip beta and release 3.0.0
* Continue work on provisioning nodes for Duffy in EC2
* CLI for tenants (what was cicoclient, ongoing)


## Package Automation (Packit Service)
Goal of this initiative
---
Automate RPM packaging of infra apps/packages

Updates
---
* Package proposal on fasjson created on bugzilla
* Release of fedora-messaging 3.0.2
* Packit added to noggin-messaging (noggin dependency)
* Packaging datanommer.models in progress (datagrepper dependency)
* Business as usual, a lot of manual packaging


## Flask-oidc: oauth2client replacement
Goal of this initiative
---
Flask-oidc is a library used across the Fedora infrastructure and is the
client for ipsilon for its authentication. flask-oidc uses oauth2client.
This library is now deprecated and no longer maintained. This will need to
be replaced with authlib.

Updates:

* Test-auth app running, allows user to successfully login using Fedora
acct details (https://app-flask-oidc-dev.apps.ocp.stg.fedoraproject.org/)
* Implementing authlib function changes in codebase (
https://github.com/fedora-infra/test-auth/blob/authlib_dev/test_auth/flask_oidc.py
)
* Trying to pull user info from login creds


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates, maintains, and manages a high quality set of additional
packages for Enterprise Linux, including, but not limited to, Red Hat
Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle 

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

[Vitaly Zaitsev via devel]

On 26/05/2022 19:31, drago01 wrote:
But bundled libs and properly tested / certified vs dynamic linking and 
less testing / no certification.


Bundled libraries are always outdated and even vulnerable. We should 
avoid bundling as much as possible.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] How to remove builds from EPEL 9 Next?

[Miro Hrončok]

Hey EPEL folks,

The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as 
the frozen set of packages from CentOS Stream made it segfault during build.


So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.

Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the 
meantime).


So, we should probbaly build and ship the package in EPEL 9.
But we should also remove/obsolete/replace the EPEL 9 build somehow.

I suppose there are multiple options here:


1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next
2. build in epel9, untag the old epel9-next build


What is the general guideline in this situation?

Related, but not necessarily blocking question: Should EPEL 9 Next be purged 
after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 
instead?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Vitaly Zaitsev via devel]

On 26/05/2022 17:40, drago01 wrote:
Why would we do that? Is the build process really more important than 
shipping tested software?


Yes.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2090500] [EPEL9] Please branch and build perl-Cache-FastMmap in EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-73fc3c9dea has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73fc3c9dea


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2090500
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220527.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220526.n.0
NEW: Fedora-Rawhide-20220527.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  1
Dropped packages:1
Upgraded packages:   39
Downgraded packages: 0

Size of added packages:  61.65 KiB
Size of dropped packages:130.78 KiB
Size of upgraded packages:   1.72 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   21.38 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: fprettify-0.3.7-2.fc37
Summary: Auto-formatter for modern Fortran source code
RPMs:fprettify python3-fprettify
Size:61.65 KiB


= DROPPED PACKAGES =
Package: forbidden-apis-2.5-10.fc34
Summary: Policeman's Forbidden API Checker
RPMs:forbidden-apis
Size:130.78 KiB


= UPGRADED PACKAGES =
Package:  awscli-1.24.9-1.fc37
Old package:  awscli-1.24.8-1.fc37
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.17 MiB
Size change:  -245 B
Changelog:
  * Thu May 26 2022 Gwyn Ciesla  - 1.24.9-1
  - 1.24.9


Package:  calc-2.14.1.0-1.fc37
Old package:  calc-2.14.0.14-2.fc36
Summary:  Arbitrary precision arithmetic system and calculator
RPMs: calc calc-devel calc-libs calc-stdrc
Size: 4.63 MiB
Size change:  -44.25 KiB
Changelog:
  * Thu May 26 2022 Matthew Miller  2.14.1.0-1
  - New upstream release 2.14.1.0  -- minor bugfixes


Package:  cantera-2.6.0-23.fc37
Old package:  cantera-2.6.0-21.fc37
Summary:  Chemical kinetics, thermodynamics, and transport tool suite
RPMs: cantera-common cantera-devel cantera-static python3-cantera
Size: 35.65 MiB
Size change:  22.28 MiB
Changelog:
  * Thu May 26 2022 Mark E. Fuller  2.6.0-22
  - patch cantera for test tolerances on alternate architectures

  * Thu May 26 2022 Mark E. Fuller  2.6.0-23
  - fix premature spec changes


Package:  dummy-test-package-gloster-0-8819.fc37
Old package:  dummy-test-package-gloster-0-8803.fc37
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 499.12 KiB
Size change:  509 B
Changelog:
  * Thu May 26 2022 packagerbot  - 0-8804
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8805
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8806
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8807
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8808
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8809
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8810
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8811
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8812
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8813
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8814
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8815
  - rebuilt

  * Thu May 26 2022 packagerbot  - 0-8816
  - rebuilt

  * Fri May 27 2022 packagerbot  - 0-8817
  - rebuilt

  * Fri May 27 2022 packagerbot  - 0-8818
  - rebuilt

  * Fri May 27 2022 packagerbot  - 0-8819
  - rebuilt


Package:  eccodes-2.26.0-1.fc37
Old package:  eccodes-2.25.0-2.fc37
Summary:  WMO data format decoding and encoding
RPMs: eccodes eccodes-data eccodes-devel eccodes-doc
Size: 8.14 MiB
Size change:  63.54 KiB
Changelog:
  * Thu May 26 2022 Jos de Kloe  - 2.26.0-1
  - Upgrade to upstream version 2.26.0


Package:  gh-2.11.3-2.fc37
Old package:  gh-2.11.1-1.fc37
Summary:  GitHub???s official command line tool
RPMs: gh golang-github-cli-2-devel
Size: 25.36 MiB
Size change:  3.45 KiB
Changelog:
  * Thu May 26 2022 Mikel Olasagasti Uranga  2.11.3-1
  - Update to 2.11.3 - Closes rhbz#2090679


Package:  google-api-python-client-2:2.49.0-1.fc37
Old package:  google-api-python-client-2:2.48.0-1.fc37
Summary:  Google APIs Client Library for Python
RPMs: python3-google-api-client
Size: 2.84 MiB
Size change:  5.04 KiB
Changelog:
  * Thu May 26 2022 Mikel Olasagasti Uranga  2:2.49.0-1
  - Update to 2.49.0 - Closes rhbz#2090697


Package:  gopass-1.14.2-1.fc37
Old package:  gopass-1.14.1-1.fc37
Summary:  The slightly more awesome standard unix password manager for teams
RPMs: golang-github-gopasspw-gopass-devel gopass
Size: 27.39 MiB
Size change:  10.71 KiB
Changelog:
  * Thu May 26 2022 Fabio Alessandro Locati  1.14.2-1
  - update to 1.14.2. rhbz#2089105


Package:  guestfs-tools-1.49.2-1.fc37
Old package:  guestfs-tools-1.49.1-1.fc37
Summary:  Tools to access and modify virtual machine disk images
RPMs: guestfs-tools guestfs-tools-bash-completion 
guestfs-tools-man-pages-ja guestfs-tools-man-pages-uk virt-dib virt-win-reg
Size: 18.50 MiB
Size change:  43.77 KiB
Changelog:
  * Thu May 26 2022 Richard W.M. Jones  - 1.49.2-1
  - New upstream development version 1.49.2


Package:  ibus-1.5.26-7.fc37
Old package:  ibus-1.5.26-6.fc37
Summary:  Intelligent Input Bus

Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)

[Milan Crha]

On Thu, 2022-05-26 at 14:37 -0500, Michael Catanzaro wrote:
> Still, hopefully we can manage this transition without applications 
> winding up broken in stable Fedoras.

Hi,
for what it's worth, I have a COPR repo for Fedora 36, which includes
several packages to use/build with/... libsoup3:
https://copr.fedorainfracloud.org/coprs/mcrha/evo-soup3/
It replaces core packages (which might get obsolete by regular f36
updates eventually) as much that it includes also gnome-shell and
others. The libsoup3 version there uses branch:
https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283
which is important for the evolution-data-server and the other
evolution packages (to be tested in action soon).

Other packages have included (or enabled) their changes from a porting
tracker bug on the libsoup side:
https://gitlab.gnome.org/GNOME/libsoup/-/issues/218

I did not cover all the packages from the default Workstation install,
I skipped gnome-boxes (Vala, huh), gnome-photos and gnome-maps. With
these removed one can replace the GNOME to the libsoup3 version.

The grilo-plugins package is just hacked to remove the libsoup parts,
because it doesn't have any proposed porting patch. There might be more
hacks in the packages, I do not recall what I tweaked where precisely.

That being said, if anyone wants to do any early testing of their
project(s), then this can be a good starting point. I can add more
packages, if anyone throws a source rpm at me (not by mail, just a link
to it).
Bye,
Milan
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 37 Rawhide 20220527.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/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20220524.n.0: anaconda-37.8-1.fc37.src, 20220527.n.0: 
anaconda-37.9-1.fc37.src

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

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_37_Rawhide_20220527.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220527.n.0_Security_Lab

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 on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Retiring Python 3.7 before Python 3.6?

[Miro Hrončok]

Hey Pythonistas,

let me include you in my dilemma I have wrt different Python versions we 
support in Fedora for testing.


tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for 
RHEL 8, but 3.7 will no longer be "needed". However, retiring mid-order might 
be confusing.


Note that this topic is not urgent at all, I am just curious about what is the 
best plan for the future.



Python 3.7 retirement date
==

Python 3.7 has security support upstream until June, 2023.

It is also used in Debian 10 “Buster” -- LST ends June, 2024.

Ubuntu seem to have skipped this Python version, so no LTS to consider there.
Same with the SUSE Linux Enterprise Server.

If nothing changes significantly, Fedora 40 will be released in April 2024, 
hence the natural thing to do would be to retire Python 3.7 in Fedora 40.


(I might have made an error, evaluating the dates. Please, do correct me if 
there is a significant platform that supports Python 3.7 beyond Debian 10 LTS 
EOL or if some dates are wrong.)



Python 3.6 retirement date
==

Python 3.6 will be supported until RHEL 8 goes EOL. Which will likely not 
happen until 2029 [1]. That means, we might consider retiring it in Fedora 50 
(wow).



My dilemma
==

If we retire 3.7 before 3.6, the situation will be harder to explain to our 
users. Why is there a gap, they might ask. In the future, the list of supported 
Python versions might look weird and contain multiple gaps as we are eventually 
going to face this situation again with 3.8, 3.10...


If we keep 3.7 around until 3.6 goes down, it will be harder to maintain. If it 
was just 3.7, that would probably be acceptable, but assuming no release 
schedules change, we will likely have Python 3.18 in Fedora 50. That means we 
would need to support 12 different Python 3.X versions by then if we haven't 
started introducing those gaps. Now we support 6.


As I written this down, I think the better thing to do is to accept the gaps 
and retire Python 3.7 before Python 3.6 right away and not decide to "keep it 
around, as we still support both 3.6 and 3.8". WDYT?



[1] https://access.redhat.com/support/policy/updates/errata

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220527.0 compose check report

[Fedora compose checker]

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-20220526.0):

ID: 1280791 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1280791
ID: 1280799 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1280799

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libsoup 2 -> 3 migration plan and timeline (action required if you depend on libsoup)

[Miro Hrončok]

On 26. 05. 22 21:42, Ben Cotton wrote:

Thanks for the long lead time. If you submit this as an F39 Change
proposal now, you'll be the very first for that release (and perhaps
even break churchyard's unofficial "most in-advance Change proposal
submission). You can, of course, wait a while to do this, too.


Let me correct that shortly.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Go-Sig spring cleaning

[Dominik 'Rathann' Mierzejewski]

On Thursday, 26 May 2022 at 23:01, Fabio Alessandro Locati wrote:
[...]
> I would ask of all of you to make sure all your packages have been
> added to the @go-sig group on src.fedoraproject.org (at least with
> "commit" access), unless there is a very good reason not to do so (and
> if that is the case for a particular package on this list, I'd be
> interested in knowing the reason).
[...]
> Below is the list of "incompletely set-up" packages, in alphabetic order, and
> at the bottom, is a list per package maintainer.
> 
> Thanks,
> Fale
> 
> 
> 
> Maintainers per package:
> 
[...]
>  - golang-github-jfrog-gofrog: rathann

Done. I missed that bit when the package was renamed.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: remove-retired-packages feedback

[Barry Scott]

> On 26 May 2022, at 14:52, Miroslav Suchý  wrote:
> 
> If you already upgraded to Fedora 36 - what is your feedback about
> 
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
>  
> 
> Did you run the command `remove-retired-packages`? Do you find it useful? 
> Comments and ideas are welcome either here or at:
> 
> https://github.com/xsuchy/fedora-upgrade/issues 
> 
> Just be sure that you have latest version, i.e., remove-retired-packages-36.3.
> 
Useful command!

It found a number of packages to remove.

One was a package that I built to locally and installed from the command line, 
which it
correctly identified as not in F36.

I like that it prompts for each package on its own. This meant that I could 
remove the
3 that I do not need to keep but leave the one that I do need.

Barry



> Miroslav
> 
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-CPAN-FindDependencies] PR #2: Debug gating

[Petr Pisar]

ppisar opened a new pull-request against the project: 
`perl-CPAN-FindDependencies` that you are following:
``
Debug gating
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-CPAN-FindDependencies/pull-request/2
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Jiri Vanek]

On 5/26/22 14:17, Stephen Snow wrote:

Also, it may be good to take a look at what AdoptOpenJDK is doing with
the Eclipse Foundation based Adoptium Project, specifically the Eclipse
Temurin subproject
https://projects.eclipse.org/proposals/eclipse-temurin-compliance which
is going to handle the compliance requirements.

In this scenerio the Eclipse Foundation is the license holder and the
Adoptium project submits to the Temurin project to get certified.

Maybe Fedora could use something similar with RH, who are signatories
on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project.

Just another thought on it.


That is just correct summary. That is exactly what wea re doing.
We certify with RH signatories.

J.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2090501] [EPEL9] Please branch and build perl-Number-Format in EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-93d3fc036a has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-93d3fc036a


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2090501
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure