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

[updates]

The following builds have been pushed to Fedora EPEL 8 updates-testing

indent-2.2.12-4.el8
pugixml-1.9-1.el8
python-ratelimitingfilter-1.1-3.el8
robin-map-0.6.1-2.el8
will-crash-0.12-3.el8

Details about builds:



 indent-2.2.12-4.el8 (FEDORA-EPEL-2019-891ee8a7be)
 A GNU program for formatting C code

Update Information:

This brings indent tool, a formatter for C code.




 pugixml-1.9-1.el8 (FEDORA-EPEL-2019-70dbc966dd)
 A light-weight C++ XML processing library

Update Information:

Initial builds for epel 8.




 python-ratelimitingfilter-1.1-3.el8 (FEDORA-EPEL-2019-d230ef1f86)
 A rate limiting filter for the Python logging system

Update Information:

- Build for epel8 - Dropped python2 from epel8 - Upstream version 1.1




 robin-map-0.6.1-2.el8 (FEDORA-EPEL-2019-70dbc966dd)
 C++ implementation of a fast hash map and hash set using robin hood hashing

Update Information:

Initial builds for epel 8.




 will-crash-0.12-3.el8 (FEDORA-EPEL-2019-c90d8a0b9c)
 Set of crashing executables written in various languages

Update Information:

- Build for epel8 - Update to 0.12


___
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

[EPEL-devel] Re: how to use epel8-playground?

[Stephen John Smoogen]

On Mon, 12 Aug 2019 at 17:47, Troy Dawson  wrote:

> Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
> playground stuff, so you should be good.
> When I did the branches for KDE (about 350 of them) there were 6 that
> didn't properly branch to epel8-playground.
> They *said* they were branched, but they weren't.
> I was able to push and create a branch though, because everything else
> was setup.
>
>   fedpkg switch-branch f30
>   git checkout -b epel8-playground
>   fedpkg push
>
> I did f30 instead of master because that's the version we wanted for
> KDE.  You can do that from master if you want.
>
>
Please be aware that when you do this you create an email for every commit
ever done as they are each resent to the various scm-commit lists. This
caused several hundred thousand emails when the KDE was done this way.


> Troy
>
> On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
> >
> > Hi Kevin,
> >
> > I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> > updated it from 1.37-2 on August 6 an hour and a half before I started
> > this thread.  If I recall correctly I saw an instruction somewhere that
> > said to update it, and I did that before my initial attempt.
> >
> > Dave
> >
> > On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > > Stephen,
> > > >
> > > > The package is singularity.
> > > >
> > > > The term "branch" in this context is not very clear to me.  All I
> know
> > > > is that there's no git branch on
> pkgs.fedoraproject.org/rpms/singularity;
> > > > I don't know about other systems.
> > >
> > > What version of fedpkg do you have there?
> > >
> > > It might be the version is too old to understand the epel8-playground
> > > request?
> > >
> > > kevin
> > >
> > >
> >
> >
> >
> >
> > > ___
> > > 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
> > ___
> > 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
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: how to use epel8-playground?

[Troy Dawson]

Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
playground stuff, so you should be good.
When I did the branches for KDE (about 350 of them) there were 6 that
didn't properly branch to epel8-playground.
They *said* they were branched, but they weren't.
I was able to push and create a branch though, because everything else
was setup.

  fedpkg switch-branch f30
  git checkout -b epel8-playground
  fedpkg push

I did f30 instead of master because that's the version we wanted for
KDE.  You can do that from master if you want.

Troy

On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
>
> Hi Kevin,
>
> I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> updated it from 1.37-2 on August 6 an hour and a half before I started
> this thread.  If I recall correctly I saw an instruction somewhere that
> said to update it, and I did that before my initial attempt.
>
> Dave
>
> On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > Stephen,
> > >
> > > The package is singularity.
> > >
> > > The term "branch" in this context is not very clear to me.  All I know
> > > is that there's no git branch on pkgs.fedoraproject.org/rpms/singularity;
> > > I don't know about other systems.
> >
> > What version of fedpkg do you have there?
> >
> > It might be the version is too old to understand the epel8-playground
> > request?
> >
> > kevin
> >
> >
>
>
>
>
> > ___
> > 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
> ___
> 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
___
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

