[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: EPEL8 conflict policy
On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote: > There does not appear to be an explicit conflict policy for EPEL8: > > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F > > I got a report against python3-s3transfer and python3-botocore > conflicting with the CentOS 8 HighAvailability repo. No idea if this is > an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630 > > It looks like we have avoided conflicts with the "ha" repos in the past, > and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my > RHEL8 developer license machine so it does seem available to everyone. > It's not available to everyone. It's a paid add-on. My understanding is that EPEL avoids conflicting only with the BaseOS, AppStream, and CodeReady Linux Builder repositories. c.f., ansible, which is more widely available than HA, but also carried in EPEL. 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: Removing baseurl= from default repo files
On Mon, Feb 10, 2020, at 1:36 PM, Stephen John Smoogen wrote: > > For the longest time, the Fedora Project has included a baseurl= line > in its configs as an alternative to the basic metalink= line. EPEL has > followed along, and I expect a lot of users have some sort of > sed/awk/ed script which looks for a #baseurl and does something with > it. > > The upstream configs in Fedora's repo files are changing to only have > the metalink= line in them, and a couple of Pull Requests to make the > changes to the EPEL config files have been placed. > > https://src.fedoraproject.org/rpms/epel-release/pull-request/6 > https://src.fedoraproject.org/rpms/epel-release/pull-request/7 > > I am announcing the change here so that people can be aware before this > starts to show up in EPEL in the next month or so. > This will definitely break a bunch of scripts. Can we at least change it to point to example.com if the server load is too great? I use this to point to local mirrors when mirror manager is not an option. 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: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 6:57 PM, Stephen Gallagher wrote: > On Thu, May 30, 2019 at 4:25 PM James Cassell > wrote: > > > > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > > approach leaves open the possibility of tagging other builds into > > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > > need to be communicated that these repositories will not receive > > > > updates and are intended to be only a snapshot of the past that is > > > > known to work with a particular RHEL 8.Y base. > > > > > > > This will be very helpful, especially if the epel-release .repo file honors > > the $releasever variable. > > > Can you explain what behavior you see here? I can't really parse from > your reply what you think/expect to have happen here, and I'd like to > make sure we address it properly. The use case is preventing updates past a minor version without explicit administrator action. We're able to do this by forcing the $releasever yum variable to be 7.50 (for RHEL) or 7.5.1804 (for CentOS). It would be convenient to keep this approach working by using the yum var in the repo file, with requisite symlinks in place on the mirrors. The repo file as is today would likely work for this purpose (but I don't have it in front of me to verify.) 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://getfedora.org/code-of-conduct.html 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: Proposal: EPEL 8 Branch Strategy
On Thu, May 30, 2019, at 3:18 PM, Kevin Fenzi wrote: > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > [...] > > > > When the time comes where an incompatible change needs to land, they > > must be coordinated to land on an approved schedule. The exact > > mechanism of scheduling and coordinating this is out of scope for this > > document and will be decided on by the EPEL Steering Committee. > > Yeah, but we should probibly try and figure it out. > > I guess there is: > A. Right after the new minor release comes out > B. Right after the new minor release comes out for CentOS > C. Some arbitrary time after the new minor release comes out. > I'd be in favor of B. [...] > > # Historical Composes > > Since major changes may occur at RHEL 8.Y releases, we want to support > > allowing our users to lock onto a repository that matches that > > release. For this, we will generate historical composes, which will > > match the stable package set of the prior minor release once the new > > minor release comes out. > > > > At 00:00 UTC of the day following a new RHEL 8.Y release, an updated > > epel-release package will be pushed, updating the %dist tag to the new > > .epel8_Y value. All new builds will thus have the new dist tag. A > > script will be run at this time to apply a new Koji tag (epel8-8.Y) to > > the latest build of a package with one of the following tags: [ > > epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y > > repository will be created at this time from all packages currently > > tagged as epel8-8.Y. > > So, we will also have to unpush/obsolete/close all pending bodhi updates > right? Since things will need rebuilding with the new dist tag for the > new minor. I'd say just cancel any karma, reset the timer, then let them go out as-is once/if they again pass the bodhi process. > > > > Historical composes are intended to be frozen and unchanging, but this > > approach leaves open the possibility of tagging other builds into > > epel8-8.Y and regenerating the compose if the need arises. It will > > need to be communicated that these repositories will not receive > > updates and are intended to be only a snapshot of the past that is > > known to work with a particular RHEL 8.Y base. > This will be very helpful, especially if the epel-release .repo file honors the $releasever variable. 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://getfedora.org/code-of-conduct.html 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: Fedora project login
On Wed, Jan 2, 2019, at 1:31 PM, Kevin Fenzi wrote: > On 1/2/19 12:44 AM, Michael A. Peters wrote: > > Hello, > > > > Extremely BAD experience trying to log in at > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9a4a06731c > > Sorry to hear it. ;( > > > First I couldn't remember my username but I could remember my password > > and the VERY BROKEN DESIGN does not allow me to request it send me a > > reminder of my username. > > > > Finally figured out my username and it sent me a password reset. > > > > Reset password, and it would not let me log in. > > > > Attempted several times. > > > > Figuring I entered it wrong and did the reset again. > > > > Tried the password the way it was in my password manager and it said I > > couldn't reset it to an old password. > > > > So regenerated new password - but with that also could not log in. > > Can you expand on that? What did it do? You got a username/password > dialog? It said password incorrect? or any other messages/errors? > Here's my experience: Go to https://bodhi.fedoraproject.org Click "Login" Dialog pops up asking for user/pass Click Cancel Page comes up for FAS log in Put Fedora Account System credentials Click "Log In" Get redirected back to bodhi, logged in. Typing my FAS credentials into the first pop up dialog just shows the dialog again and does not log me in. V/r, James Cassell > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Email had 1 attachment: > + signature.asc > 1k (application/pgp-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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
