[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

[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

[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

[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

[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