[EPEL-devel] Re: how to use epel8-playground?

[Dave Dykstra]

Hi Kevin,

I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
updated it from 1.37-2 on August 6 an hour and a half before I started
this thread.  If I recall correctly I saw an instruction somewhere that
said to update it, and I did that before my initial attempt.

Dave

On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > Stephen,
> > 
> > The package is singularity.
> > 
> > The term "branch" in this context is not very clear to me.  All I know
> > is that there's no git branch on pkgs.fedoraproject.org/rpms/singularity;
> > I don't know about other systems.
> 
> What version of fedpkg do you have there?
> 
> It might be the version is too old to understand the epel8-playground
> request?
> 
> kevin
> 
> 




> ___
> 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
___
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

[EPEL-devel] RHEL-7.7 problems

[Stephen John Smoogen]

This release has had a multitude of problems this release.

* The python3 problems were caused because there were complaints that the
python36 was conflicting with the RHEL-7 python3 causing build problems.
The maintainers removed python36 to try and fix this and broke centos
consumers who relied on EPEL.

* The real problem turned out to be definitions which RHEL over-rode EPEL
build srpm definitions. This needed further package updates which are in
the buildroot, but while debugging this we found at least two more
buildroot problems.

* One of the items is that RHEL did not update the rhel-alt platform which
contained aarch64 or power9 with the EL7.7 release. This means that these
are frozen at 7.6 it would seem. I am not sure what to do about this at the
moment.

* The other problem is that reposync broke once again with the Red Hat cdn.
Running the script by hand would show that it thought it had downloaded
everything but it was clear only parts of the 7.7 had been downloaded for
various architectures. Only by starting over seems to have gotten things to
unstick.

I expect we will have several more issues/problems to deal with.

-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Stephen John Smoogen]

On Mon, 12 Aug 2019 at 07:21, Miro Hrončok  wrote:

> On 09. 08. 19 11:13, Antonio Trande wrote:
> > Hi all.
> >
> > 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
> > EPEL7 ppc64le only?
> >
> >
> https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000
>
> Funny thing:
>
> ppc64le gets:
>
> Problem: conflicting requests
>   - nothing provides python-rpm-macros > 3-30 needed by
> python-devel-2.7.5-86.el7.ppc64le
>   - nothing provides python2-rpm-macros > 3-30 needed by
> python-devel-2.7.5-86.el7.ppc64le
>
> x86_64 gets python-devel-2.7.5-80.el7.x86_64
>
> It seems that the ppc64le build has the arched package from RHEL 7.7 but
> misses
> the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages
> from
> RHEL 7.6 altogether.
>
>
OK our certificate to using Red Hat Network was made invalid during a sync.
I am 'fixing'.

>
>

-- 
Stephen J Smoogen.
___
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

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Miro Hrončok]

On 12. 08. 19 13:20, Miro Hrončok wrote:

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000 



Funny thing:

ppc64le gets:

Problem: conflicting requests
  - nothing provides python-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le
  - nothing provides python2-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le


x86_64 gets python-devel-2.7.5-80.el7.x86_64

It seems that the ppc64le build has the arched package from RHEL 7.7 but misses 
the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from 
RHEL 7.6 altogether.


https://pagure.io/fedora-infrastructure/issue/8084

--
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

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Miro Hrončok]

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000


Funny thing:

ppc64le gets:

Problem: conflicting requests
 - nothing provides python-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le
 - nothing provides python2-rpm-macros > 3-30 needed by 
python-devel-2.7.5-86.el7.ppc64le


x86_64 gets python-devel-2.7.5-80.el7.x86_64

