Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

While I really tried to do my best, it seems that I broke CentOS by retiring 
python36. Should it be unretired? Or is it reasonable to say: Please wait for 
CentOS 7.7?

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

Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is 
there any action to take?

https://lists.fedoraproject.org/archives/list/[e-mail]...

[Richard Grainger]

> On 10 Aug 2019, at 20:23, Miro Hrončok  wrote:
>
> While I really tried to do my best, it seems that I broke CentOS by retiring python36. Should it be unretired? Or is it reasonable to say: Please wait for CentOS 7.7?

This is why I believe we need a “CentOS-EPEL” repo that mirrors EPEL generally, but that is frozen in the period between a RHEL and CentOS release.

[Andrew C Aitchison]

On Sat, 10 Aug 2019, Richard Grainger wrote:
> > On 10 Aug 2019, at 20:23, Miro Hrončok  wrote:
> >
> > While I really tried to do my best, it seems that I broke CentOS by
> > retiring python36. Should it be unretired? Or is it reasonable to
> > say: Please wait for CentOS 7.7?
>
> This is why I believe we need a “CentOS-EPEL” repo that mirrors EPEL
> generally, but that is frozen in the period between a RHEL and
> CentOS release.

The same could be said for a Scientific-Linux-EPEL.
Would it be clearer to have an EPEL7.6 and an EPEL7.7 ?

[Stephen John Smoogen]

On Sat, 10 Aug 2019 at 16:18, Andrew C Aitchison 
wrote:
> On Sat, 10 Aug 2019, Richard Grainger wrote:
> > > On 10 Aug 2019, at 20:23, Miro HronÄ ok  wrote:
> > >
> > > While I really tried to do my best, it seems that I broke CentOS by
> > > retiring python36. Should it be unretired? Or is it reasonable to
> > > say: Please wait for CentOS 7.7?
> >
> > This is why I believe we need a “CentOS-EPEL† repo that mirrors EPEL
> > generally, but that is frozen in the period between a RHEL and
> > CentOS release.
>
> The same could be said for a Scientific-Linux-EPEL.
> Would it be clearer to have an EPEL7.6 and an EPEL7.7 ?

This was the purpose of the various branching proposals. The main issue
there are not enough time/manpower resources to make any of the proposals
work as it needs build system changes, a full time release manager and
packagers who want to deal with it. In the end though this is a volunteer
project done on the side by various people in the Fedora community. If we
were to move this elsewhere, it would still be a volunteer activity.

I wish I had a better answer but after seeing us break the world every
RHEL-X.Y release.. I don't.

[Bryan J Smith]

Stephen John Smoogen  wrote:
> This was the purpose of the various branching proposals. The main issue
> there are

not enough time/manpower resources to make any of the proposals work as it
> needs

build system changes, a full time release manager and packagers who want to
> deal with it.

In the end though this is a volunteer project done on the side by various
> people in the

Fedora community. If we were to move this elsewhere, it would still be a
> volunteer activity.

I wish I had a better answer but after seeing us break the world every
> RHEL-X.Y release.. I don't.

Indeed, it's a thankless job.
Sincerely, keep up the good work, and that goes for all maintainers too.

I've always advised those running 'downstream' versions wait to update
until they are on the same, new 'Update' after any new RHEL release.  It's
a good rule to follow -- e.g., RHEL 7.7 just came out.

- "Still lurking" bjs

<anecdotal>
P.S.  For those that don't know, starting a good 7 years ago I brought up
the increasing 'breakage' with RHEL as Fedora EPEL build various packages
for CentOS because CentOS rebuilding various RHEL add-ons.  Simply put, at
a half-dozen major Red Hat accounts, I had to warn EPEL would now conflict
in various ways outside of the very RHEL core, so RHEL systems couldn't be
subscribed to it, and each EPEL package needed to be vetted into an
internal channel/repo (e.g., Satellite) before even considering deployment.

I also worked with both Red Hat GLS as well as Partners over the next 18
months to tell them to yank all sections regarding EPEL from Training,
Enablement and other documentation, as only core RHEL compatibility was the
goal, not all of RHEL.

So at that time I suggested the idea of forking into Emerging Technologies
for Enterprise Linux (ETEL) from EPEL.  That way, people who wanted newer
Fedora stuff or, in the case of CentOS not rebuilding various Enterprise
add-ons available for RHEL, or even newer versions of packages in RHEL
add-ons, would have a separate repo from EPEL that was never supposed to
conflict.

As Stephen, Kevin and others others pointed out for that to happen,
increases of resources and volunteer hours would have to happen.  And
that's just the reality.  Not everyone is going to be made happy, given the
constraints.  So we should all appreciate what we have.  I'm just glad EPEL
still focuses on at least core RHEL.
</anecdotal>

[Miro Hrončok]

On 10. 08. 19 21:23, Miro Hrončok wrote:
> While I really tried to do my best, it seems that I broke CentOS by retiring 
> python36. Should it be unretired? Or is it reasonable to say: Please wait for 
> CentOS 7.7?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1739804

