[EPEL-devel] EPEL 8 not finding buildroot overrides
I have hdf5 (amongst others) in a buildroot override but when I tried to build OpenImageIO I got the following errors in root.log: DEBUG util.py:585: BUILDSTDERR: No matching package to install: 'hdf5-devel' I'm I missing something? Ok, as I write this and investigate more it get's weirder... https://koji.fedoraproject.org/koji/buildinfo?buildID=1348296 Shows the good build... $ koji wait-repo epel8-build --build=hdf5-1.10.5-3.el8 Warning: package hdf5 is not in tag epel8-build It's technically in epel8-testing, but should that matter? I was "collecting" builds into an update so I didn't forget all the ones that needed to be pushed together. I guess I shouldn't have done that? Thanks, Richard ___ 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] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 364 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 140 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 106 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 103 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 40 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897 dosbox-0.74.3-2.el7 32 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-487a6fb279 knot-2.8.2-1.el7 knot-resolver-4.1.0-1.el7 32 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aabd063c30 squirrelmail-1.4.23-1.el7.20190710 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-44d26d23ea upx-3.95-4.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-b6948289f0 pdns-4.1.11-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ad7b11b384 igraph-0.7.1-12.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-643d621522 jhead-3.03-4.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4e6da66b9f python-django-1.11.23-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-204f810692 clamav-0.101.3-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5f75a76f4e kf5-kconfig-5.52.0-1.el7.1 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa84623a4e libmspack-0.5-0.0.7.alpha.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-26e64681f6 hostapd-2.9-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing boost-nowide-0-20190813.gitec9672b.el7 geolite2-20190806-1.el7 lldpd-1.0.4-1.el7 sslh-1.20-1.el7 xorgxrdp-0.2.10-4.el7 Details about builds: boost-nowide-0-20190813.gitec9672b.el7 (FEDORA-EPEL-2019-425c8980bd) Boost.Nowide makes cross platform Unicode aware programming easier. Update Information: Build boost-nowide against boost 1.67 geolite2-20190806-1.el7 (FEDORA-EPEL-2019-afdc98a00b) Free IP geolocation databases Update Information: - Latest upstream - Add ASN subpackage ChangeLog: * Tue Aug 13 2019 Carl George - 20190806-1 - Latest upstream - Add ASN subpackage * Thu Jul 25 2019 Fedora Release Engineering - 20190618-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild lldpd-1.0.4-1.el7 (FEDORA-EPEL-2019-688071d56a) ISC-licensed implementation of LLDP Update Information: Update to 1.0.4 release ChangeLog: * Tue Aug 13 2019 James Hogarth - 1.0.4-1 - Updated to new upstream release 1.0.4 * Thu Jul 25 2019 Fedora Release Engineering - 1.0.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Sun Feb 17 2019 Igor Gnatenko - 1.0.1-5 - Rebuild for readline 8.0 * Fri Feb 1 2019 Fedora Release Engineering - 1.0.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Tue Jul 24 2018 Adam Williamson - 1.0.1-3 - Rebuild for new net-snmp * Fri Jul 13 2018 Fedora Release Engineering - 1.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild References: [ 1 ] Bug #1720837 - lldpd-1.0.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=1720837 sslh-1.20-1.el7 (FEDORA-EPEL-2019-19f9a0db9b) Applicative protocol(SSL/SSH) multiplexer Update Information: Update to new upstream release 1.20 ChangeLog: * Mon Aug 12 2019 James Hogarth - 1.20-1 - Update to 1.20 upstream * Sat Jul 27 2019 Fedora Release Engineering - 1.19c-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Sun Feb 3 2019 Fedora Release Engineering - 1.19c-5 - Rebuilt for
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following builds have been pushed to Fedora EPEL 6 updates-testing R-Rcpp-1.0.2-1.el6 geolite2-20190806-1.el6 lldpd-1.0.4-1.el6 Details about builds: R-Rcpp-1.0.2-1.el6 (FEDORA-EPEL-2019-1622b8a724) Seamless R and C++ Integration Update Information: Rcpp version 1.0.2 ChangeLog: * Tue Aug 13 2019 Mattias Ellert - 1.0.2-1 - Update to 1.0.2 * Mon Aug 12 2019 Elliott Sales de Andrade - 1.0.1-5 - rebuilt * Mon Aug 12 2019 Elliott Sales de Andrade - 1.0.1-4 - Remove explicit dependencies provided by automatic dependency generator * Mon Aug 12 2019 Elliott Sales de Andrade - 1.0.1-3 - Rebuild with automatic Provides * Wed Jul 24 2019 Fedora Release Engineering - 1.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild References: [ 1 ] Bug #1740462 - Please update it to 1.0.2 https://bugzilla.redhat.com/show_bug.cgi?id=1740462 geolite2-20190806-1.el6 (FEDORA-EPEL-2019-7508ffbf6f) Free IP geolocation databases Update Information: - Latest upstream - Add ASN subpackage ChangeLog: * Tue Aug 13 2019 Carl George - 20190806-1 - Latest upstream - Add ASN subpackage * Thu Jul 25 2019 Fedora Release Engineering - 20190618-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild lldpd-1.0.4-1.el6 (FEDORA-EPEL-2019-720269d0ec) ISC-licensed implementation of LLDP Update Information: Update to 1.0.4 release ChangeLog: * Tue Aug 13 2019 James Hogarth - 1.0.4-1 - Updated to new upstream release 1.0.4 * Thu Jul 25 2019 Fedora Release Engineering - 1.0.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Sun Feb 17 2019 Igor Gnatenko - 1.0.1-5 - Rebuild for readline 8.0 * Fri Feb 1 2019 Fedora Release Engineering - 1.0.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Tue Jul 24 2018 Adam Williamson - 1.0.1-3 - Rebuild for new net-snmp * Fri Jul 13 2018 Fedora Release Engineering - 1.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild References: [ 1 ] Bug #1720837 - lldpd-1.0.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=1720837 ___ 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] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing Field3D-1.7.2-16.el8 fldigi-4.1.07-1.el8 hamlib-3.3-6.el8 hdf5-1.10.5-3.el8 portaudio-19-30.el8 pugixml-1.9-1.el8 robin-map-0.6.1-2.el8 Details about builds: Field3D-1.7.2-16.el8 (FEDORA-EPEL-2019-70dbc966dd) Library for storing voxel data Update Information: Initial builds for epel 8. fldigi-4.1.07-1.el8 (FEDORA-EPEL-2019-0a37ff) Digital modem program for Linux Update Information: Initial builds for EPEL 8. hamlib-3.3-6.el8 (FEDORA-EPEL-2019-0a37ff) Run-time library to control radio transceivers and receivers Update Information: Initial builds for EPEL 8. hdf5-1.10.5-3.el8 (FEDORA-EPEL-2019-70dbc966dd) A general purpose library and file format for storing scientific data Update Information: Initial builds for epel 8. portaudio-19-30.el8 (FEDORA-EPEL-2019-0a37ff) Free, cross platform, open-source, audio I/O library Update Information: Initial builds for EPEL 8. pugixml-1.9-1.el8 (FEDORA-EPEL-2019-70dbc966dd) A light-weight C++ XML processing library Update Information: Initial builds for epel 8. 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. ___ 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.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
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 signature.asc Description: OpenPGP digital signature ___ 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: The use of the playground
On Tue, 13 Aug 2019 at 11:51, Kevin Fenzi wrote: > On 8/13/19 7:29 AM, Troy Dawson wrote: > > > > > I was not aware that we were using playground for the second usecase. > > I thought the discussions we had in our weekly EPEL Steering meeting > > we agreed *not* to use playground for rebuilding, but had agreed to > > use side-tags. If I was wrong, could someone please point me to the > > document that says we do. > > No, you are right, that is not a usecase we had for playground as far as > I am aware. > > So since that isn't what we were planning, then that is my misunderstanding. I was going off the playground ~= rawhide discussions where we had a place to branch the next EPEL when RHEL decides to move from the python36 module to python40 in RHEL-8.4 or something. However I am expecting that was only me thinking that and everyone else thinking something else. > > Honestly, the package.cfg reasoning is rather vague to me. I'm not > > sure where it came from. I don't remember being asked about it. > > It was in the playground discussions... > > > Personally, if I had been asked I would have said that at the least, > > it needs to be .package.cfg. This is done in several places in the > > Red Hat Brew dist-git, and it stops alot of these types of > > discussions. > > > > But I also didn't fight against it. Why? Because I knew the first > > thing I was going to do was delete it. And ... that's what I've done. > > > > Unfortunately, the way I've deleted it (git merge f30) seems to create > > a freighter boatload of emails to various people (who are not me). > > But the end result is that for a majority of my epel8 dist-git repo's > > are in sync with f30. Are they "perfectly" in sync? Well, I guess > > according to what you define it, no, but I am able to do a "git merge > > " and it merges without any issues. That's what I care about, > > and I bet in the end, that's what you care about as well. > > Yeah. So on thinking about it, we could instead document that you need > to always enable epel8 with epel8-playground. Then, packages not built > for playground will just be in epel8 and it would get them from there. > > Or we could try and do something with pungi that also gathers from > epel8, so epel8-playground would have all the epel8-playground packages > + all the epel8 packages in it. (but that would use more disk space). > > One item brought up in a PM on IRC was to have epel-playground be a 'layer' you need to have epel8 enabled but epel8-playground would sit on top and replace things if there. It fits more with the RHEL channel idea but I don't know how troublesome it would be. The second idea with epel8+epel8-playground as a pungi target sounds less troublesome. > 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 > -- 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: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
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. -- 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.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
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 signature.asc Description: OpenPGP digital signature ___ 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] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2019-08-14 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. Agenda is in the https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next Source: https://apps.fedoraproject.org/calendar/meeting/9364/ ___ 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: The use of the playground
On 8/13/19 7:29 AM, Troy Dawson wrote: > > I was not aware that we were using playground for the second usecase. > I thought the discussions we had in our weekly EPEL Steering meeting > we agreed *not* to use playground for rebuilding, but had agreed to > use side-tags. If I was wrong, could someone please point me to the > document that says we do. No, you are right, that is not a usecase we had for playground as far as I am aware. > Honestly, the package.cfg reasoning is rather vague to me. I'm not > sure where it came from. I don't remember being asked about it. It was in the playground discussions... > Personally, if I had been asked I would have said that at the least, > it needs to be .package.cfg. This is done in several places in the > Red Hat Brew dist-git, and it stops alot of these types of > discussions. > > But I also didn't fight against it. Why? Because I knew the first > thing I was going to do was delete it. And ... that's what I've done. > > Unfortunately, the way I've deleted it (git merge f30) seems to create > a freighter boatload of emails to various people (who are not me). > But the end result is that for a majority of my epel8 dist-git repo's > are in sync with f30. Are they "perfectly" in sync? Well, I guess > according to what you define it, no, but I am able to do a "git merge > " and it merges without any issues. That's what I care about, > and I bet in the end, that's what you care about as well. Yeah. So on thinking about it, we could instead document that you need to always enable epel8 with epel8-playground. Then, packages not built for playground will just be in epel8 and it would get them from there. Or we could try and do something with pungi that also gathers from epel8, so epel8-playground would have all the epel8-playground packages + all the epel8 packages in it. (but that would use more disk space). kevin signature.asc Description: OpenPGP digital signature ___ 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: The use of the playground
On Tue, Aug 13, 2019 at 5:22 AM Mattias Ellert wrote: > > Hi! > > I recently had a discussion about the use of the playground on > pagure.io: https://pagure.io/releng/issue/8582 > > I was asked to bring the discussion here to epel-devel. > > I quote my last comment from the thread below. If you want more details > you can read the entire thread at the pagure link above. > > > You plan is to use the epel-playground repo for two very different and > incompatible tasks. > > The first usecase is as a playground where maintainers can try out new > versions and new features. This means that the versions of packages in > the epel-playground are allowed to be different from the versions in > epel, might have additional features enabled that the versions in epel > are missing, and occasionally could even be backward incompatible with > the version i epel or have a different soname for libraries. > > The second usecase is as a place to do mass rebuilds for new rhel point > releases, where you plan to change the rhel base to a new point release > in epel-playgroind, do the rebuilds in epel-playground, and the when > you change th epel repo to the new point release merge the mass rebuilt > packages back to epel. But, since the use case for the playground > repository was to be a place where new unstable stuff is tested, all > those rebuilds will have been built against these new versions and > might depend on features that are not provided by the dependencies that > are in epel, or be compiled to depend on a different soname than the > library that is available in epel. > > I.e. since the playground is a playground, packages built in the > playground must never be merged into main epel. > > In Fedora there are rebuilds all the time. For new python versions, for > new perl versions, and the recurring mass rebuilds. These are done in > side tags. This can be done without adding a package.cfg file allowing > the build of the package in the side tag, but koji allows this by > default. > > The proper way to do a mass rebukd for epel8 is to declare an epel8- > rebuild sidetag that inherits from the rhel 8.n+1 and epel8 and > definitely must not inherit from epel8-playground. The packages built > in this sidetag can then be safely merged into epel8, when epel8 is > redefined to inherit from rhel 8.n+1. And since it is a sidetag there > should be no need to add any special package.cfg since this is not > needed for sidetags in fedora. > > Mattias I was not aware that we were using playground for the second usecase. I thought the discussions we had in our weekly EPEL Steering meeting we agreed *not* to use playground for rebuilding, but had agreed to use side-tags. If I was wrong, could someone please point me to the document that says we do. Honestly, the package.cfg reasoning is rather vague to me. I'm not sure where it came from. I don't remember being asked about it. Personally, if I had been asked I would have said that at the least, it needs to be .package.cfg. This is done in several places in the Red Hat Brew dist-git, and it stops alot of these types of discussions. But I also didn't fight against it. Why? Because I knew the first thing I was going to do was delete it. And ... that's what I've done. Unfortunately, the way I've deleted it (git merge f30) seems to create a freighter boatload of emails to various people (who are not me). But the end result is that for a majority of my epel8 dist-git repo's are in sync with f30. Are they "perfectly" in sync? Well, I guess according to what you define it, no, but I am able to do a "git merge " and it merges without any issues. That's what I care about, and I bet in the end, that's what you care about as well. 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
[EPEL-devel] The use of the playground
Hi! I recently had a discussion about the use of the playground on pagure.io: https://pagure.io/releng/issue/8582 I was asked to bring the discussion here to epel-devel. I quote my last comment from the thread below. If you want more details you can read the entire thread at the pagure link above. You plan is to use the epel-playground repo for two very different and incompatible tasks. The first usecase is as a playground where maintainers can try out new versions and new features. This means that the versions of packages in the epel-playground are allowed to be different from the versions in epel, might have additional features enabled that the versions in epel are missing, and occasionally could even be backward incompatible with the version i epel or have a different soname for libraries. The second usecase is as a place to do mass rebuilds for new rhel point releases, where you plan to change the rhel base to a new point release in epel-playgroind, do the rebuilds in epel-playground, and the when you change th epel repo to the new point release merge the mass rebuilt packages back to epel. But, since the use case for the playground repository was to be a place where new unstable stuff is tested, all those rebuilds will have been built against these new versions and might depend on features that are not provided by the dependencies that are in epel, or be compiled to depend on a different soname than the library that is available in epel. I.e. since the playground is a playground, packages built in the playground must never be merged into main epel. In Fedora there are rebuilds all the time. For new python versions, for new perl versions, and the recurring mass rebuilds. These are done in side tags. This can be done without adding a package.cfg file allowing the build of the package in the side tag, but koji allows this by default. The proper way to do a mass rebukd for epel8 is to declare an epel8- rebuild sidetag that inherits from the rhel 8.n+1 and epel8 and definitely must not inherit from epel8-playground. The packages built in this sidetag can then be safely merged into epel8, when epel8 is redefined to inherit from rhel 8.n+1. And since it is a sidetag there should be no need to add any special package.cfg since this is not needed for sidetags in fedora. Mattias smime.p7s Description: S/MIME cryptographic signature ___ 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
