[EPEL-devel] Re: Continuing playground discussion
Am 29.08.20 um 00:11 schrieb Troy Dawson: On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson wrote: On Sat, Aug 22, 2020 at 11:12 AM kevin wrote: On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote: On 21/8/20 19:06, Troy Dawson wrote: C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down) D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against. I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option. I like option D too, looks like a more polished version of option B Do we have any data here? Are stream changes breaking epel packages so that they need rebuilds often? It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely? Do we know that many/any people are consuming stream all the time? We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'. I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us? Pros for building against stream: - We would have a way to test EPEL packages that matter against the not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it. Cons for building against stream: - I think you've hit on a big thing. For those wanting a major change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream. - HERE IS THE BIGGEST CON AGAINST USING STREAM -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route. Troy At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above. A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived. If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons. Just a thought - this assumes that when RHEL9 gets out of the door. The above mentioned scenario (possible library changes) will not happen? Implies after May 31, 2024 (EL8 Maintenance Support Phase starts) ... -- Leon ___ 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] plasma has moved from epel into playground causing update conflicts
Can the below be fixed ? I guess this package should not be in both repos... # yum update Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST. Error: Problem 1: package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64 requires libgps.so.24()(64bit), but none of the providers can be installed - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 and gpsd-libs-3.19-4.el8.1.x86_64 - cannot install the best update candidate for package plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64 - cannot install the best update candidate for package gpsd-libs-3.19-4.el8.1.x86_64 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64 - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 and gpsd-libs-3.19-4.el8.1.x86_64 - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64 requires libgps.so.24()(64bit), but none of the providers can be installed - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64 requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground, but none of the providers can be installed - cannot install the best update candidate for package plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64 # yum info plasma-workspace-geolocation Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST. Installed Packages Name : plasma-workspace-geolocation Version : 5.18.4.1 Release : 2.el8 Architecture : x86_64 Size : 206 k Source : plasma-workspace-5.18.4.1-2.el8.src.rpm Repository : @System From repo: epel Summary : Plasma5 geolocation components URL : https://cgit.kde.org/plasma-workspace.git License : GPLv2+ Description : Plasma5 geolocation components. Available Packages Name : plasma-workspace-geolocation Version : 5.18.4.1 Release : 2.epel8.playground Architecture : x86_64 Size : 87 k Source : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm Repository : epel-playground Summary : Plasma5 geolocation components URL : https://cgit.kde.org/plasma-workspace.git License : GPLv2+ Description : Plasma5 geolocation components. ___ 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: Continuing playground discussion
On Fri, Aug 28, 2020, at 6:11 PM, Troy Dawson wrote: > On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson wrote: > > > > On Sat, Aug 22, 2020 at 11:12 AM kevin wrote: > > > > > > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote: > > > > > > > > On 21/8/20 19:06, Troy Dawson wrote: > > > > > > > > C) Drop playground. Say it was an interesting experiment and we > > > > > learned stuff, but shut it down. > > > > > (and clean up the package.cfg files as part of shutting it down) > > > > > > > > > > D) > > > > > 1 - Manual builds only. No package.cfg files. No automatic builds. > > > > > 2 - Assume playground depends on epel8. > > > > > 3 - Use CentOS 8 Stream to build against. > > > > > > > > > > I am leaning towards option D. > > > > > We've already got all the playground infrastructure setup. I don't > > > > > want to waste that. So, although I said option C in the meeting, that > > > > > doesn't mean I want it, I was just stating it was an option. > > > > I like option D too, looks like a more polished version of option B > > > > > > Do we have any data here? > > > > > > Are stream changes breaking epel packages so that they need rebuilds > > > often? > > > > > > It will mean that if someone wants to use playground to test some large > > > change in epel, they will have to find people who also enable stream to > > > test it most likely? > > > > > > Do we know that many/any people are consuming stream all the time? > > > > > > We also don't have much way to say 'if you enable epel8-playground you > > > have to enable stream repos also'. > > > > > > I guess I don't think the yummy to trouble ratio is good enough here to > > > justify the trouble of enabling stream. Can you expand on why this is > > > good/what it gets us? > > > > > > > Pros for building against stream: > > - We would have a way to test EPEL packages that matter against the > > not yet released RHEL version. > > -- How often would this matter? > > -- It's hard to say. There might not be a single EPEL package needing > > this for the entire RHEL 8.3 release. > > -- I know for the 8.2 release, I would have liked it so I would have > > had a place to let others test my updated KDE. > > --- But I found a work around, so I didn't have to have it. > > > > Cons for building against stream: > > - I think you've hit on a big thing. For those wanting a major > > change, but don't care about stream, then playground becomes useless. > > -- So this cuts down on the usefulness of playground. Packagers who > > want a major change in their package, and are working on stream. > > - HERE IS THE BIGGEST CON AGAINST USING STREAM > > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes > > out. At some point after that, it switches to being based off RHEL9. > > --- This means that infrastructure is going to have to switch > > everything back to being built off RHEL. > > --- We will have to re-document things. > > --- More confusion if we had go the CentOS Stream route. > > > > Troy > > At the EPEL Steering Committee Meeting, this was discussed again. > I believe we all agree that having -playground build off Stream isn't > a good thing. > But we are also concerned about possible library changes in RHEL8 that > might affect EPEL8 packages, and having something based off Stream > would be good. > Here is the proposal. > Note: A) was re-written with better wording than above. > > A) epel8-playground > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume playground depends on epel8. > 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. > > E) epel8-next > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume -next depends on epel. > 3 - Built off CentOS Stream. > 4 - Has a limited lifetime that corresponds with the CentOS Stream / > RHEL lifetime. > -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, > then epel8-next get's archived. > > If people are wondering about the name, it was decided to use -next > instead of -stream, due to the overuse of 'stream' among other > reasons. > > Thoughts? Sounds like the perfect solution to me! V/r, James Cassell ___ 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: Continuing playground discussion
On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson wrote: > > On Sat, Aug 22, 2020 at 11:12 AM kevin wrote: > > > > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote: > > > > > > On 21/8/20 19:06, Troy Dawson wrote: > > > > > > C) Drop playground. Say it was an interesting experiment and we > > > > learned stuff, but shut it down. > > > > (and clean up the package.cfg files as part of shutting it down) > > > > > > > > D) > > > > 1 - Manual builds only. No package.cfg files. No automatic builds. > > > > 2 - Assume playground depends on epel8. > > > > 3 - Use CentOS 8 Stream to build against. > > > > > > > > I am leaning towards option D. > > > > We've already got all the playground infrastructure setup. I don't > > > > want to waste that. So, although I said option C in the meeting, that > > > > doesn't mean I want it, I was just stating it was an option. > > > I like option D too, looks like a more polished version of option B > > > > Do we have any data here? > > > > Are stream changes breaking epel packages so that they need rebuilds > > often? > > > > It will mean that if someone wants to use playground to test some large > > change in epel, they will have to find people who also enable stream to > > test it most likely? > > > > Do we know that many/any people are consuming stream all the time? > > > > We also don't have much way to say 'if you enable epel8-playground you > > have to enable stream repos also'. > > > > I guess I don't think the yummy to trouble ratio is good enough here to > > justify the trouble of enabling stream. Can you expand on why this is > > good/what it gets us? > > > > Pros for building against stream: > - We would have a way to test EPEL packages that matter against the > not yet released RHEL version. > -- How often would this matter? > -- It's hard to say. There might not be a single EPEL package needing > this for the entire RHEL 8.3 release. > -- I know for the 8.2 release, I would have liked it so I would have > had a place to let others test my updated KDE. > --- But I found a work around, so I didn't have to have it. > > Cons for building against stream: > - I think you've hit on a big thing. For those wanting a major > change, but don't care about stream, then playground becomes useless. > -- So this cuts down on the usefulness of playground. Packagers who > want a major change in their package, and are working on stream. > - HERE IS THE BIGGEST CON AGAINST USING STREAM > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes > out. At some point after that, it switches to being based off RHEL9. > --- This means that infrastructure is going to have to switch > everything back to being built off RHEL. > --- We will have to re-document things. > --- More confusion if we had go the CentOS Stream route. > > Troy At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above. A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived. If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons. Thoughts? 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] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1af9888c22 golang-1.15-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing php-horde-Horde-Core-2.31.15-1.el6 php-horde-imp-6.2.27-1.el6 pspg-3.1.3-1.el6 Details about builds: php-horde-Horde-Core-2.31.15-1.el6 (FEDORA-EPEL-2020-84711fb527) Horde Core Framework libraries Update Information: **Horde_Core 2.31.15** * [mjr] Fix ActiveSync SmartForward handling. ChangeLog: * Fri Aug 28 2020 Remi Collet - 2.31.15-1 - update to 2.31.15 php-horde-imp-6.2.27-1.el6 (FEDORA-EPEL-2020-53ec4aba67) A web based webmail system Update Information: **imp 6.2.27** * [mjr] Fix attachments disappearing when forwarding in PHP 7.4 (Bug #15031). * [mjr] Prevent creating an empty To: header (Bug #15019). * |+ ChangeLog: * Fri Aug 28 2020 Remi Collet - 6.2.27-1 - update to 6.2.27 pspg-3.1.3-1.el6 (FEDORA-EPEL-2020-2f125922be) A unix pager optimized for psql Update Information: new upstream release, per release notes: - https://github.com/okbob/pspg/releases/tag/3.1.3 - https://github.com/okbob/pspg/releases/tag/3.1.2 - https://github.com/okbob/pspg/releases/tag/3.1.1 - https://github.com/okbob/pspg/releases/tag/3.0.7 - https://github.com/okbob/pspg/releases/tag/3.0.6 ChangeLog: * Fri Aug 28 2020 Pavel Raiskup - 3.1.3-1 - new upstream release, per release notes: https://github.com/okbob/pspg/releases/tag/3.1.3 https://github.com/okbob/pspg/releases/tag/3.1.2 https://github.com/okbob/pspg/releases/tag/3.1.1 https://github.com/okbob/pspg/releases/tag/3.0.7 https://github.com/okbob/pspg/releases/tag/3.0.6 * Tue Jul 28 2020 Fedora Release Engineering - 3.0.4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1826790 - pspg-3.1.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1826790 ___ 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