If any EPEL expert thinks the package should be unretired for now, please do so.
> Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is 
> there any action to take?
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Stephen John Smoogen]

On Sat, 10 Aug 2019 at 17:12, Miro Hrončok  wrote:
> On 10. 08. 19 21:23, Miro Hrončok wrote:
> > While I really tried to do my best, it seems that I broke CentOS by
>
> retiring
> > python36. Should it be unretired? Or is it reasonable to say: Please
>
> wait for
> > CentOS 7.7?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
>
> If any EPEL expert thinks the package should be unretired for now, please
> do so.

Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is out
in the CR repo. My apologies for not thinking of this when you were
mentioning things yesterday. I do not have the rights to unretire things so
will need to get in touch with Mohan/Kevin/Mizdebsk on what to do.
> > Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL
>
> one. Is
> > there any action to take?
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> >
>
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Miro Hrončok]

On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> On Sat, 10 Aug 2019 at 17:12, Miro Hrončok <[e-mail] 
> > wrote:
> On 10. 08. 19 21:23, Miro Hrončok wrote:
>  > While I really tried to do my best, it seems that I broke CentOS by retiring
>  > python36. Should it be unretired? Or is it reasonable to say: Please wait
> for
>  > CentOS 7.7?
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
>
> If any EPEL expert thinks the package should be unretired for now, please do so.
>
>
> Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is out in 
> the CR repo. My apologies for not thinking of this when you were mentioning 
> things yesterday. I do not have the rights to unretire things so will need to 
> get in touch with Mohan/Kevin/Mizdebsk on what to do.

https://pagure.io/releng/issue/8607

[Mohan Boddu]

I unretired the packages and tagged the old builds, I think that should fix
the buildroot and got a testing build working.

On Sun, Aug 11, 2019 at 3:29 AM Miro Hrončok  wrote:
> On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> > On Sat, 10 Aug 2019 at 17:12, Miro Hrončok <[e-mail]
> > > wrote:
> > On 10. 08. 19 21:23, Miro Hrončok wrote:
> >  > While I really tried to do my best, it seems that I broke CentOS
>
> by retiring
> >  > python36. Should it be unretired? Or is it reasonable to say:
>
> Please wait
> > for
> >  > CentOS 7.7?
> >  >
> >  > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
> >
> > If any EPEL expert thinks the package should be unretired for now,
>
> please do so.
> > Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
>
> out in
> > the CR repo. My apologies for not thinking of this when you were
>
> mentioning
> > things yesterday. I do not have the rights to unretire things so will
>
> need to
> > get in touch with Mohan/Kevin/Mizdebsk on what to do.
>
> https://pagure.io/releng/issue/8607
>
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Miro Hrončok]

On 11. 08. 19 9:59, Mohan Boddu wrote:
> I unretired the packages and tagged the old builds, I think that should fix the 
> buildroot and got a testing build working.

Thanks, now.

Assuming Koji sees RHEL 7.7, can we somehow:

- keep the packages in the repos
  - but make Koji prefer the RHEL ones (they have higher EVR)?

[Kevin Fenzi]

On 8/11/19 1:45 AM, Miro Hrončok wrote:
> On 11. 08. 19 9:59, Mohan Boddu wrote:
> > I unretired the packages and tagged the old builds, I think that
> > should fix the buildroot and got a testing build working.
>
> Thanks, now.
>
> Assuming Koji sees RHEL 7.7, can we somehow:
>
> - keep the packages in the repos
>  - but make Koji prefer the RHEL ones (they have higher EVR)?

Are they using the same source package name?

If so, the epel one will always be used.
If not, they should both be available.

kevin

[Miro Hrončok]

On 13. 08. 19 20:08, Kevin Fenzi wrote:
> On 8/11/19 1:45 AM, Miro Hrončok wrote:
> > On 11. 08. 19 9:59, Mohan Boddu wrote:
> > > I unretired the packages and tagged the old builds, I think that
> > > should fix the buildroot and got a testing build working.
> >
> > Thanks, now.
> >
> > Assuming Koji sees RHEL 7.7, can we somehow:
> >
> > - keep the packages in the repos
> >   - but make Koji prefer the RHEL ones (they have higher EVR)?
>
> Are they using the same source package name?
>
> If so, the epel one will always be used.
> If not, they should both be available.

Some, most importantly python-rpm-macros, use the same source package name and 
were retired in EPEL, however that broke centos. So they got unretired, but that 
broke Koji.

We could possibly package "python-rpm-macros-temporary" but this has already 
drained a lot of my energy, so somebody else needs to do that, sorry.

[Kevin Fenzi]