It seems that the ppc64le build has the arched package from RHEL 7.7 but misses 
the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from 
RHEL 7.6 altogether.


--
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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Tuomo Soini]

On Mon, 12 Aug 2019 10:52:34 +0200
Miro Hrončok  wrote:

> > python3_other is now defined to 3 in rhel7.7.  
> 
> By what? Do you mean python3_pkgversion? W can override that as well.

Sorry. python3_pkgversion.


-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Mon, Aug 12, 2019 at 11:21 AM Miro Hrončok  wrote:
>
> On 12. 08. 19 11:16, Mikolaj Izdebski wrote:
> > On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:
> >>
> >> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> >>> On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
> 
>  See for example:
> 
>  https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
>  2019-08-11 07:50:11
> 
>  - nothing provides python(abi) = 3.6 ...
> 
>  This is provided in RHEL 7.7.
> 
>  (Note that we've unretired the python36 package, so later it resolved 
>  correctly.)
> >>>
> >>> Koschei uses Koji repos. You can find out the exact repo URL at given
> >>> timestamp in the following way:
> >>>
> >>> In [1]: import koji, datetime
> >>> In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> >>> In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> >>> In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> >>> In [5]: event = ks.getLastEvent(before=ts)
> >>> In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> >>> event=event['id'])
> >>> In [7]: pi.repo(repo['id'], 'epel7-build')
> >>> Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
> >>
> >> And for RHEL packages?
> >
> > Selected RHEL packages are available in EPEL buildroots.
>
> Oh. Do you know any pointers about how do I add more?

EPEL 7 build uses repos from 5 RHEL 7 channels.
You can see them with the following command:

$ koji list-external-repos --tag epel7-base
Pri External repo nameMode   URL
--- - --

10  rhel7-server  koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-rpms/
11  rhel7-rhel-extras koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-extras-rpms/
12  rhel7-server-ha   koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-ha-for-rhel-7-server-rpms/
15  rhel7-server-optional koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-7-server-optional-rpms/
20  rhel7-server-rhscl-7  koji
http://kojipkgs.fedoraproject.org/repo/rhel/rhel7/$arch/rhel-server-rhscl-7-rpms/

Koji admins (i.e. Release Engineering) can add more channels upon
request from EPEL developers.
Before adding to Koji, RHEL repos would need to be synced from RHN to
Fedora servers (this can be requested from Fedora Infrastructure).


>
> >>> x86_64 repos are used for dependency resolution. At that time python36
> >>> was not available in epel7-build:
> >>
> >> Are RHEL packages available directly from epel7-build?
> >
> > Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
> > RHEL build.
>
> I see. Thanks.
>
> --
> 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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Miro Hrončok]

On 12. 08. 19 11:16, Mikolaj Izdebski wrote:

On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:


On 12. 08. 19 11:12, Mikolaj Izdebski wrote:

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:


See for example:

https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11

- nothing provides python(abi) = 3.6 ...

This is provided in RHEL 7.7.

(Note that we've unretired the python36 package, so later it resolved 
correctly.)


Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'


And for RHEL packages?


Selected RHEL packages are available in EPEL buildroots.


Oh. Do you know any pointers about how do I add more?


x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:


Are RHEL packages available directly from epel7-build?


Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.


I see. Thanks.

--
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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok  wrote:
>
> On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
> > On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
> >>
> >> See for example:
> >>
> >> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> >> 2019-08-11 07:50:11
> >>
> >> - nothing provides python(abi) = 3.6 ...
> >>
> >> This is provided in RHEL 7.7.
> >>
> >> (Note that we've unretired the python36 package, so later it resolved 
> >> correctly.)
> >
> > Koschei uses Koji repos. You can find out the exact repo URL at given
> > timestamp in the following way:
> >
> > In [1]: import koji, datetime
> > In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
> > In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
> > In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
> > In [5]: event = ks.getLastEvent(before=ts)
> > In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
> > event=event['id'])
> > In [7]: pi.repo(repo['id'], 'epel7-build')
> > Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
>
> And for RHEL packages?

Selected RHEL packages are available in EPEL buildroots.

>
> > x86_64 repos are used for dependency resolution. At that time python36
> > was not available in epel7-build:
>
> Are RHEL packages available directly from epel7-build?

Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.

>
> --
> 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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 12. 08. 19 10:52, Miro Hrončok wrote:

On 12. 08. 19 8:14, Tuomo Soini wrote:

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:


%python3_other_pkgversion 34

I believe the easiest fix is to define that directly in
epel-rpm-macros:

https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5


Correct. That fixes this issue but not the huge issue we have now.


Thanks for the report!


I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.


By what? Do you mean python3_pkgversion? W can override that as well.


Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.


Let's do that as a quick hotfix for now decide the rest later.


Updated https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5

Please some EPEL people, review and possibly build soon.

--
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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Miro Hrončok]

On 12. 08. 19 11:12, Mikolaj Izdebski wrote:

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:


See for example:

https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11

- nothing provides python(abi) = 3.6 ...

This is provided in RHEL 7.7.

(Note that we've unretired the python36 package, so later it resolved 
correctly.)


Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'


And for RHEL packages?


x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:


Are RHEL packages available directly from epel7-build?

--
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

[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?

[Mikolaj Izdebski]

On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok  wrote:
>
> See for example:
>
> https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
> 2019-08-11 07:50:11
>
> - nothing provides python(abi) = 3.6 ...
>
> This is provided in RHEL 7.7.
>
> (Note that we've unretired the python36 package, so later it resolved 
> correctly.)

Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:

In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'

x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:

$ dnf -q --repofrompath
epel7-build-1234463,https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463/x86_64/
--repo epel7-build-1234463 repoquery --whatprovides 'python(abi)'
python-0:2.7.5-80.el7_6.x86_64
python34-0:3.4.10-2.el7.x86_64


> --
> 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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 12. 08. 19 8:14, Tuomo Soini wrote:

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:


%python3_other_pkgversion 34

I believe the easiest fix is to define that directly in
epel-rpm-macros:

https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5


Correct. That fixes this issue but not the huge issue we have now.


Thanks for the report!


I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.


By what? Do you mean python3_pkgversion? W can override that as well.


Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.


Let's do that as a quick hotfix for now decide the rest later.


--
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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Tuomo Soini]

On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok  wrote:

> %python3_other_pkgversion 34
> 
> I believe the easiest fix is to define that directly in
> epel-rpm-macros:
> 
> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5

Correct. That fixes this issue but not the huge issue we have now.

> Thanks for the report!

I agree. But we have much bigger problem with epel python naming.

python3_other is now defined to 3 in rhel7.7.

Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.

Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.

We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.

Let's list some history, please notify if I forgot something important.

python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.

When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion

rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.

Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.

There are two possibilities how to handle this:

Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.

This would cause pain in every occasion when there is new python3
package added to rhel7 because rhel7 uses different naming. That
would mean we would need to manually patch dependencies on packages in
rhel7 because we don't have any guarantee that rhel packagers remember
epel when doing rhel packages. So we need to manually change
dependencies to rhel packages to be python3, not
python%{python3_pkgversion}.

My suggestion for this is to do big python3 rebuild again in epel7,
this time with python3_pkgversion from rhel7.7 and move clearly to
rhel7.7 python3 naming and obsolete pythn34 now, people have already
been notified that python34 is end of the life and not supported by
upstream.

Add epel specific python_provide macro which for python3-modname does:
normal provides as it did before.

Provides: python3- = %{version}-%{release}
Obsoletes: python36- < %{version}-%{release}
Obsoletes: python34- < %{version}-%{release}

Remove python3_other from epel7.

Only downside from this is that python3-modname source rpm naming won't
work any more because rpm doesn't allow python3-modname naming in
sub-package. My suggestion for that is to name these epel only
source packages with python3-epel-modname or python3-modname-epel
naming so that they can generate python3-modname.


-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
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