On 8/13/19 11:15 AM, Miro Hrončok wrote:
> On 13. 08. 19 20:08, Kevin Fenzi wrote:
> > On 8/11/19 1:45 AM, Miro Hrončok wrote:
> > > On 11. 08. 19 9:59, Mohan Boddu wrote:
> > > > I unretired the packages and tagged the old builds, I think that
> > > > should fix the buildroot and got a testing build working.
> > >
> > > Thanks, now.
> > >
> > > Assuming Koji sees RHEL 7.7, can we somehow:
> > >
> > > - keep the packages in the repos
> > >   - but make Koji prefer the RHEL ones (they have higher EVR)?
> >
> > Are they using the same source package name?
> >
> > If so, the epel one will always be used.
> > If not, they should both be available.
>
> Some, most importantly python-rpm-macros, use the same source package
> name and were retired in EPEL, however that broke centos. So they got
> unretired, but that broke Koji.
>
> We could possibly package "python-rpm-macros-temporary" but this has
> already drained a lot of my energy, so somebody else needs to do that,
> sorry.

I think all we need to do is update python-rpm-macros in epel so that
they meet the needs of the rhel 7.7 python2:

DEBUG util.py:585:  BUILDSTDERR:   - nothing provides python-rpm-macros
> 3-30 needed by python-devel-2.7.5-86.el7.x86_64

DEBUG util.py:585:  BUILDSTDERR:   - nothing provides python2-rpm-macros
> 3-30 needed by python-devel-2.7.5-86.el7.x86_64

What do folks think of:

https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/28

kevin

[Stephen John Smoogen]

On Sun, 11 Aug 2019 at 03:32, Miro Hrončok  wrote:
> On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> > On Sat, 10 Aug 2019 at 17:12, Miro Hrončok <[e-mail]
> > > wrote:
> > On 10. 08. 19 21:23, Miro Hrončok wrote:
> >  > While I really tried to do my best, it seems that I broke CentOS
>
> by retiring
> >  > python36. Should it be unretired? Or is it reasonable to say:
>
> Please wait
> > for
> >  > CentOS 7.7?
> >  >
> >  > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
> >
> > If any EPEL expert thinks the package should be unretired for now,
>
> please do so.
> > Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
>
> out in
> > the CR repo. My apologies for not thinking of this when you were
>
> mentioning
> > things yesterday. I do not have the rights to unretire things so will
>
> need to
> > get in touch with Mohan/Kevin/Mizdebsk on what to do.
>
> https://pagure.io/releng/issue/8607

Thank you. I just want to say that you are not in any way responsible for
the problems. I did not clearly think out what would happen when I gave you
the go-ahead last week. I should have seen this and said we need to wait.
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...

[Kevin Fenzi]

On 8/11/19 12:28 AM, Miro Hrončok wrote:
> On 11. 08. 19 2:58, Stephen John Smoogen wrote:
> > On Sat, 10 Aug 2019 at 17:12, Miro Hrončok <[e-mail]
> > > wrote:
> >
> > On 10. 08. 19 21:23, Miro Hrončok wrote:
> >      > While I really tried to do my best, it seems that I broke
> > CentOS by retiring
> >      > python36. Should it be unretired? Or is it reasonable to say:
> > Please wait
> >     for
> >      > CentOS 7.7?
> >      >
> >      > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
> >
> > If any EPEL expert thinks the package should be unretired for now,
> > please do so.
> >
> > Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
> > out in the CR repo. My apologies for not thinking of this when you
> > were mentioning things yesterday. I do not have the rights to unretire
> > things so will need to get in touch with Mohan/Kevin/Mizdebsk on what
> > to do.
>
> https://pagure.io/releng/issue/8607

Now that CentOS 7.7 is out shall we retire things again?

kevin

[Miro Hrončok]

On 18. 09. 19 0:55, Kevin Fenzi wrote:
> Now that CentOS 7.7 is out shall we retire things again?

I guess we do. But I dare to touch it. It works now.

[Robert-André Mauchin]

On Saturday, 10 August 2019 21:23:55 CEST Miro Hrončok wrote:
> While I really tried to do my best, it seems that I broke CentOS by retiring
>  python36. Should it be unretired? Or is it reasonable to say: Please wait
> for CentOS 7.7?

How long would that wait be?

[Bryan J Smith]

Robert-André Mauchin  wrote:
> How long would that wait be?

RHEL7.7 is only 4 days old.  Everyone running CentOS should be planning
their patching cycles around the lull between a brand new RHEL Update and
the CentOS build/catch-up.

- bjs

[Miro Hrončok]

On 10. 08. 19 21:23, Miro Hrončok wrote:
> While I really tried to do my best, it seems that I broke CentOS by retiring 
> python36. Should it be unretired? Or is it reasonable to say: Please wait for 
> CentOS 7.7?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1739804

Currently I cannot even init an epel7 mock:

Error:
  Problem: conflicting requests
   - nothing provides python-rpm-macros needed by epel-rpm-macros-7-20.noarch
   - nothing provides python-srpm-macros needed by epel-rpm-macros-7-20.noarch
   - nothing provides python2-rpm-macros needed by epel-rpm-macros-7-20.noarch