[EPEL-devel] Re: RFC: Django latest vs LTS maintenance plan
On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote: > Hi all, > > With the recent EOL of the Django 3.2 LTS series[^1], and Django being a > key component of our mailing list infra for both Fedora and CentOS, I > would like to propose the following plan to maintain Django in both > Fedora and EPEL: > > - Fedora: `python-django` maintained as currently, not tracking any LTS > series > - **but** also fork off `python-django` each time it hits an LTS > series to make a new `python-djangoX.Y` (e.g. > https://bugzilla.redhat.com/show_bug.cgi?id=2274198) > - LTS packages are introduced in Fedora first, until they either reach > EOL or no longer build, at which point they are retired in Rawhide. > See below for the EOL case. > - EPEL: we will only branch LTS packages (as is the case now, with > `python-django3` - though under the new naming scheme it should have > been `python-django3.2`) > - Handling EOL > - not an issue for `python-django` - we just keep rebasing it To be clear, in fedora right? There wouldn't be a bare python-django in EPEL? > - for LTS releases in Fedora, retire in Rawhide if the series will > EOL before the EOL of the upcoming Fedora release > - for LTS releases in EPEL, once it is EOL (like `python-django3`) > we mark it as `Provides: deprecated()` and retire it if there is a > replacement that works with add-on packages, *and* there is a CVE > that is not fixed > - Package ACL: cc-ing the current maintainers of python-django here. > Please let me know if > - you want to be added to the LTS packages as well > - you want to be removed from python-django > - you're not currently involved but want to help out > - I'll also add infra-sig to the ACL for the LTS packages, as in > practice they might need access to fix any issue affecting Mailman > > The different Django stacks are in the process of being updated so they > can be swapped without affecting dependents, by providing and > conflicting with the virtual `python-django-impl`; not only will this > allow us to swap one Django LTS for another in EPEL when the older one > EOLs, but it also allows those with dependencies that are not qualified > for the latest Django to swap to the LTS in Fedora > > Let me know if this makes sense, or if you have ideas of how to handle > some of these better. I think it does make a lot of sense. ;) On the epel side, it would be good to make some noise/announce when a LTS one is marked deprecated and when it's retired, since 3rd parties might be using it for the external stuff even if everything in EPEL moves to the new one. Would a EPEL package moving to a new LTS release need exceptions/announcements also? I mean, ideally it doesn't matter, but it would be a large version jump, even if the dependent package didn't change otherwise. Also, there might be cases where the dependent package does have to change... ie, foo-1.0 works with django-3.2, but when 4.2 lands you have to upgrade to foo-2.0 to work with it? Anyhow, I think this is a pretty reasonable process, but we should make sure and communicate it very well, document it and make sure epel steering comittee is happy with it. kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce
On Mon, Jan 29, 2024 at 06:40:19AM -0800, Troy Dawson wrote: > On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa wrote: > > > > This seems reasonable to me. > > > > I agree with Neal, this looks good to me. > Thank you for the nice explanation/write-up. Yeah, same here. Seems reasonable... kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: retirement of klee from EPEL 9
On Thu, Sep 28, 2023 at 10:37:28PM -0500, Carl George wrote: > It recently came to my attention that the klee package in EPEL 9 > needed to be rebuilt against the LLVM 15 library that shipped in RHEL > 9.2. I filed a bug for this [0], and then noticed it was assigned to > "Orphan Owner". It looks like the maintainer retired it from Fedora > [1][2] due the upstream not being compatible with LLVM 15 [3]. I am > not the maintainer of this package, but I intend to retire this > package from EPEL 9 to avoid having a package with installation issue > lingering around. The EPEL retirement policy [4] doesn't cover this > exact scenario, so I plan to bring it up for discussion at the next > EPEL Steering Committee meeting. We could delay the retirement for > one week (the policy for security-related retirements) or two weeks > (the policy for lack-of-time retirements), but my preference would be > to retire it ASAP. Retiring seems reasonable here. kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Ansible in EPEL 9
On Tue, May 16, 2023 at 11:05:26AM +0200, Leon Fauster via epel-devel wrote: > Am 15.05.23 um 20:50 schrieb Jonathan Wright: > > EPEL tracks RHEL, not clones. > > > > EPEL10 is likely to resolve this, however. Ref > > https://discussion.fedoraproject.org/t/epel-10-proposal > > <https://discussion.fedoraproject.org/t/epel-10-proposal> > > > > On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel > ... > > > > > > While setting up a new workstation with an EL rebuild, I run into the > > situation that ansible is not installable (rocky still on 9.1). Is there > > a chance from EPEL side to close this time gap by at least keep older > > packages (current-1) on the repos? Like epel-next closes the "forward" > > gap, this would close such "backward" gap, thought ... > > > > -- > > Leon > > > Well, my point was not a strategy change, more a technical variation > that eliminates a lot of cases (also the above mentioned). Without > a single downgrade path, regressions can not be addressed. Just an > example: https://bugzilla.redhat.com/show_bug.cgi?id=2184351 > > So, it was a general feasibility request. For those that slip into > such situation; there are still the repo archives, that get a copy > when a minor release happens (this one I had forgotten). This has been asked for many times, but our compose tooling doesn't lend itself to doing this. :( kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote: > > This is what I have on my ticket. Respond soon (by tomorrow end of day) if > you think I need changes. > > Subject: > Notice: will be automatically retired from epel when RHEL > . is released > > Comment: > Thank you for your work maintaining in epel. This package > has been considered important enough to Red Hat's customers that Red Hat > has decided to promote it to be an official part of RHEL. It will be part > of RHEL .. When that is released, EPEL automation will > remove from epel. That looks pretty good, but I might suggest adding something more explicit at the end: Note that this issue is purely informational, you do not need to take any actions at this time. But perhaps thats overkill. ;) kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On Tue, Jan 31, 2023 at 07:21:03PM -0700, Orion Poplawski wrote: > On 1/31/23 11:03, Maxwell G wrote: > > On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote: > > Hi all, > > > > > Hi, Orion > > > Thanks for raising this question. > > > > Indeed! > > > > > I wonder if it's possible to continue to update collections to the > > > newest versions anyway. If someone wants to use the collection version > > > provided in "big ansible", they would use ansible 6.3.0 with all > > > included. If they want a newer collection, they can install a separate > > > newest RPM. > > > > I agree. I think we should update collections to the next major version > > (if it exists) after each RHEL minor release and then keep them updated > > with point releases in between. We update the ansible bundle to the next > > major version that corresponds to RHEL's ansible-core version at each > > RHEL minor release, so it makes to do the same with the standalone > > collection packages. Collection versions that are EOL upstream won't be > > tested with newer ansible-core versions. > > Does this capture the general sentiment? > > - ansible is the static/stable collection of collections paired with the > provided ansible-core for the life of the point release > > - ansible-collection-* packages will be at least the version of the > collection in ansible, and optionally higher while giving due diligence to > avoiding breaking changes. That sounds mostly reasonable. I guess I could come up with a crazy case like 'the version in ansible has some problem that wasn't noticed, so I want to keep the seperate collection on a older version until it's fixed' though. kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On Tue, Jan 31, 2023 at 06:03:48PM +, Maxwell G wrote: > On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote: > Hi all, Note that some folks cc'ed are not subscribed to epel-devel, so it probibly rejected their posts. :( > > > Hi, Orion > > Thanks for raising this question. > > Indeed! > > > I wonder if it's possible to continue to update collections to the > > newest versions anyway. If someone wants to use the collection version > > provided in "big ansible", they would use ansible 6.3.0 with all > > included. If they want a newer collection, they can install a separate > > newest RPM. > > I agree. I think we should update collections to the next major version > (if it exists) after each RHEL minor release and then keep them updated > with point releases in between. We update the ansible bundle to the next > major version that corresponds to RHEL's ansible-core version at each > RHEL minor release, so it makes to do the same with the standalone > collection packages. Collection versions that are EOL upstream won't be > tested with newer ansible-core versions. Yes, when we first started to package collections we made sure (although I have not checked if anything changed) that the seperately packaged collections would override the bundled ones in the ansible package. So, while the ansible collection of collections and ansible-core are (and should be) closely tied together, the seperately packaged ansible collections should be free to update as long as they continue to work ok with ansible-core thats provided/etc. So, in practice I personally have been thinking of 'ansible' as the stable collection of collections, and the seperately packaged collections as 'next' or 'fast moving' channel. Just my 2cents. kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators
On Tue, Jan 31, 2023 at 10:19:09AM +0100, Jitka Plesnikova wrote:
> Hi,
>
> I added the package perl-generators-epel to EPEL 7/8/9. The package is
> adding the behavior provided in perl-generators-1.16.
>
> I created pull requests for epel-rpm-macros to add perl-generators-epel
> to EPEL buildroot.
>
> Pull Request
> EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61
> EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60
> EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
>
> Could anybody please merge them and build the packages or shall I do it
> myself?
Done. Building now.
Thanks for the pr's
kevin
--
>
> Thanks,
> Jitka
>
> On 12/6/22 04:40, Maxwell G via epel-devel wrote:
> > On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
> > > Could be the following file added to the package epel-rpm-macros (or
> > > anything like this) for EPEL 9?
> > It could, but it might be better to include this in a subpackage of
> > epel-rpm-macros or as a separate perl-generators-epel component. We
> > could pull it in with (package-name-here if perl-generators). This won't
> > work in EPEL 7 which unfortunately doesn't support rich dependencies.
> >
> > > But I don't know how to do it for EPEL 7/8, because the above file
> > > doesn't work.
> > > It ends with error [2]:
> > > error: Couldn't exec perl-libs: No such file or directory
> > >
> > > Do you have any idea if there is any other way how to provide
> > > maintainers this functionality for EPEL 7/8?
> > Parametric macro dependency generators are not supported in EPEL 7 and
> > 8's RPM versions. You can still implement this using a "regular"
> > dependency generator. This is also described in the RPM
> > documentation[1]. Instead of specifying %__perlcompat_requires() and
> > writing an RPM macro that accepts a path name as %1, you specify
> > `%__percompat_requires /path/to/executable`. That script receives a
> > newline separated list of paths as stdin and prints the generated
> > dependencies to stdout separated by newlines.
> >
> > So perlcompat.attr could look something like
> >
> > ```
> > %__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}
> >
> > # %%__perlcompat_path can stay the same.
> > ```
> >
> > These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
> > passed to the script as an argument, because the script of course
> > doesn't have access to the RPM context. This can be any executable
> > written in any language, but it should be straightforward to do this in
> > shell.
> >
> >
> > [1]:
> > https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
> >
> > --
> > Maxwell G (@gotmax23)
> > Pronouns: He/Him/His
> > ___
> > 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
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jitka Plesnikova
> Senior Software Engineer
> Red Hat
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
signature.asc
Description: 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://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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Adding Package to side-tag
On Sat, Sep 03, 2022 at 08:32:47PM +1000, Frank Crawford wrote: > > The document I used > was > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages > > It was the only place I could find that really talked about side-tags, > and wait-repo looks only mentioned in passing. Once you know it is > needed it is more obvious, but not if you haven't used them much > before. Well, it does say: "The latter is important if any builds depend on previous ones in the side tag. Use koji wait-repo --build to ensure that the respective build is available in the build root for subsequent builds. " But if you can see a way to be more clear there, perhaps you could put in a PR? kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Sep 01, 2022 at 12:12:07PM -0500, Maxwell G via epel-devel wrote: > On Wednesday, August 31, 2022 Troy Dawson wrote: > > EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL > > maintainer wants to add a package to RHEL 8 or 9 they start a "new package > > workflow". There are several automations that happen when they start that > > workflow. One of them is checking if the package is already in epel. If > > it is, it creates a bugzilla against that package, and links that bug > > against the EPEL2RHEL tracker. [1] > > Remember, this check currently happens at the beginning of the new package > > workflow. Before a package has been branched, built, or put into testing > > repos. > > I think this whole process should be automated. File bugs that say "Heads up: > your package will be automatically retired after the release of RHEL X.X" and > provide some explanation. This will have multiple benefits: > > 1. Saying "you'll have to do something in six months, but it'll be bad if you > do it now" is quite difficult to follow. > > 2. We can send out one announcement to epel-announce about which packages are > going to be retired and when that'll happen, instead of retiring packages in > a > piecemeal manner. > > 3. The maintainers won't have to remember to do it. > > 4. If we find out that a package is buildroot only, then we'll close the bug > and exclude it from the automatic retiring. I really like this approach... :) kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Adding Package to side-tag
On Sun, Aug 28, 2022 at 07:38:31PM +1000, Frank Crawford wrote: > On Sat, 2022-08-27 at 14:58 -0500, Maxwell G via epel-devel wrote: > > n 22/08/27 04:03PM, Frank Crawford wrote: > > > While building two related new packages for EPEL9 with a > > > chainbuild, > > > the second one failed, however, now I am trying to work out how to > > > specify the completed package in the build for the second package. > > > > > > I have tried creating a side-tag and add the completed build to the > > > side-tag, then building the second package in that side-tag, but it > > > still claims that it can't find the first package, which it > > > requires to > > > build. > > > > Can you please provide more information? What are the > > builds/packages? > > What commands did you run? How did you add the first package to the > > side > > tag? Did you wait for the side tag repo to refresh before trying to > > build the second package? > > I think you answered my issue here, I did not allow sufficient time for > the repo to refresh before submitting the second build. > > For reference, the packages were python-zipp-0.5.1-1.el9 and python- > importlib-metadata-4.6.3-2.el9 and the commands I ran were: > > fedpkg request-side-tag > koji wait-repo > koji tag-pkg python-zipp-0.5.1-1.el9 > fedpkg build --target= > > It looks like I needed to do another "koji wait-repo " between the > tag-pkg and build, but I will say that it is not obvious in any of the > documentation I could find, that this needed. :( Which documentation were you looking at for this? We should try and update it... The wait repo is needed because you added a build and now it needs to regenerate the repodata to include it. kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Orphaning EPEL Branches
On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote: > Hi EPEL folks, > > In the past couple EPEL SCo meetings, we have been discussing adding a > new package retirement policy for EPEL packages. That reads amusingly to me... to be clear 'new policy' not 'new packages'. ...snip... > > Here are my thoughts: > > If an entire Fedora package that has (an) EPEL branch(es) is orphaned, > the EPEL branch(es) should probably be orphaned at the same time as the > rawhide branch. Otherwise, we'd have to treat only orphaning an EPEL > branch as a special case: > > We could create an issue tracker for this. Packagers would have to > submit a ticket requesting to orphan a certain package's EPEL branch(es) > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we > could have a provenpackager in the SIG go through and manually retire > the packages that haven't been picked up after six weeks. The later will > be difficult if we have a large volume, but I don't expect that. We > could script this if necessary or just ask the submitter to do it > themself. > > This doesn't allow picking up packages in a self-service manner, but I > don't think that's a huge deal for our case. > > > [1]: > https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#_orphaning_and_retiring_packages I'm not sure we want to CC epel-devel on these, perhaps we could have a script that processes them once a week or so and sends a summary to the list? But I am not sure how much volume we would expect here. ;( I wonder if we could get some cycles from developers to adjust pagure-dist-git for this case to make it more self-service. (taking orphan packages over). kevin signature.asc Description: 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote: > Hi, > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee > wrote: > > > Hi, > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL > > under Projects at issues.redhat.com. > > What is the correct project for RHEL 9 ? > > > > You have to file a bug for "distribution" component in Bugzilla. Please don't file it there. :) Take a look at the handy doc: https://docs.fedoraproject.org/en-US/epel/epel-package-request/ If anything is unclear there, please do let us know. While RHEL may be moving to jira with RHEL10, EPEL is very likely to stay with whatever Fedora is using (currently bugzilla). kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Does EPEL 9 Koji have older c9s packages than local mock?
On Fri, Apr 22, 2022 at 07:53:10PM +0200, Miro Hrončok wrote: > Hello, > > I've been trying to debug a segfault during %check that only occurs in epel9 > Koji, but not in mock. > > At the end, I compared the list of packages with: ...snip... > > This seems like my local mock has newer c9s packages than the Koji build > repo. Is that expected, or is pulling c9s packages into the build repo stuck > on Koji side? It's expected, because epel9 is going to be tracking RHEL9 as soon as it's out, so we cut the sync when CentOS stream 9 started tracking 9.1 packages. Your local mock likely has 9.1 packages. > Actually, I got an idea that EPEL 9 Koji might already be using (internal?) > RHEL 9.0, possibly I have missed this switch... However, the > centos-stream-release package contraditcs taht idea :/ > > I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g. > pyproject-rpm-macros-1.0.1-1.el9. It's not using rhel9 (yet) just a snapshot of stream9 back when it was tracking 9.0. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL-ANNOUNCE retirement of ansible-2.9.x
Looks like your orig message didn't get to epel-devel, perhaps you
aren't subscribed?
On Thu, Apr 21, 2022 at 04:03:20PM +0200, Michael Trip wrote:
> Hi Kevin,
>
> What does that mean for the ansible rpm package in general? Do we have
> to remove the ansible RPM from our systems and install ansible through
> pip ? Or will ansible-core also land in EPEL 7? My apologies if i don´t
> understand it correctly.
epel7: ansible-2.9.x rpm in epel will be retired (ie, dropped, removed,
no longer appear in repos).
So, yes, you would need to install from pip or if you are using RHEL you
could I think still install the rpm from the ansible-engine channel.
If using pip, you would need to make sure and specify <3.0 or it will
try and install the current version and fail (because python is too old
to meet requirements).
Also, do note that it will be EOL and getting no updates... not even
security updates. :(
kevin
--
>
> Kind regards,
>
> Michael Trip
>
> On Tue, 2022-04-19 at 13:14 -0700, Kevin Fenzi wrote:
> > Greetings.
> >
> > Just a reminder that ansible-core (The split out ansible 'engine')
> > will
> > be landing in RHEL8.6 (and other el builds thereafter). Also, the
> > ansible 2.9.x ('ansible classic') package is going to going end of
> > life
> > and no longer supported in that same timeframe.
> >
> > So, at that time I will be retiring the ansible 2.9.x package in
> > epel7.
> >
> > In epel8 I will be converting the 'ansible' epel8 package into the
> > upstream ansible-5 meta collections package (which also pulls in
> > ansible-core).
> >
> > epel7 and epel8 ansible users are advised to plan for this
> > retirement/change.
> >
> > Thank you,
> >
> > kevin
> > ___
> > epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> > epel-announce-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-annou...@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
signature.asc
Description: 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://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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] retirement of ansible-2.9.x
Greetings.
Just a reminder that ansible-core (The split out ansible 'engine') will
be landing in RHEL8.6 (and other el builds thereafter). Also, the
ansible 2.9.x ('ansible classic') package is going to going end of life
and no longer supported in that same timeframe.
So, at that time I will be retiring the ansible 2.9.x package in epel7.
In epel8 I will be converting the 'ansible' epel8 package into the
upstream ansible-5 meta collections package (which also pulls in
ansible-core).
epel7 and epel8 ansible users are advised to plan for this
retirement/change.
Thank you,
kevin
signature.asc
Description: 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://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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL conflicts with Satellite 6 packages
On Sun, Apr 17, 2022 at 12:39:56PM -0400, Stephen John Smoogen wrote: > On Sun, 17 Apr 2022 at 09:54, Amos wrote: > > > > On Wed, 1 Jun 2016 12:31:01 -0600 Erinn Looney-Triggs > > > > > > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provid... > > <https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F> > > > So, thats not a channel that EPEL strives to avoid conflicts with. We > > could consider how to > > > better avoid conflicts with that channel, but I'm not sure there's any > > easy way there. kevin > > > > Apologies for replying to this old thread, but unless I'm mistaken, this > > is still a problem. More recently, there were two blog posts from Red Hat > > that extolled the virtues of adding the EPEL repository into Satellite: > > > > https://www.redhat.com/sysadmin/epel-8-repo-satellite-6 > > > > https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it > > > > Apparently, however, at least based on our own experience, this is still a > > problem with RHEL7, 8. Is there anything new on this topic? > > > > > Hi, I realize you are having a problem, but the above email says NOTHING > about what the problem is. What packages are you having and how are you > having them? This is needed before any volunteer here can help. Yeah, I'll echo smooge here. Can you expand on exactly what you are hitting? I can't seem to find the orig thread from 2016 in my mailbox, so I'm really not sure what the issue is here. ;( kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Modules for EPEL9
On Thu, Mar 24, 2022 at 07:09:33PM -0400, Neal Gompa wrote: > On Thu, Mar 24, 2022 at 6:38 PM Kevin Fenzi wrote: > > > > On Thu, Mar 24, 2022 at 07:56:15AM -0700, Troy Dawson wrote: > > > It was talked about December 2021, and pushed off to the new year. > > > https://pagure.io/epel/issue/135 > > > It's the new year, and you are the first this year to ask for it. So, > > > time > > > to get it back in the discussions. > > > Could you please put what modules you want to build in that ticket, so we > > > can help prioritize it. > > > > Personally, I'd be happy just not doing modules at all for epel9 given > > the limitations we have (cannot build any module that requires rhel > > modules). I'd prefer we have folks just use compatiblity packages > > instead. > > > > What's stopping us from being able to depend on RHEL modules? Koji now > supports enabling module streams on a per tag basis, so it *should* be > possible now. As far as I know, MBS has no way of handling this case. It only knows about modules it itself has built, it doesn't have a way to tag in an externally built RHEL module to be used as a BuildRequires for another module. https://pagure.io/fm-orchestrator/issue/1653 kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?
On Wed, Mar 23, 2022 at 09:18:08PM -0500, Carl George wrote: > On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote: > > > > Typically EPEL inherits policy from Fedora, diverging when necessary. > > Here is the corresponding section of Fedora policy. > > > > "All package dependencies (build-time or runtime, regular, weak or > > otherwise) MUST ALWAYS be satisfiable within the official Fedora > > repositories." > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies > > > > We don't consider HA or RS part of the base RHEL distribution > > (referred to in policy as the "Target Base"). However, I don't think Well, for 8 and 9... for 7 we do. ;) > > we should strictly forbid any dependency on HA or RS packages, because > > that would require unnecessary duplication of HA/RS packages in EPEL > > (which is allowed, but shouldn't be required IMO). I suggest a > > compromise that we can make the policy: > > > > "All EPEL package dependencies (build-time or runtime) MUST ALWAYS be > > satisfiable within the Target Base or EPEL itself. Weak package > > dependencies are allowed on packages from additional RHEL channels > > that are not part of the Target Base, such as the HighAvailability > > channel." > > > > -- > > Carl George > > We discussed this a bit further at today's EPEL Steering Committee. > One alternative that was suggested was to just add the HA and RS repos > to the target base list. The initial impact of that would be that > several packages already in EPEL8 would become policy violations and > would have to be retired. Yeah, I guess thats pretty anoying in 8 since we didn't start with them. ;( So, if we did allow weak deps to packages in other non our Base repos, wouldn't that not actually work for the case that started this thread? ie, say I have a foo-plugin package and foo is in a different non epel base rhel channel and I add a Reccomends for it in epel. People who have the channel enabled would be fine but if someone else installed foo-plugin it would just... not work. Also could we tell if deps changed? Say I have foo-plugin in epel Reccommending foo, and RHEL drops foo. None of our 'will it install' or broken deps type checks will know that it is now not working. ;( If we don't add HA and RS to the base epel repos, I guess we could just allow people to build those things they need in epel, but then of course they get to maintain them. ;( Perhaps instead of a strict rule we could just ask everything that has this issue to get an exception? Not an easy case. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Modules for EPEL9
On Thu, Mar 24, 2022 at 07:56:15AM -0700, Troy Dawson wrote: > It was talked about December 2021, and pushed off to the new year. > https://pagure.io/epel/issue/135 > It's the new year, and you are the first this year to ask for it. So, time > to get it back in the discussions. > Could you please put what modules you want to build in that ticket, so we > can help prioritize it. Personally, I'd be happy just not doing modules at all for epel9 given the limitations we have (cannot build any module that requires rhel modules). I'd prefer we have folks just use compatiblity packages instead. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Revisiting policy for limited arch packages?
On Mon, Jan 31, 2022 at 06:48:21PM +, Gary Buhrmaster wrote: > On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi wrote: > > > The limited arch policy we had for epel7 had a number of problems. > > At first we just said 'rebuild the exact rhel version' and then we > > switched to 'add a 0 to release so the rhel package always gets > > installed in favor of it'. > > It (probably?) would not hurt to have the epel > repos have a higher cost in the repo config > to discourage choosing the epel package over > the rhel package (if all things are equal, but > of course, they are not always equal). > > For some specific cases where I needed to > build the -devel package in a copr (until or > unless I can get the -devel packages shipped > in CRB (or equivalent)) I have manually set > the cost for the copr repos to be high so that > for a non -devel install I got the rhel versions. > I would love to know if there is a better way. > It all just seems so non-optimal. Sure, we could do that, but it's far from foolproof. Many people make their own repo files, or they might have their own weight schemes. It also doesn't help any building against things in koji. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Revisiting policy for limited arch packages?
On Thu, Jan 27, 2022 at 09:35:27PM -0800, Michel Alexandre Salim wrote: > Hi all, > > I just filed https://pagure.io/epel/issue/152 to ask if we should > revisit the policy for > https://docs.fedoraproject.org/en-US/epel/epel-packaging/#limited_arch_packages > > This policy seems very similar to the policy we agreed on in > https://pagure.io/epel/issue/134 (but haven't documented yet) which > deals with missing subpackages of two kinds: > - built but not shipped > - disabled from building > > except this time it's architectures that are either excluded from build, > or excluded from being shipped. > > Neal is trying to package LibRaw, which is built on all arches but has > been shipped only for x86_64: > > review request: https://bugzilla.redhat.com/show_bug.cgi?id=2047560 > rejected RHEL 8 request to ship LibRaw: > https://bugzilla.redhat.com/show_bug.cgi?id=1956029 > rejected RHEL 9 request: https://bugzilla.redhat.com/show_bug.cgi?id=2012272 The limited arch policy we had for epel7 had a number of problems. At first we just said 'rebuild the exact rhel version' and then we switched to 'add a 0 to release so the rhel package always gets installed in favor of it'. We also didn't have any kind of record keeping or process, so we have no idea how many of these there were, and they continued to just surprise people over and over again. ;( > Details in the ticket, but TL;DR > - why is EPEL 8 excluded from the limited arch policy, and would the > recommendation in issue 134 to use a different srpm name resolve the > issues there? I think we didn't allow it for epel8 for the above reasons. A different name might make it easier for the packager, but not for tracking or visibility. > - assuming we still disallow EPEL 8, is EPEL 9 fine? I'd say no, until we approve a new policy. > - can we merge that policy with the policy we have to write for issue > 134 anyway? Perhaps. The difference here is that people will see a epel package 'newer' than the rhel one and get it installed (in cases where rhel does ship it). Thats what the 0 leading release was supposed to help with, but it adds a bunch of complexity. > - in case of limited arch packages, should the new srpm be `-epel` or > `-extras`? It's very lightly edited from the original (see Neal's > review request) as we don't even have to disable certain subpackages: > - rename %name > - rename back all the generated packages > - add changelog > but on the other hand, in this case it's very long lived as it's not > just a matter of "we can persuade RH to ship it in CRB, it's not > supported anyway" I personally don't much care, but we should pick one. ;) > - should we come up with review guidelines for this? fedora-review seems > overkill as in most cases we don't want to diverge from the CentOS > Stream upstream anyway. At the very least we should make a requirement to add a provides or something so we can find these and see them. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting branches for epel9
On Wed, Dec 15, 2021 at 05:46:18PM +0100, Miroslav Suchý wrote: > Dne 14. 12. 21 v 17:12 Matthew Miller napsal(a): > > > > But it seems like "request an EPEL branch" should generally be either > > > > "Okay! > > > > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are > > > > the > > > > other cases? > > > As far as I know this isn't about requesting EPEL branches, as much as > > > requesting any branches by hand. If I add something to Fedora rawhide > > > and then ask for a F34 branch, the same issues can happen. Remember > > > our build infrastructure is a pile of band-aids on top of duct tape on > > > top of bungee cords. Lots of tools are written for a toolchain which > > > existed years ago and have been hacked to make it work with whatever > > > new initiative that comes into play. 'Unexpected' side effects and > > > corner cases happen all the time and the fixing of them tends to add > > > new ones. > > Sure. But also, asking people to spend a lot of their time running > > grunt-work tasks means that they have less time to fix when things break, > > let alone re-engineer away some of that tech debt. It seems like we should > > be able to automate the simple cases (adding F34 and F35 branches should be > > even easier, since we don't have the "is it in EL?" question even). > > *nod* > > So ... the question is how can I help? Can you document the check-list? I > volunteer to start writing the script. So, I suspect the epel-devel list isn't really the place to discuss this (I would think devel list + direct engagement with releng folks). That said, fedscm-admin _does_ do a bunch of checks currently. For branch requests for existing packages it checks that the requestor is a maintainer of that package and then just auto approves it. Those requests could potentially be automated (we have talked about it in releng land, but it's also a bit difficult due to all the perms you have to have). For new packages it does a bunch of checks like 'is the reviewer in the packager group', did the reviewer set 'fedora-review: +', are the requested branches valid, etc, etc https://pagure.io/fedscm-admin/blob/main/f/fedscm_admin/utils.py#_285 I can't speak for the current folks doing the processing, but I did this for 3-4 years a long time ago. When I did it I looked for a lot of things it was hard to automate checks for, like "Did this review check list a bunch of things, or just say 'ok, approved'". I would typically look closely at those and find things that were missed. I also recall several reviews that I blocked due to legal reasons where the reviewer didn't understand things correctly. That said, the volume of new packages is pretty high these days so I don't know how much extra scrutiny they are really getting. Perhaps it's time to just completely automate it and have better ways to clean up if something bad gets in. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Builds for EPEL9
On Sat, Dec 11, 2021 at 08:58:15PM +1100, Frank Crawford wrote: > Folks, > > I'm looking at building a package that currently exists in EPEL8 for > EPEL9. I have a new branch epel9 branch for my package, but when I try > to do a mock build or scratch build it fails with the error: > > Error: Error downloading packages: > Status code: 404 for > https://infrastructure.fedoraproject.org/repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesystem-11-13.el9.noarch.rpm > (IP: 38.145.60.16) > > Am I doing anything wrong here, is it just that we can't currently > build for EPEL9? builds were broken for a short time. We started syncing the centos-9-stream 'release' repos, and it accidentally deleted the existing centos-9-stream buildroot repos we have been building against. I resynced the buildroot repos and made sure it wasn't going to delete them, so it should be all back to working. If you have the non working repodata cached, you make need to do a mock --clean or the like. We still need to adjust koji to use the 'release' repos for epel9. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 9 branch?
On Sun, Dec 05, 2021 at 03:27:49AM +, Gary Buhrmaster wrote: > Now that CentOS Stream 9 is announced as > available, is there a schedule for when EPEL-9 > branches can be made, and when one can > (start to) ask others to build for EPEL-9 yes, yesterday. See the announcement: https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/ > (it would be nice if a number of the EPEL-9 > packages were preliminarily ready at the time > of the EL-9 formal release (just, perhaps, > needing a (mass) rebuild to be sure)). There's no longer any plans to mass rebuild, those packages that need a rebuild for some reason can be rebuilt by their maintainer(s). kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 29, 2021 at 09:11:48AM -0500, Neal Gompa wrote: > On Mon, Nov 29, 2021 at 9:04 AM Matthew Miller > wrote: > > > > On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote: > > > If Fedora and EPEL were to have older versions, we'd have to have a > > > dedicated CDN endpoint for them, because mirrors would seriously have > > > trouble taking it. > > > > How often would such packages be used? If we had a non-default repo > > available but not enabled by default, it could be optional to mirror and > > probably still be okay. So, we actually do have this for fedora updates today. We had to set it up to solve an issue with the updates flow and CoreOS. See the fedora-updates-archive subpackage of fedora-repos. This is hosted on amazon S3, behind cloudfront. > I suspect it would be fairly heavily used. There are significant > benefits to having those: > > * DeltaRPM would be considerably more useful In order to have deltarpms the packages would have to be available at compose time and in the same repo. > * "dnf history undo" would actually work > > We could make it non-default and tell people that rollbacks require an > --enablerepo= option, though. This would work for Fedora now with the archive repo above. I suppose we could look at setting up a similar setup with epel. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 9 Next Bodhi updates: Set lower days to stable limit?
On Fri, Nov 19, 2021 at 01:22:32PM -0500, Neal Gompa wrote: > On Fri, Nov 19, 2021 at 1:15 PM Miro Hrončok wrote: > > > > On 19. 11. 21 17:54, Troy Dawson wrote: > > > > > > > > > On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen > > <mailto:smo...@gmail.com>> wrote: > > > > > > On Fri, 19 Nov 2021 at 11:42, Miro Hrončok > > <mailto:mhron...@redhat.com>> wrote: > > > > > > > > Hello EPEL people, > > > > > > > > what do you think about setting the Bodhi days to stable limit to > > > 3 days for > > > > EPEL 9 Next (at least until RHEL 9 GA)? > > > > > > > > > > I think EPEL-9 Next being based off of Stream with its major changes > > > should have a small stable limit. 3 days sounds about right. > > > > > > > > > +1 > > > > There seem to be a consensus, do I file a ticket at infra, or does the EPSCo > > need to approve it a meeting? > > > > Please file a ticket with infra about it. wow... consensus in 1.5 hours. :) Perhaps this should be discussed at the next meeting? To allow interested parties to actually see it and comment? Anyhow, I'm personally fine with it, but note that 3 days leaves very little time for testing. One of those days is likely mirror sync/getting the update, so interested testers would need to update at least every day to make sure and not miss out. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] ansible 2.9.x EOL - 2022-05-23
Greetings. Upstream ansible has announced that they intend to EOL ansible 2.9.x on May 23rd, 2022. I intend to likewise retire the epel7 and epel8 ansible-2.9.x packages at that time. See the upstream announcement at: https://groups.google.com/g/ansible-devel/c/rx-fnf1L5e8/m/r0_UumLMBgAJ ansible-core will be available in centos stream 8/9 and rhel8/9 soon. The ansible upstream distribution (ansible-core + many many collections) will be available for Fedora soon ( https://fedoraproject.org/wiki/Changes/Ansible5 ). Once that packaging work is done we will see about also adding it to epel8/9. Users using EL7 for a control host should look at moving to EL8 before ansible 2.9 goes EOL. Thanks, kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ
On Thu, Oct 28, 2021 at 03:10:38PM -0400, Ben Cotton wrote: > Hi folks, > > In a conversation with Carl George and Troy Dawson earlier this week, > we discussed the possibility of creating a "distribution" component in > the EPEL product in Bugzilla. The idea would be that they could use it > as a place for tracking bugs and other not-tied-to-a-specific > component bugs. > > I wanted to share this more broadly for feedback and to get > suggestions on who should be the default contact. Is there a BZ > account for the EPEL SIG or should I have Carl and Troy arm wrestle > for it? :-) There's no epel bz account I am aware of, but of course we could make one. Or not. It doesn't seem worth it to me, I'd just say whoever wants to be point of contact can be. I'll probibly add myself to CC since I enjoy redirecting the misfiled bugs that will definitely appear (I do that for fedora/distribution a lot). kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9
On Thu, Sep 16, 2021 at 08:18:30PM +0200, Leon Fauster wrote: > On 16.09.21 19:47, Kevin Fenzi wrote: > > On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote: > > > I believe ansible-core includes a "dependency manager" depending on your > > > definition. The ansible-galaxy command in ansible-core can install > > > ansible > > > collections so that's you can install modules that you may need. > > > > > > It is similar in scope to pip, rubygem, cargo, or any other of the > > > language > > > package installers. > > > > > > It does not resolve based on what modules/plugins are used in your > > > playbooks but it will resolve dependencies between collection dependencies > > > if needed (and those deps were properly listed). > > > > > > I know that Nirik has plans to get newer ansible packages into epel which > > > provide an all-in-one experience by installing about 75 collections which > > > give you an experience similar what was included in ansible-2.9 but I'll > > > let him speak to how he wants to do that. > > > > Yeah. > > > > For EPEL9, I hope to: > > * Make a 'ansible' package thats the collections in upstream 'ansible', > > minus any collections that are packaged seperately (either in rhel9 or > > epel9) and a 'ansible' metapackage. > > * Have that 'ansible' metapackage require all those collections and > > ansible-core, so > > when someone does 'dnf install ansible' they get hopefully pretty > > close to what upstream ansible is now. > > > > I'm not sure if there will be problems with that yet tho. ;) > > > > I'm hoping to basically do this for Fedora 36, so I should know more > > after that. > > > That would be amazing! Is it in rawhide already? > > Thanks for your hard work. ansible-core is, but not the collections meta. Right now in rawhide 'ansible' is still 'ansible classic/2.9.x' kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9
On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote: > I believe ansible-core includes a "dependency manager" depending on your > definition. The ansible-galaxy command in ansible-core can install ansible > collections so that's you can install modules that you may need. > > It is similar in scope to pip, rubygem, cargo, or any other of the language > package installers. > > It does not resolve based on what modules/plugins are used in your > playbooks but it will resolve dependencies between collection dependencies > if needed (and those deps were properly listed). > > I know that Nirik has plans to get newer ansible packages into epel which > provide an all-in-one experience by installing about 75 collections which > give you an experience similar what was included in ansible-2.9 but I'll > let him speak to how he wants to do that. Yeah. For EPEL9, I hope to: * Make a 'ansible' package thats the collections in upstream 'ansible', minus any collections that are packaged seperately (either in rhel9 or epel9) and a 'ansible' metapackage. * Have that 'ansible' metapackage require all those collections and ansible-core, so when someone does 'dnf install ansible' they get hopefully pretty close to what upstream ansible is now. I'm not sure if there will be problems with that yet tho. ;) I'm hoping to basically do this for Fedora 36, so I should know more after that. kevin -- > > -Toshio > > On Thu, Sep 16, 2021, 7:20 AM Josh Boyer wrote: > > > On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster > > wrote: > > > > > > On 16.09.21 14:22, Josh Boyer wrote: > > > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi wrote: > > > >> > > > >> Just a heads up that ansible-core (the engine part of ansible) is now > > in > > > >> CentOS stream 9: > > > >> > > > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core > > > >> > > > >> Note that this is the engine, you will likely want to install > > > >> collections for modules and roles, etc. > > > > > > > > For those that might not have followed how Ansible has been > > > > refactored, take a look at > > > > https://www.ansible.com/blog/ansible-3.0.0-qa > > > > > > > > ansible-core is the lowest level of the ansible stack and does not > > > > include many of the modules and plugins that those using ansible > > > > engine (ansible-2.9) might be used to. As Kevin said, you will almost > > > > certainly need additional modules/plugins not provided by > > > > ansible-core. > > > > > > > > > Out of curiosity > > > > > > Does CS9 provide additional (sub)packages to extend the functionality? > > > > Not generally. ansible-core has been added to CS9 in support of > > System Roles only. This is analogous to how ansible is made available > > in RHEL 8. System Roles will include the modules/plugins it needs to > > manage the various areas of the OS, but they are not general purpose > > ansible packages. > > > > > Right now EPEL8 provide the the full stack based on ansible 2.9. > > > > > > Will EPEL9 provide such packages to provide additional modules/plugins? > > > > > > And more a ansible question: Does ansible3 provide a dependencies > > > manager as consequence now? > > > > I'll leave these for Kevin or someone else to answer in terms of EPEL 9 > > plans. > > > > josh > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] ansible-core-2.11.x in CentOS stream 9
Just a heads up that ansible-core (the engine part of ansible) is now in CentOS stream 9: https://gitlab.com/redhat/centos-stream/rpms/ansible-core Note that this is the engine, you will likely want to install collections for modules and roles, etc. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: modular bugzilla components
On Tue, Aug 24, 2021 at 09:44:12PM +0200, Miro Hrončok wrote: > On 24. 08. 21 3:40, Orion Poplawski wrote: > > Should I create an epel8 branch but then retire it just to create a > > bugzilla component? > > AFAIK this wont work. Packages retired on EPEL have the components blocked. Right. Instead we need to tech our bugzilla sync to sync EPEL modules to 'Fedora EPEL Modules/$name' like our Fedora modules are made under 'Fedora Modules/$name'. I've filed: https://pagure.io/fedora-infra/toddlers/issue/82 about this. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL8 and EPEL7: Introduce %py3_check_import - review needed
On Tue, Aug 03, 2021 at 02:57:50AM +0200, Miro Hrončok wrote: > On 03. 08. 21 2:10, Kevin Fenzi wrote: > > On Tue, Aug 03, 2021 at 01:55:52AM +0200, Miro Hrončok wrote: > > > Hello, > > > > > > I've opened the following two pull requests to introduce %py3_check_import > > > to EPEL8 and EPEL7: > > > > > > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 > > > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 > > > > > > So far, there has been no response. Is there anybody willing to merge > > > them? > > > They are manually tested, as indicated in the comments. > > > > > > When we introduce new macros to Fedora, I strive to backport them to EPELs > > > if possible, so package maintainers don't need to think "may I use this?" > > > if > > > they desire EPEL compatibility. However, I don't want to merge my own pull > > > requests to epel-rpm-macros (unless they are urgent bug fixes). > > > > I can merge them... > > Thank you! Both updates now exist: > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dfd462a782 > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e3b1cc2b6e I deliberately didn't do the epel8 build because I wanted to wait for: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/33 to get rebased, but ok. ;) > > > A meta question: Should the epel-sig group co-maintain the package? > > > > They could if desired. > > I think it is desired. Why wouldn't it be? Beats me. I don't want to speak for the epel-sig without the folks in it speaking up first. :) kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL8 and EPEL7: Introduce %py3_check_import - review needed
On Tue, Aug 03, 2021 at 01:55:52AM +0200, Miro Hrončok wrote: > Hello, > > I've opened the following two pull requests to introduce %py3_check_import > to EPEL8 and EPEL7: > > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 > > So far, there has been no response. Is there anybody willing to merge them? > They are manually tested, as indicated in the comments. > > When we introduce new macros to Fedora, I strive to backport them to EPELs > if possible, so package maintainers don't need to think "may I use this?" if > they desire EPEL compatibility. However, I don't want to merge my own pull > requests to epel-rpm-macros (unless they are urgent bug fixes). I can merge them... I just didn't notice them somehow. I guess because they were while I was on PTO and I missed them when catching up. Usually a ping in PR would let me know about them... > A meta question: Should the epel-sig group co-maintain the package? They could if desired. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Proposed change to bodhi days to stable for epel
On Thu, Jul 22, 2021 at 11:42:30AM -0700, Troy Dawson wrote: > Currently the default days to stable for EPEL is 14 days. > I believe when it was first put in it was set to that time because we > wanted things more stable and better tested. But experience has found that > if a package is going to get tested, it usually is in the first few days of > when it was built. Thus 14 days seems to be 4 days of testing, and 10 days > of sitting. Well, we don't actually know when it might be tested. ;) I think there's lots of folks out there that consume fedora updates-testing and epel updates-testing and only add negative karma when things break. If they don't break, they just ignore it... > I am proposing that we change the "days to stable" for epel to 7 days, > matching Fedora's "days to stable". > > People have asked that the epel-next "days to stable" be dropped down to 3 > days, matching Fedora when it is in it's development phase. The reasoning > is that epel-next is built off CentOS Stream, which only has 6 months at > the most before it is rolled into the next RHEL release. > > If people could give any cases for, or against these, please respond here. > The EPEL Steering Committee will have a vote at our next meeting (July 28). I guess I'm fine with changing it, but it's hard to say how much effect it will have. Perhaps we could gather some stats and revisit it after some time? kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning for EPEL9
On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote: > > This is very exciting! > > However, question here: At least for the bootstrap for RHEL 9 GA, > couldn't we use the EPEL9 next buildroot to rebuild everything once > instead of rebuilding 5 times? We can then remove the EPEL9 next > buildroot from the EPEL9 buildroot so that state doesn't persist after > everything is done. This also makes it so we can ignore the > "noautobuild" file the one time that all the content needs to be > properly seeded in EPEL9. But at the time of RHEL9.0 GA, cs9 may well have already moved on to 9.1... so that might result in stuff that doesn't work/install/depsolve with 9.0? Or am I missing something there... kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning for EPEL9
On Wed, Jul 07, 2021 at 08:28:20PM -0400, Mohan Boddu wrote: > Hello all, > > While we are already working on epel9-next enablement, there was a > discussion about how to handle epel9 when rhel9 goes GA. It is safe to > assume that a lot of the builds that are already in epel9-next at that > point of time should work on rhel9. Yeah, a lot... but not all probibly. > There were couple of ideas thrown around from doing nothing to tagging > epel9-next builds to epel9, but I think the best way to solve this is, > mass branching the packages that have epel9-next branch and create > epel9 branch from it and then running a mass rebuild without any > changes to spec files. As epel9-next builds will already have a > .el9.next dist tag, we can simply rebuild whatever there is in epel9 > branch (after branching epel9 branch from epel9-next branch). > > Since the builds are done in alphanumerical order and does not > preserve build order, we might have to run this mass rebuild a few > times (thinking of 5 times) on the failed builds to get most of the > builds. This doesn't involve changing the spec files, just > resubmitting the failed tasks. Well, it may be possible to just look at the failures after 2 passes and see whats going on. I don't think we will have thousands of epel9-next packages at that time, probibly hundreds? or even less. > Also, people who wish to opt out of this mass rebuild can add > 'noautobuild' file to the epel9-next branch beforehand, this however > does not stop from creating the epel9 branch, just the package won't > be included in the rebuild. The idea here is, if the maintainer wishes > to support epel9-next, their final goal is to maintain the package for > epel9. So, we give them a branch, but will not rebuild their package > as they might have wanted to build their packages in the correct build > order (cough cough KDE :D). > > This gives us a working epel9 with a bunch of working builds in a few > days after rhel9 GA and also we can create ftbfs bugs for those that > failed in the mass rebuild which will help maintainers to identify and > fix the issues. > > Couple of questions that need to be answered here: > 1. Is 5 times of rebuilds good enough or do we need more? I think we should do 2 and then evaluate if more would help any. Or I suppose we could go for 'steady state'. Ie, keep rebuilding only the failures until the number of them is the same between runs. At that point rebuilding them more won't help any. > 2. Do the mass rebuild builds have to go through bodhi or can we just > directly tag them for stable compose? In order to get a base of rhel9 packages out quickly, I would say just make a stable compose with them. Then, all future ones use bodhi. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: proposed recommendation - missing devel packages
On Thu, Jul 01, 2021 at 03:05:50PM -0700, Troy Dawson wrote: > I believe this is a recommendation, versus a policy. > I wanted to get people's thoughts on it, and if ya'll like it, put it in > the documentation. > > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all > packages that are built from RHEL spec files. This will also be true of > RHEL 9, and possibly future RHEL releases. These missing packages are > usually -devel packages and may impact an EPEL package build. > If your EPEL package is impacted by a missing -devel package, do the > following. > > 1 - Request the package be added to RHEL 8 and 9 CRB repository. > -- To initiate this process, please file a bug in > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9. Report > the bug against the "CentOS Stream" version of the "Red Hat Enterprise > Linux 8" and/or "Red Hat Enterprise Linux 9" product. > -- Be sure to say that it is impacting an EPEL build, and which package it > is impacting. > > 2 - Create an epel package that only has the missing packages. > -- Be prepared to maintain this package as long as it is needed. > -- It is recommended that you name it -epel --- It cannot be named (ie, the same name as the rhel source package name). > -- It is recommended that you add the epel-packaging-sig group as a > co-maintainer > -- It qualifies for an exception to the review process[1] so you can > request the repo with > --- fedpkg request-repo --exception -epel > -- If you need help building this, ask for help. We have some examples. -- keep it in sync with the RHEL version, upgrade when they do. > > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -epel > package. > > --- > Sorry, this is a little rushed. I wanted to get something out sooner, > rather than later. Looks great to me aside the nitpicks above. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: missing rhel devel packages - another proposal
On Tue, Jun 22, 2021 at 02:53:05PM -0700, Troy Dawson wrote: > Someone brought this proposal to me, I'd like to get others feedback. > > Proposal: > EPEL would make its own "devel" repo, with the missing RHEL packages, > grabbing the packages from the publicly available centos stream koji > builds.[1] For example, the missing lmdb-devel would be downloaded from > here.[2] > We would have a list of missing packages, along with their corresponding > source rpm name. Whenever that source rpm get's updated in RHEL, we would > grab the updated missing packages, and regenerate the "devel" repo. > This should work for epel8, epel8-next, epel9, epel9-next > > I realize that this will require some up front work, but I'd like to get > people's ideas about the proposal. The main concern I have is keeping it in sync... I think we would want some automation here to notify when such a package updates in rhel, otherwise while we might update it at first, it will get forgotten after a while. Outside of that on the technical side... if these are from stream they might not always work for base epel would they? kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee
On Tue, Jun 08, 2021 at 01:03:24PM -0700, Troy Dawson wrote: > It isn't just EPEL, I see this on all the calendar reminders I get from > Fedora. I wonder if there are two instances of the app running. > > Does anyone know the right place to file a bug for this? fedocal is in the process of being moved from a vm to a openshift project. I've disabled the vm version now, so hopefully that will fix this. kevin -- > > On Tue, Jun 8, 2021 at 11:48 AM Andrew C Aitchison > wrote: > > > > > I get two copies of the steering meeting reminders through > > epel-devel@lists.fedoraproject.org, > > > > One has > > Source: https://apps.fedoraproject.org/calendar/meeting/9854/ > > the other has > > Source: https://calendar.fedoraproject.org//meeting/9854/ > > > > Today's reminder is archived at > > > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/TQXND3O5WEXQ7QYOVWHBSCCW3ZLKCIT2/ > > and > > > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/IG5W4TJZWD7ZHJLT5USVNUVMGVSVLTFU/ > > > > Is it possible to send just one of these to the list ? > > > > Thanks, > > > > -- > > Andrew C. Aitchison Kendal, UK > > and...@aitchison.me.uk > > ___ > > 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 > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: fedpkg Kerberos failing for me on el7
On Mon, May 24, 2021 at 03:30:58PM +, Dave Dykstra wrote: > Is anybody else having trouble with using kerberos with fedpkg on el7? > It is working for me on el8, and it used to work for me on el7, but now > on my el7 machine any time I try to do an upload I get > Could not execute upload: Request is unauthorized. > and with fedpkg build I get > Kerberos authentication fails: unable to obtain a session > Could not execute build: Could not login to > https://koji.fedoraproject.org/kojihub > > This is with fedpkg-1.40-6.el7 installed from epel and after successfully > doing kinit d...@fedoraproject.org. Can you make a ticket at https://pagure.io/fedora-infrastructure and include the output of the failing commands with: "KRB5_TRACE=/dev/stdout" prepended (that will give debugging output). Thanks, kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: intent to retire roundcubemail in epel7
On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote: > On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen > wrote: ...snip... Here's a scratch build of 1.4.11, but I bet it won't work as many of the php-pear packages are too old. ;( https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451 > > I am wondering if we need a different way to announce reasons for this: > > > > [ ] I no longer use RHEL-7 so can not test > > [ ] I found that there are too many package updates needed that I do not > > have time for. > > [ ] The following RHEL packages are too old for this package to be updated > > [ ] The upstream is dead and I can not fix > > ... > > Or maybe instead of saying it's retiring, do Fedora's Orphaning format. > Announce they are orphaning the package, and if a package is orphaned for a > certain amount of time, and has all the orphan annoucements, it get's > removed. > But I do like your checkbox way for announcing the reasons for > retiring/orphaning. Well, thats what goes in the dead.package file when the package is retired. :) I was just wanting to stop shipping a known vulnerable package and get it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't actually going to work, but happy for someone to prove me wrong. I don't really have the time to investigate further myself. So, I will orphan it now, if no one takes it in a while, I will retire it then? kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: intent to retire roundcubemail in epel7
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote: > > > On 17/05/2021 19:32, Kevin Fenzi wrote: > > roundcubemail in epel7 is very old at this point, and can never be > > upgraded because epel7 has too old a php. > > > > It's got 10 CVEs open against it. > > > > I'm planning on retiring it later today. > > > > I can mail epel-announce about it... > > > > kevin > > > What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 - > https://roundcube.net/about/#features. Current PHP is php-5.4.16-48. There > is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/. Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of the CVE's... but that leaves 8 more. I don't really think they are going to be doing any more 1.2.x releases now that 1.5 is almost out. Sorry I wasn't being exact there, it's not php itself, it's various php related things. Like php-pear version 1.10.1 is needed and rhel7 has 1.9.4 and so on. If you would like to try and get 1.4.x working on epel7 that would be great! Of course the 1.2 -> 1.4 jump would be pretty major for users, but such things happen. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] intent to retire roundcubemail in epel7
roundcubemail in epel7 is very old at this point, and can never be upgraded because epel7 has too old a php. It's got 10 CVEs open against it. I'm planning on retiring it later today. I can mail epel-announce about it... kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Fwd: fmt soname bump in EPEL7
On Tue, May 11, 2021 at 09:35:40PM +0200, Leon Fauster wrote: > On 11.05.21 14:02, Christoph Karl wrote: > > Hi! > > > > On 11.05.21 at 12:30 Leon Fauster wrote: > > > While reading this I noticed that the recent fluidsynth-libs update > > > also introduced a soname bump. Affected EPEL packages > > > - audacious-plugins-amidi > > > - qsynth > > > > Yes, this was me. I am already trying to clean up this. > > > > > BTW: As also stated here: > > https://lists.centos.org/pipermail/centos-devel/2021-May/076864.html > > previous releases (multiple) are not kept but I was assuming that its > possible to downgrade at least to ONE version before but it isn't. > > - Was there ever a downgrade option in EPEL? no. > CentOS Stream suffered from that but covered yet: > > https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html > > Would it not be beneficially? Especially for such cases like these ... There's a number of reasons we haven't implemented this over the years: tooling isn't setup for it easily, desire to not keep publishing insecure/broken/vulnerable packages, etc. We could revist it again, but it's not something that would change quickly. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Intent to update nginx to 1.20.0
On Tue, Apr 20, 2021 at 11:01:14PM -0400, Felix Kaechele wrote: > Hi there, > > I think this has been discussed at committee meetings before: nginx's > procedure of immediately dropping a release series when a new one hits the > stable branches is essentially forcing us to upgrade along with it, unless > someone is willing to backport patches. > > I personally am not willing to do backports as I do not use EL7 at this > point and only continue maintaining the package as a courtesy to the > community. > > I therefor intend to make the following changes to the nginx package in > EPEL7: > - Update to 1.20.0 > - build against OpenSSL 1.1 to enable TLS1.3 support > > Do I require additional permission do move forward with this in this manner? > There should not be any breaking changes or incompatible changes to config > syntax. But I'll admit that I do not have complex config scenarios as > testcases. > > EPEL8 is not affected as nginx doesn't have an EPEL build for EL8. It is > maintained upstream. > There are, however, modules with certain streams (1.18 and mainline, for > example) available from EPEL. I think this sounds fine, but you might want to send a note to 'epel-annou...@lists.fedoraproject.org' once its in updates-testing and again when it goes to stable. kevin signature.asc Description: 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Proposal: EPEL9 timeline
On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote: > There is a little nuance here. In order to get the repository going, we had > to 'mass-branch' about 40 or so packages. fedpkg and some other items > require quite a few packages which all have to be done at once. Without > those you can't build anything else to put into EPEL... so I would say that > EPEL is the specific set of packages in order to get a minimal repository > working in the Fedora Build System. Everything else is just extras people > add to it. That is an excellent point. Perhaps we should try and identify those packages and see if we can just add epel-packagers sig to all of them? Do we have any record of those? kevin signature.asc Description: 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://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: EPEL9 timeline
Overall this seems fine to me, a few nitpicks inline... On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote: > This is a proposal. It's mainly writing down what I think most of us > agreed on at last weeks EPEL Steering Committee meeting. Feel free to > continue to discuss and/or have ideas. > I've been asked by a couple places what the plans were, so I'm writing it > here. > > Overall Plan: > - epel-next is an epel branch that is built against CentOS Stream. epel-next > only has the packages that would be incompatible with released RHEL > builds, or if an EPEL maintainer is updating a package that will only > be released to regular EPEL at the next RHEL release. > - We plan on creating epel9-next when CentOS 9 Stream has a public > repository. We plan on using the EPEL Packaging SIG to populate it > early with common packages, although any EPEL package maintainers can > add their packages whenever they want. This part I am unsure of. What are 'common packages' ? We should make sure and ask maintainers to branch and maintain packages they want for this, but I think it would be odd to just do it without them being in the loop. We never never 'mass branched' things in the past. EPEL isn't a specific set of packages, it's packages maintainers want to maintain. That said, if there's packages of interest where the maintainers are not interested in epel, the epel sig should definitely branch and maintain those. > - We plan on creating normal EPEL9 after the RHEL 9.0 GA release, just > like normal. No sooner. All epel9-next packages will be rebuilt on > EPEL9. They will not be "tagged over". This rebuild should be by whoever > built it in epel9-next. This I am also not a fan of. What if you make a epel9-next branch for something, but you don't (for whatever reason) want to put it in epel9? I think we should just open new epel9 branches at epel9 time and maintaienrs can branch and build them (again, if people don't care the epel packagers sig can do all the ones they manage right up front). > > Approximate Timelines: > - All of these timelines depend on (A) CentOS 9 Stream / RHEL9 actual dates > and (B) availability of EPEL volunteers. Please note, EPEL is > completely volunteers, and sometimes "day jobs" make EPEL timelines slip. > - epel9-next - July 2021 > -- CentOS 9 Stream should have a public repository in April 2021 > -- Should take about 3 months to setup > - epel9 - October 2022 > -- RHEL 9.0 should be released around May 2022 > -- Should take about 5 months to setup > -- Note: It takes longer because it has to deal with getting packages > from an internal RHEL repo and all the complications of doing that. > > EPEL Packaging SIG > - We hope to utilize the EPEL Packaging SIG as much as possible. > - This might be as simple as having them rebuild a epel9-next package > on epel9, or possibly maintaining a package when the Fedora packager > does not want to do EPEL. I think simple is better here. > - More details will be coming, but we hope the SIG will help get alot > of the most used EPEL packages into EPEL9 as soon as possible. Thanks for writing all this up! kevin signature.asc Description: 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://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: EPEL9 - thoughts and timings
On Fri, Jan 29, 2021 at 01:46:56PM -0800, Troy Dawson wrote: > On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar wrote: > > > > On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote: > > > I think that could be workable, but I'll toss out another proposal: > > > > > > As soon as centos 9 stream exists, we create epel9-playground and allow > > > people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as > > > usual and epel9-next and point epel9-next to build against stream and > > > playground to build against rhel9. > > > > > Do you know what CentOS 9 Stream will look like between its first > > availability > > and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then > > switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest > > incompatibilities as the build root would regress. To be clear if the question was directed at me: I have no idea. ;) > Very good question Petr, and thanks for asking it. > I asked internally about this. > There will be a set time [1] when RHEL 9.0.0 release will be branched, > and all the final stabilizing stuff will happen internally. > At that point, CentOS 9 Stream will be on the 9.1.0 release, and any > changes to it will not be in the 9.0.0 GA. > I don't know when that point in time is, I haven't figured it out yet. > But my educated guess is 3 months before GA, if I'm wrong, then I > don't think more than 6 months before GA. > > So, that gives us something to consider. Do we think that 3 to 6 > months of possible changes will affect us too much? > Troy > > [1] - I wasn't given a date, just X weeks into the schedule. We talked about this in the meeting yesterday some. Pondering on it I think the best was forward would be: * as soon as centos 9 stream exists and is consumable, we setup things and start allowing epel9-next branches (only) for things. We could do this as we plan for epel8-next (ie, bodhi, updates/updates-testing) or we could decide thats too much overhead and just do a daily compose of everything. The first option would be more up-front work, but then we don't have to change it later. * as soon as rhel9 GA is available and consumable, we setup things and start allowing epel9 branches. We also send a note to all 'epel9-next' maintainers that epel9 is available and that they should request that and build there. If we did epel9-next as a 'rawhide style daily compose' we would switch it to bodhi/updates-testing then. I'm not sure what to do about rhel9-beta. My first thought is to ignore it and tell people to use epel9-next with it, and consider following stream to get updates. As for epel9-playground... I'm kind of coming to the idea that it's not that useful really and we shouldn't make one for 9. SO, I guess this is all just the orig proposal. ;) kevin signature.asc Description: 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://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: EPEL9 - thoughts and timings
On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote: > As we are getting closer to the F34 branching, which means we are > getting closer to CentOS 9 Stream, which will eventually be turned > into RHEL9 Beta, and then RHEL9 release. Now seems like a good time > to get ideas flowing about EPEL9. > > I'm just throwing ideas around. Nothing I'm saying here is even close > to policy or a final plan. If people have other ideas, feel free to > say them. > > epel8-next is getting closer and closer to being in place. > To me it seems logical to create a epel9-next, pointing at the CentOS > 9 Stream (when it comes). It would need the same setting up as > epel8-next, all the steps would be the same other than the name and > where it points for it's repo. > > We could also setup some type of signup board for if maintainers want > the EPEL Packaging SIG to automatically bring their packages over. > > With epel9-next in place, and good set of EPEL9 packages in it, users > would be able to test RHEL9 much better in it's beta phase. > > Also, it would take alot of pressure off when we start getting regular > EPEL9 setup. If it takes a month or two, people wouldn't be as > concerned, because they could always just grab the packages from > epel9-next. I think that could be workable, but I'll toss out another proposal: As soon as centos 9 stream exists, we create epel9-playground and allow people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as usual and epel9-next and point epel9-next to build against stream and playground to build against rhel9. The advantages of that would be that epel9-playground is more rawhide like... it would compose every night and there's no bodhi overhead. Of course to be confusing we could just treat epel9-stream that way until GA too I suppose. In any case as soon as centos 9 stream is ready, I think it would indeed be a great idea to start allowing epel builds against it one way or another. :) kevin signature.asc Description: 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://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: EPEL7 python3/python36 standardization
On Thu, Jan 21, 2021 at 12:19:39AM -0600, Carl George wrote:
> Howdy folks,
>
> RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> EPEL7 contains Python 3.6 packages using both the python3 and python36
> prefixes. Thanks to the foresight and preparation work of the Red Hat
> Python Maintenance team, these work interchangeably when using the
> %python_provide macro. However the situation is still confusing for
> packagers and users. We never formalized guidelines on which prefix
> to use. I would like to change that. I propose that we standardize
> on the python3 prefix to match RHEL7 packages and document in EPEL
> guidelines that maintainers SHOULD use the python3 prefix.
>
> Transitioning packages is straightforward. Packages using a
> python%{python3_pkgversion}- subpackage can simply rename it to
> python3-. If the top level package is already python3-,
> then the subpackage can be converted into the top level package. In
> both cases, `%python_provide python3-` handles the necessary
> provides and obsoletes. This work doesn't need to happen all at once,
> and maintainers can opt in as they have time. We already have a mix
> of prefixes, this is just about nudging towards python3 as the correct
> prefix.
>
> Please share your feedback, and I'll present this proposal and the
> feedback to the EPEL Steering Committee.
Seems like anoying churn to change them, but I guess standardizing is
good. Perhaps we could generate a list of python36 and python34
subpackages that need changing and make a tracker bug and the
epel-packagers sig could drive forward filing bugs/pr's/just fixing
these?
For epel8: I see there's one python38 package in epel8 ( python38-radicale3 )
do we want to also standardize there also to python3-name? Since there's
multiple python stacks there we really might have need for being more
specific there, so that might be fine, but we should probibly note it.
kevin
signature.asc
Description: 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://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 for RHEL8 missing -devel packages
On Sun, Dec 13, 2020 at 10:37:49AM -0700, Orion Poplawski wrote: > On 12/11/20 5:04 PM, Miro Hrončok wrote: > > On 12/12/20 12:12 AM, Troy Dawson wrote: > > > There is also a problem if a missing package has been specifically > > > blocked by a module. I think libuv-devel is this way. > > > > If that happens, wouldn't it be blocked in both scenarios > > (module+grobisplitter+tagging and devel-only-component)? Or would > > grobisplitter put them in an additional repo with module_hotfixes=yes? > > > > If that's the case, it might be possible to create a separate repo with > > such packages only and manually tag them there. E.g. after a build I'd > > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and > > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 > > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this > > proposal, it requires some work (on infra to set up this extra repo and > > on packagers to remember to do the tagging, but that still sounds like > > less work than the grobisplitter proposal for both groups). > > Is there any easy way to tell if a package is explicitly blocked vs just not > being present. You can ask koji: koji list-pkgs --show-blocked --package whatever and it will tell you what tags it's blocked in with [BLOCKED] 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] Re: Epel 8 (and 9) build against what?
On Tue, Dec 15, 2020 at 11:00:15AM +0100, Miroslav Suchý wrote: > Regarding the recent announcement of CentOS 8 flipping to CentOS Stream - > What will be the configs for building EPEL 8? > I mean mock configs? And I ask as Mock maintainer - because I have no idea. I don't think you need to panic and try and decide something now. I'd stick with the way it is now, and perhaps revisit it in 6months or so when things might be more clear. > Are we going to build EPEL 8 against CentOS stream? What will happen when > CentOS stream flip to RHEL 9 based content > > https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F > ? There will still be centos8 stream for a year... kevin signature.asc Description: 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://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: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On Wed, Dec 09, 2020 at 11:17:46AM +0100, Miro Hrončok wrote: > Hello, > > wrt https://blog.centos.org/2020/12/future-is-centos-stream/ > > Since EPEL 8 is for RHEL 8 and EPEL Next 8 is for CentOS Stream 8, I assumed > we will continue to use CentOS Linux 8 for local mock (and Copr) builds of > EPEL 8 packages. The same for EPEL 9. > > However, since CentOS Linux 8 (and 9!) will be no more, do we have some > ideas how to handle this? Do we require all EPEL contributors to obtain the > developer RHEL subscription (seems like a huge pain)? Do we switch to Oracle > Linux (only half joking)? Do we try to fight this decision (however I am > afraid I've exhausted my fight capacity on different decisions)? > > Not looking for specific answers yet, this is more a discussion kick off. I guess this is a decision for the mock/copr maintainers in the end? but yeah, not sure what the best way is. We do have some time... kevin signature.asc Description: 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://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: Broken EPEL7 builds
On Sun, Dec 06, 2020 at 07:51:13PM +0100, Antonio T. sagitter wrote: > https://koji.fedoraproject.org/koji/taskinfo?taskID=56903884 > > I opened a ticket about: > https://pagure.io/releng/issue/9887 Should be fixed now. Please reopen the ticket if you see any further issues... kevin signature.asc Description: 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://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: Fedpkg wrote "Create package.cfg to specify build targets to build. "
On Tue, Dec 01, 2020 at 06:18:42PM +, Sérgio Basto wrote: > Hi , > Fedpkg wrote "Create package.cfg to specify build targets to build. " > , where I can read more about this subject , should I add package.cfg > to the package ? can package.cfg be in master branch and in Fedora > branches ? etc . Theres no need to do anything. This is a remnant from the way that epel8-playground used to work (it made a package.cfg in epel8 branch and that caused 'fedpkg build' to build for _both_ epel8 and epel8-playground). epel8-playground now just inherits from epel8 and is only made if requested. fedpkg/fedscmadm just needs to finish adjusting and no longer make the package.cfg file. kevin signature.asc Description: 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://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: Fast-moving packages in EPEL
On Tue, Oct 13, 2020 at 12:14:24PM +0200, Leon Fauster wrote: > Am 13.10.20 um 10:12 schrieb Christopher Engelhard: > > On 12.10.20 10:49, Leon Fauster wrote: > > > Not sure but IIRC EPEL should not depend on software collections ...? > > > > Can someone confirm that? If the package can't depend on php7.2+, then > > the question of how to deal with EPEL7 is moot. > > > > My recall was this > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/ It's changed a bit since then. We now allow scls if: * They only need to be used at build time (ie, the rpms produced do not require users to install/enable any scls) * They are approved by the epel steering comittee. So far we have only enabled devtoolset. (so for example, chromium uses devtoolset to build with a newer gcc, but does not require users to install or enable anything to use it). In the case of php, this would likely not work because it would require users to install/enable php to get the webserver module or cmd line. kevin signature.asc Description: 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://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: Fast-moving packages in EPEL
On Sun, Oct 11, 2020 at 07:47:22AM +0200, Christopher Engelhard wrote: > Hi, > the nextcloud server package is currently stuck at ancient version 10 > (current is 20) in EPEL7 (It's not (yet) available EPEL8 repos). > > I'd like to fix that, but > > - upstream releases a new version roughly every 4 months > - they support them only for roughly 1 year (officially it's "at least 8 > months") > - nextcloud receives A LOT of bug- and CVE-fixes, and there is no way > I'll be able to backport all of those, so staying on an older version > after upstream stopped support is not really an option. > > So, should this still be in EPEL even though it would receive major > version updates or is it better to retire it from EPEL? > > I suspect that EPEL users would probably prefer to run it from > upstream's containers anyways, so retiring might make more sense, but > I'm open either way. There's a number of options: * Keep in epel - As you note though this is major upgrades and it's not something people expect. * It doesn't help you any with epel7, but for 8 you could put it in epel8-playground. There's much more expectation of packages that have major upgrades and change things, so people who consume it might be fine with that. * You could try a module (again does not help with epel7). This should work except if you need any non default modules. * You could just put it in a copr (this would work for both epel7 and epel8). It's not as discoverable there, but this might be a good solution. kevin signature.asc Description: 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://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 Next
On Mon, Oct 05, 2020 at 11:08:27AM -0500, Carl George wrote: > Thanks for looking over the plan Kevin. > > 1. I wasn't planning any changes for bugzilla. I think it's appropriate for > the bug reports to be filed against the epel8 component. Typically there > should be an epel8 branch already when an epel8-next branch is requested. The > only exception I can imagine is if a package has a dependency on a package > that > is in CentOS Stream but isn't in a RHEL GA release yet. Even then, it would > only be a temporary situation, because within six months that package would > make it into RHEL and then the package should be built in epel8, not > epel8-next. Do you think it would be worthwhile for fedscm-admin to enforce a > requirement of an epel8 branch before allowing the creation of an epel8-next > branch? I think if it's easy/possible to make it reject epel8-next and epel8-playground branches when a package doesn't have a epel8 branch that would be nice. I am not sure this is required however, as you note it should be a pretty rare case... > > 2. I'm perfectly fine waiting until after F33 is done. That makes lots of > sense. Cool. Thanks kevin -- > > On Sat, Oct 3, 2020 at 12:07 PM Kevin Fenzi wrote: > > > > On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote: > > > Here is my rough outline of the steps required to implement this proposal. > > > I imagine things would happen roughly in this order, but some things could > > > probably take place in parallel. > > > > > > 1. EPEL Steering Committee approves the proposal > > > 2. koji changes: > > > - create CentOS Stream 8 external repo > > > - create epel8-next build target (inheriting from epel8) > > > - dist macro override for that target > > > 3. create PDC entries > > > 4. update fedscm-admin with branch SLAs > > > 5. configure dist-git to allow branch name > > > 6. update pungi config > > > 7. add epel-next-repo subpackage to epel-release > > > 8. add epel8-next release in bodhi > > > 9. document in the wiki > > > 10. announcement email > > > > > > Please let me know if I'm missing anything. > > > > Looks pretty good to me, but two things: > > > > 1. I assume (but good to ask) that we are not going to change anything > > in bugzilla? ie, bug reports should just go against the epel component? > > Of course now that playground is 'seperate' and next will also be, would > > we ever have cases where we have a component without epel branch, but > > with playground and/or next? And what would we do for bugs there? > > > > 2. We are heading into final freeze for Fedora 33 next tuesday, so not > > sure how much will get done until f33 is out the door. Is it ok to do > > this after? Some of it could be done with freeze breaks and such, but > > might be easier just to do it all at once after f33 freeze is over? > > > > Thanks much for putting this together! > > > > kevin > > -- > > > > > > > > On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > > > > > > > I agree, using .el8.next for the dist macro makes the most sense. This > > > > will > > > > enable maintainers to use a similar workflow to Fedora branches, where > > > > older > > > > branches can be fast forwarded, and the same commit can be built for > > > > different targets but still have different NVRs in Koji. Here is an > > > > example > > > > workflow for a fictional foo package that already exists in Fedora. > > > > > > > > - request epel8 branch > > > > - merge master branch to epel8 branch > > > > - build epel8 branch, resulting in foo-1-1.el8 > > > > - realize it won't install on CentOS Stream due to a library difference > > > > - request epel8-next branch > > > > - merge epel8 branch to epel8-next branch > > > > - build epel8-next branch, resulting in foo-1-1.el8.next > > > > > > > > After the next RHEL 8 minor release (when that library difference > > > > affects > > > > everyone), the maintainer can increment the release on the epel8 branch > > > > and > > > > proceed as usual. > > > > > > > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > > > > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > > > > At the EPEL Steering Committee last week, we had an extensive > > > > > > di
[EPEL-devel] Re: [EPEL7] Celery stack update & Python 3 enablement
On Sun, Oct 04, 2020 at 09:56:33AM +0200, Frantisek Zatloukal wrote: > Hi, > > I've recently begun maintaining celery stack in Fedora and Fedora EPEL. > > I am in process of enabling python 3 builds of celery for EPEL 7, testing > copr (in working state with at least redis backend) is available here for > anyone interested: > https://copr.fedorainfracloud.org/coprs/frantisekz/celery_epel_py3/ > > I am also planning to update all parts of celery to the latest minor > versions while I am making packaging changes. python-(vine, amqp, celery) > are all fine with only tiny changes there, however, python-kombu is a > little bit more complicated. > > Current kombu version in EPEL 7 is borked [0] and removed by the upstream > from pypi [1]. Long story short, they've accidentally released master > branch as kombu-4.2.2 in the past and that bad release is part of EPEL 7. I > can leave it as it is, or move to a proper, kombu 4.3 release. > > From what I understand, 3rd party applications/scripts/whatever should be > using celery and not kombu directly. Current celery version present in > EPEL 7 works just fine with kombu 4.3 [2], I did some testing and haven't > hit any issues , it doesn't seem 3rd party applications using celery would > break/need any changes for newer kombu. > > What are your opinions about this? How big are the changes between 4.2.2 and 4.3? ie, if someone is using 4.2.2 and you update epel7, how much will they need to adjust? I would lean toward doing the upgrade, but good to know what affect it might have, and if it's going to require people to make changes, announce in advance and leave in testing extra long. kevin signature.asc Description: 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://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 Next
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote: > Here is my rough outline of the steps required to implement this proposal. > I imagine things would happen roughly in this order, but some things could > probably take place in parallel. > > 1. EPEL Steering Committee approves the proposal > 2. koji changes: > - create CentOS Stream 8 external repo > - create epel8-next build target (inheriting from epel8) > - dist macro override for that target > 3. create PDC entries > 4. update fedscm-admin with branch SLAs > 5. configure dist-git to allow branch name > 6. update pungi config > 7. add epel-next-repo subpackage to epel-release > 8. add epel8-next release in bodhi > 9. document in the wiki > 10. announcement email > > Please let me know if I'm missing anything. Looks pretty good to me, but two things: 1. I assume (but good to ask) that we are not going to change anything in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there? 2. We are heading into final freeze for Fedora 33 next tuesday, so not sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over? Thanks much for putting this together! kevin -- > > On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > > > I agree, using .el8.next for the dist macro makes the most sense. This will > > enable maintainers to use a similar workflow to Fedora branches, where older > > branches can be fast forwarded, and the same commit can be built for > > different targets but still have different NVRs in Koji. Here is an example > > workflow for a fictional foo package that already exists in Fedora. > > > > - request epel8 branch > > - merge master branch to epel8 branch > > - build epel8 branch, resulting in foo-1-1.el8 > > - realize it won't install on CentOS Stream due to a library difference > > - request epel8-next branch > > - merge epel8 branch to epel8-next branch > > - build epel8-next branch, resulting in foo-1-1.el8.next > > > > After the next RHEL 8 minor release (when that library difference affects > > everyone), the maintainer can increment the release on the epel8 branch and > > proceed as usual. > > > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > > At the EPEL Steering Committee last week, we had an extensive > > > > discussion of > > > > this proposal, specifically focused on how to handle the dist macro. I > > > > believe these are the possible choices. > > > > > > > > * keep dist the same as epel8 (.el8) > > > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using > > > > .el8 for > > > > dist. It would make sense to continue using the same dist for EPEL > > > > Next. > > > > However, this would put a little more work on packagers. They would > > > > not be > > > > able to build the same commit for both EPEL and EPEL Next because the > > > > NVR > > > > will conflict in Koji. In simple rebuild situations, this is not a > > > > problem > > > > because at a minimum the release will be higher. But if a packager > > > > wanted > > > > to update the package in both EPEL and EPEL Next, they will need to > > > > first > > > > update and build it in EPEL, then bump the release and build it in EPEL > > > > Next. This isn't ideal, but isn't terrible either, and can be partially > > > > mitigated by good documentation around EPEL Next workflows. > > > > > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > > > > > In EPEL Next we could define dist to a string that RPM evaluates higher > > > > than > > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches > > > > to be > > > > in sync and the same commit could be built for both targets. The higher > > > > dist would ensure the upgrade path works. > > > > > > I think this makes the most sense and will help packages workflows the > > > best. > > > > > > kevin > > > _
[EPEL-devel] Re: Retire mongodb from EPEL7
On Tue, Sep 22, 2020 at 06:33:49AM -0700, Troy Dawson wrote: > On Tue, Sep 22, 2020 at 5:28 AM Andrew C Aitchison > wrote: > > > > On Tue, 22 Sep 2020, Patrik Novotny wrote: > > > > > Hi, > > > > > > there's intend to retire the mongodb package from EPEL7 [1]. As for > > > the MongoDB license change[2], we are not able to backport patches, > > > which leaves us shipping basically unmaintained release. > > > > > > Since that is generally not a good idea, we are deciding on retiring > > > the package. > > > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1855725 > > > [2] > > > https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server > > > > I received this announcement on the epel-devel list, but not via > > epel-annou...@lists.fedoraproject.org and I do not see it in the archive at > > https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/ > > (although the headers on the epel-devel copy I received do suggest it was > > sent to epel-announce). > > > epel-announce is a moderated mailing list. Sometimes it is quick, > sometimes it takes a day or two to get through. I get to moderation requests as soon as I can, but not while I am asleep. :) kevin signature.asc Description: 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://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: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 11:28:10AM -0700, Troy Dawson wrote: > On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > > ...snip... > > > > > > When a maintainer is done with their package in playground, they must > > > untag all builds of it out of epel-playground. We do not want > > > epel-playground cluttered with old test packages. Done means either > > > the package has been moved to regular EPEL, and / or the maintainer no > > > longer wants to play and test in epel-playground. Untagging all > > > builds of a package is currently done via a release engineering > > > ticket. > > > > This puts more work on releng, but I am not sure how often it will come > > up. We could also create a 'epel-sig' permission and grant everyone in > > that group permissions to untag from playground? > > > > Otherwise, looks good to me. > > > > kevin > > If the maintainer could do it themselves, I'm ok with that. But > currently, I don't think they can. They cannot. We would need to create a new koji permission and add people to it, or just have releng do it. > If we can get something better than rel-eng, I'm all for it. But as > far as I know, that's what we currently have to do. > We can update it when we get something better in place. Well, I think it might be worthwhile to add a permission and a small group of people who can do it, then they could process the releng tickets too. kevin signature.asc Description: 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://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 Next
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > At the EPEL Steering Committee last week, we had an extensive discussion of > this proposal, specifically focused on how to handle the dist macro. I > believe these are the possible choices. > > * keep dist the same as epel8 (.el8) > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for > dist. It would make sense to continue using the same dist for EPEL Next. > However, this would put a little more work on packagers. They would not be > able to build the same commit for both EPEL and EPEL Next because the NVR > will conflict in Koji. In simple rebuild situations, this is not a problem > because at a minimum the release will be higher. But if a packager wanted > to update the package in both EPEL and EPEL Next, they will need to first > update and build it in EPEL, then bump the release and build it in EPEL > Next. This isn't ideal, but isn't terrible either, and can be partially > mitigated by good documentation around EPEL Next workflows. > > * modify dist to always be higher than epel8 (.el8.next or similar) > > In EPEL Next we could define dist to a string that RPM evaluates higher than > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be > in sync and the same commit could be built for both targets. The higher > dist would ensure the upgrade path works. I think this makes the most sense and will help packages workflows the best. kevin signature.asc Description: 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://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: Proposed EPEL Playground Documentation
On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: ...snip... > > When a maintainer is done with their package in playground, they must > untag all builds of it out of epel-playground. We do not want > epel-playground cluttered with old test packages. Done means either > the package has been moved to regular EPEL, and / or the maintainer no > longer wants to play and test in epel-playground. Untagging all > builds of a package is currently done via a release engineering > ticket. This puts more work on releng, but I am not sure how often it will come up. We could also create a 'epel-sig' permission and grant everyone in that group permissions to untag from playground? Otherwise, looks good to me. kevin signature.asc Description: 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://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: EPEL playground && mock builds against released repos
On Tue, Sep 15, 2020 at 10:53:10AM +0200, Pavel Raiskup wrote: > Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can > reproduce builds locally with mock. Initially the configuration worked, but > it > has been failing for quite some time now. Dnf isn't able to --installroot: > > No matches found for the following disable plugin patterns: local, > spacewalk > CentOS-8 - Base 12 MB/s | 2.2 MB > 00:00 > CentOS-8 - AppStream 21 MB/s | 5.8 MB > 00:00 > CentOS-8 - PowerTools11 MB/s | 1.9 MB > 00:00 > CentOS-8 - Extras33 kB/s | 7.3 kB > 00:00 > Extra Packages for Enterprise Linux 8 - Playgro 15 MB/s | 6.1 MB > 00:00 > Error: > Problem: conflicting requests > - nothing provides fpc-srpm-macros needed by > epel-rpm-macros-8-16.playground.noarch > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' > to use not only best candidate packages) > > I'm not sure we miss something there, but it looks like the shipped chroot is > broken. The mock bug report [1], and fpc-srpm-macros report [2]. Yeah, looks like the fpc-srpm-macros build for epel8-playground failed. I fired off a build: https://koji.fedoraproject.org/koji/taskinfo?taskID=51522174 but also there's no epel8-playground branch for the package. > Local mock builds are done against CentOS repositories, so I'm not sure where > to > report this problem, if here or to CentOS (but starting here as I believe that > fpc-srpm-macros should go to the playground repo). > > Also another question is whether we can fix the chroot, or not (dropping the > config file from mock-core-configs is an option, too). We should be able to fix it. Once the above lands in the buildroot it should be working again. kevin signature.asc Description: 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://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: Proposing an EPEL packaging SIG
On Mon, Sep 14, 2020 at 09:42:36AM -0700, Michel Alexandre Salim wrote: > I wonder if these are two separate concerns though? I agree that being > able to indicate a package should always be branched would be great, > but... epel-sig / epel-wranglers might not find a package relevant in a > new EL release (e.g. say we care about neovim, and want to carry it by > default in new releases, and thus we also care about some of its > dependencies that are not in (RH)EL core -- but the set of dependencies > we care about in EPEL7 != the set in EPEL8 etc. > > ^ if that seems explicit that's because it, uh, is from personal > experience. Yeah, I agree, not everything will want to auto branch... and in fact this will change from time to time as new versions come out, things are retired, etc. > Maybe package.cfg might be where such a metadata live? e.g. if the > epel8 branch of the package has a package.cfg that says "branch for > next release" it gets branched for epel9 -- and inherits that > package.cfg by default. If a package gets opted in once and at some > point is no longer needed in the next epel, just delete that. I don't like that idea... I've heard many many complaints from people about package.cfg files and them messing up merges. I would think at the pagure/src.fp.o level might be better... or if not, then just a simple 'alwaysepelbranch' file or something thats ignored except for this use. > This might also suggest we want to have a delay before automatically > branching so EPEL SIG / Wranglers have time to adjust that package.cfg > after testing the next EL beta. Sure, should be a deliberate process. snip > Hmm. So right now (correct me if I'm wrong), it seems that only the > main admin for a package can override the bugzilla assignee? yeah, I think thats indeed the case. > I'm not sure about how this part would work yet. If at the beginning we > try this out with manual infra ticket, I could imagine the EPEL SIG > member that requests EPEL-SIG comaintainership for a package should ask > the main admin to make them the EPEL assignee, or if it goes through an > infra ticket, ask for infra to make that change? I suppose. I am not keen on adding more infrastructure tickets. If we can do a workflow that consolidates requests/can be automated that would be much better IMHO. > > > One deviation we might want to have from how Python SIG works is... > > > we > > > probably don't want to encourage packagers to add this EPEL SIG as > > > a > > > comaintainer preemptively, but only as needed. > > > > That would defeat the purpose of using epel-sig packages as 'always > > branch' wouldn't it? > > > Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG > has commit access requesting a new branch is not a significant delay > anyway). So 'branch for next' in package.cfg might be a better solution > all around. > > How much tooling change would we need to get collaborators the ability > to request branches if the branch name matches their whitelist, > incidentally? Not sure. Thats a question for Pingou. :) > > The other hazard if that different maintainers have different > > workflows > > and epel-sig folks would need to adjust to those. ie, some people > > want > > master to have epel conditionals and merge back to epel branches, > > some > > don't want that at all. I wonder if it wouldn't make sense to have > > some > > way to indicate to people what workflow is in effect for the package > > (I > > guess spec file comments?) > > > Maybe spec file comments as well as only granting collaborator > (whitelisting epel* branches) instead of commit / admin access if they > don't want EPEL conditionals? yeah. kevin signature.asc Description: 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://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: Proposing an EPEL packaging SIG
On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote: ...snip... > > EPEL packages are maintained in dist-git as additional branches on > Fedora packages; however, unlike with Fedora releases, where by default > a package gets branched for any new Fedora release, EPEL branches are > only created if one of the package maintainers request it (it's opt- > in). > > The rationale is that many Fedora packagers do not specifically care > about EL, and with their long release cycles the maintenance burden is > higher (e.g. upgrading to fix a security vulnerability might not be > possible if the newer fixed version has unmet dependencies, so > backporting the fix might be required). EL is more often used server > side too, so the average Fedora packager is not expected to be an EL > user. I'll add that in addtion to some maintainers not wanting to maintain their fedora packages also in epel, the timelines involved sometimes make it so a package that was branched/maintained in epelX, makes no sense in epelY. ie, Xfce 4.14 would be fine now, but in 3 years, 4.16 or whatever would make more sense and the package set may well not be the same. > This poses a problem for those of us who rely on packages in EPEL -- > e.g. Fedora Infrastructure, and many corporate deployments. Right now > the process is as such: > > * An org starts rolling out the new version of EL > * It turns out a given package is not available in EPEL > * Bug filed requesting that package be branched and built > * Worst case scenario, no response and we need to use the non- > responsive maintainer flow > * That package might have other unmet dependencies, so repeat this > cycle several times > * Wait for each of these packages to go through the update system > * For organizations that have their own internal mirrors, they now need > to sync the new packages I wonder... could we somehow let maintainers indicate "I want my package branched for the next epel as soon as it's available"? I suppose in part thats what adding epel-sig would do? With the addition of 'epel-sig should build by packages as soon as those branches are ready'. > There are several changes we can make to both streamline the process, > and not increase the maintenance burden on the (other) maintainers of > these packages: > > * Have an EPEL SIG modeled after the SIGs centered around programming > language stacks (e.g. Python, Haskell, Java) > * Have an expedited flow where this SIG can request EPEL branches and > admin access to packages if there are no response from package > maintainers for a set period (3 days? 1 week?) Both of those are really short... I guess a week or two might be ok. > * whether it should be full admin access or whether such access > should be scoped to epel* branches can be discussed. Full admin would > make it possible to adjust the spec in Rawhide to be more EPEL > friendly, for example > * Members of the EPEL SIG can then branch these packages early when the > next EL release is branched > * The member of the SIG doing the branching should be designated as the > primary EPEL assignee for that package How would that be designated? > One deviation we might want to have from how Python SIG works is... we > probably don't want to encourage packagers to add this EPEL SIG as a > comaintainer preemptively, but only as needed. That would defeat the purpose of using epel-sig packages as 'always branch' wouldn't it? The other hazard if that different maintainers have different workflows and epel-sig folks would need to adjust to those. ie, some people want master to have epel conditionals and merge back to epel branches, some don't want that at all. I wonder if it wouldn't make sense to have some way to indicate to people what workflow is in effect for the package (I guess spec file comments?) kevin signature.asc Description: 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://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: Proposed EPEL Playground Documentation
On Tue, Sep 08, 2020 at 08:52:39AM -0700, Troy Dawson wrote: > Note1: Not everything has been implemented yet. package.cfg is still > in the epel repos. fedpkg has not been updated. This documentation > will go out when those changes are implemented. > > Note2: This is a proposal. It can be changed. If there is something > in there you do not want or think should be re-worded, please say so. Looks good to me. +1 and thanks for writing it up. kevin signature.asc Description: 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://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 Next
On Wed, Sep 09, 2020 at 01:15:29PM -0500, Carl George wrote: > > So, maintainers would need to be careful to make sure epel8-next or > > whatever packages are rpm 'newer' at all times to make this work right? > > Or I guess if they were fixing soname issues like above, dnf might be > > smart enough to pull in the next version anyhow even if it was lower > > than the epel8 one (unless the user used --best). > > Yes, I believe dnf helps us out here as you described. We could also > document that packagers should take care to ensure the upgrade path works > from epel8 to epel8-next, similar to Fedora branches. Fedora has the added > benefit of the dist macro always ensuring the release field is higher on > higher branches, but in our cases it's .el8 for both. Maybe we could > consider redefining dist for epel8-next builds to accomplish the same thing, > but I'm not sure it's worth the effort. Changing the dist tag is pretty easy (can be done in koji)... % rpmdev-vercmp 1.0-1.el8 1.0-1.epel8stream 1.0-1.el8 < 1.0-1.epel8stream Might also make it easier to see where packages came from? > > So, say I have package foo that needs a rebuild to work with stream. > > I request a branch, do a build and everything there is happy. > > Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and > > push it out and everything is happy again... but what about the > > epel8-stream/next package? It just sits there older and unused? > > Yes, but I don't see a problem with this. ok. I'm not sure it's a problem per se, but something to note. > > I assume this would work like playground/rawhide as far as landing in > > the buildroot right after build and going out in the daily compose? > > Or would you want to use bodhi updates? > > My preference would be to use bodhi updates. I think updates getting > published without review would degrade the experience for CentOS Stream > users. We could do a lower karma/time threashold than regular EPEL if > desired. > ok. Thats a non trivial amount of work added on. (creating bodhi release for it, updating sync scripts and punji config, etc). Can be done, but will definitely be more work. kevin signature.asc Description: 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://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 Next
On Wed, Sep 09, 2020 at 12:36:44PM -0400, Ben Cotton wrote: ...snip... > Warning: heresy and rampant speculation ahead! > It's too early to do this now, but I think there's a compelling case > to be made for shifting EPEL from Fedora to Stream at some point. This > would be dependent on getting a solid contributor community > established for Stream, of course. Realistically, I'd say we're a few > years away from making that transition, but I think the Stream > community would be a more natural fit. If CentOS Stream had existed > when EPEL started, I don't think we'd have made EPEL a part of Fedora, > despite the good points Matthew makes below. (In other words, it's not > a foregone conclusion that EPEL should be a part of Stream, and there > are reasons not to do that, but there are also reasons to do that. > That's a problem for Future Us to solve.) I'm a bit confused here... you seem to be conflating epel and this epel-stream/epel-next. Do you mean both of them? or just the new one would move over? We would need at least shared git (is that still something that might happen someday?) kevin signature.asc Description: 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://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 Next
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote: > Howdy folks, > > A large part of my day job is working on CentOS Stream. Naturally I would > like it to be successful and have wide adoption. I know that EPEL will play > a big role in this success. EPEL is extremely popular. Many users consider > RHEL and CentOS unusable without it. > > The problem we are facing is that EPEL 8 cannot be 100% compatible with > RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for > RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, > those changes are showing up in CentOS 8 Stream first. EPEL 8 builds > against the latest RHEL 8 release. This can result in EPEL 8 packages that > are uninstallable on CentOS 8 Stream due to the library differences. One > prominent example we have already seen is llvm-libs, which has increased its > library soname in every RHEL 8 minor release so far. Another increase is > planned for RHEL 8.3, which has already been released in CentOS 8 Stream. > There are likely other incompatibilities that haven't been noticed yet. I > expect this problem to grow worse as RHEL development continues and more > packages are added to EPEL 8. This situation is hurting the adoption of > CentOS Stream. > > To solve this problem, I am proposing that we create a new repository called > EPEL 8 Next. > > - built against CentOS 8 Stream > - opt-in for packagers (must request epel8-next dist-git branch) > - opt-in for users (part of epel-release but disabled by default) I like tdawsons idea down thread that it be a 'epel-release-stream' or whatever subpackage, so they have to install that and enable it (just like they would for enabling stream) > - used *with* epel8, not *instead of* So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best). Possibly it would be best to say 'must be newer' and have some kind of check... ? > This will provide EPEL packagers a place where they can update their > packages when necessary to be compatible with CentOS 8 Stream. These > packages would also be useful for RHEL 8 users during the gap between a RHEL > minor release and the equivalent CentOS 8 Linux rebuild. In theory this > repository should also be directly consumable by RHEL 8 Beta releases. > Similar to RHEL itself, breaking changes could be permitted in epel8-next in > preparation for delivering them to epel8 around the time of the next RHEL > minor release. So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused? > > This proposal may sound similar to epel8-playground. However, that was > still built against RHEL 8, so it didn't solve the compatibility issue with > CentOS 8 Stream. This proposal does draw on lessons learned from the > playground experiment. > > - no automatic builds via packages.cfg > - opt-in rather than opt-out > - layering on top of epel8, rather than duplicating content > > I first suggested this idea at the last EPEL Steering Committee meeting, and > we plan to discuss it again during the next one. Please share your thoughts > on this proposal. I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates? kevin signature.asc Description: 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://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, Sep 04, 2020 at 07:18:31AM -0700, Troy Dawson wrote: ...snipp > Step 5 - Send a daily report > -- Is this similar to what we send for EPEL6,7,8 ? > --- If this is true, I'm in favor of it. If not, then please explain more. > -- I have no idea about the work involved for this. I was thinking like the report that rawhide/branched composes send to the devel/test lists. So, basically that the compose happened and showing what updated, etc. I think that shouldn't be much work, but... we may need to do some work to make it not send if nothing has changed (which we should/could also reuse for branched). > I think Step 5 is a very important step (if I'm understanding it > correctly). Because it will give us a good idea about how many people > are utilizing playground. well, no, it will just make it more visible when packages in playground change. For usage, thats another thing... we should look at the new dnf counting that fedora is doing and see if we can use that with at least epel8... but thats another seperate project I guess. > > I think Step 3, changing the inheritance is the only change in the > work involved for releng. We would be changing the inheritance, > instead of deleting it. I don't know how much extra work that will > be. Should just be a few commands. kevin signature.asc Description: 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://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 Mon, Aug 31, 2020 at 08:05:14AM -0700, Troy Dawson wrote: > On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen wrote: > > > > > > > > On Mon, 31 Aug 2020 at 09:43, Troy Dawson wrote: > >> > >> On Sun, Aug 30, 2020 at 11:44 AM kevin wrote: > >> > > >> > >> > > Thoughts? > >> > > >> > Well, I think it satisfies all the use cases, but... we barely have > >> > enough cycles to try and revamp playground. Do we think we have enough > >> > to do that and also make a new -next version? > >> > > >> > >> Very good question. > >> Without being a superhero, do you and/or Smooge think we have the > >> resources to do this? > >> It's sounding like the answer is no. > >> > > > > Honestly, I don't see us having the resources to keep the playground > > around. Kevin's doubts a long time ago about playground stretching > > resources too far were correct. The build system is highly complex and just > > doing plain EPEL is a strain on the Fedora volunteers. Adding the > > playground was an experiment and I would lean towards ending it. > > > > > > Sounds like you would like C) > > 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) > > You, Kevin, and Mohan have been doing all the work. And anything we > decide, you all will end up doing all that work as well. So I think > totally fair that you get a huge say in what happens. > But if we do decide to drop playground, I don't want it to sound like > it's because of you. > > The facts are that EPEL has been given very limited resources, barely > enough to keep normal EPEL operations running. > Adding epel-playground on top, has over-taxed our limited resources. > If epel-playground didn't require any extra upkeep, it might be ok. > And if we find a solution that doesn't require any extra upkeep, maybe > we can keep playground. > But adding anything else, like -next, is over the top. At a minimum > it will require extra resources every couple years to setup and take > down stuff. Those are resources we don't have. I think playground might be fixable/made of use without too much work... * adjust fedpkg to stop requesting playground branches always/only request them on explicit ask * change the inheritence in koji so it inherits from epel8 * untag all the things that are "older" in playground * add more docs about what it is and how it works * perhaps make it send a daily report for each compose I suppose though that if we get those things in place, adding a epel8-stream shouldn't be much work over that (aside mirroring stream repos and adding them to koji). I wish we could get some idea of the usage of things to know where best to send our limited efforts. Are people using playground? Would they use it more if it was smaller/just big changes packages? Are there enough stream users to justify a epel repo built against it? Would it be popular if there were? I'm open on how to answer these questions, or I suppose we just guess as best we can. We could also decide to do something if we get the resources. ie, don't set a time when something is done, say it depends on free time of interested parties. I suppose all that didn't help too much did it? kevin signature.asc Description: 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://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 03:11:49PM -0700, Troy Dawson wrote: > > 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? Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version? Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it? kevin signature.asc Description: 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://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 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? kevin signature.asc Description: 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://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, Jul 31, 2020 at 03:13:00PM -0700, Troy Dawson wrote: > We were having a good discussion about epel8-playground in the > Steering Committee meeting this week. Since we ran out of time I'd > like to continue it via email. > > Most everyone agreed that playground is currently a bit of a mess and > it's hard to explain to end users what it is for, or when to use it. > It was also agreed that we need to decide on a plan of "this is what > playground is for" and then work to setup/cleanup/document things. > > There seemed to be two main opinions of what to set the plan to. > > A) epel8-playground is meant for package development and testing for > major changes. We stop doing the "build on both epel8 and > epel8-playground", and epel8-playground packages only get built from > the epel8-playground dist-git branch. Thats my preferred setup. Note that this will take some releng work to make it inherit right from epel8 and such. > B) epel8-playground is meant for future RHEL/CentOS testing, and thus > everything built in epel8-playground get's built off CentOS Stream. > We would continue the "build on both epel8 and epel8-playground" and > this would make sure packages would be able to build on the newer > RHEL. I find this less compelling because stream changes are supposed to be minor release changes, so typically not abi/api breaks or big version updates. In general epel8 stable packages should keep working fine when the next minor 8.x release comes out, so I don't know that this would be particualrly valuable. > Both of these plans would require epel8-playground cleanup, and > re-implementation. Both would require work. But the work would be > quite different with the different plans. So until we decide which > way to go, we don't know what to do. > > Thoughts on which plan to choose? Or if there is something different? A for me, not sure when I would have time to work on it, but I think thats best. kevin signature.asc Description: 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://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: EPEL repos packaged for Fedora (for repoquery)
On Tue, Jul 21, 2020 at 02:06:43PM +0200, Miro Hron=C4=8Dok wrote: > On 07. 07. 20 14:08, Tomas Orsava wrote: > > On 6/30/20 9:10 PM, Miro Hron=C4=8Dok wrote: > > > On 30. 06. 20 21:03, Kevin Fenzi wrote: > > > > I don't think a package-review is needed? It would just be unretiri= ng > > > > the fedora branches of an existing package? > > >=20 > > > Technically, the package is "retired for 8+ weeks" on Fedora. Hence > > > a new review request. > > >=20 > > > > That said, I am -1 on the idea. > > > >=20 > > > > You have no idea how many people try to install epel packages on fe= dora. > > > > We had to explicitly add a Conflicts to try and reduce this, and th= at > > > > was with them in another repo entirely! > > > >=20 > > > > I fear if we do this more people will start installing stuff from e= pel > > > > on fedora and cause a lot of breakage. > > >=20 > > > I understand the concern, but am not considering it a blocker for > > > this, especially since people will find a way to download the epel > > > packages anyway. This does not allow `dnf install epel-release` on > > > Fedora neither are the repos enabled. The amount of work to actually > > > use this package to install epel packages on Fedora is more or less > > > the same as downloading the packages from Koji or EPEL mirrors. > >=20 > >=20 > > +1 from me. People will always do weird things, if they want rope, I sa= y > > let them have it. > > But that shouldn't stop us from making life easier for packagers. I > > myself would use this. >=20 > The discussion kinda stopped. I don't want to force the package in, but I= 'd > like to have some resolution. Is there a better way to achieve the result= s > with less risk? Well, not sure. Is there some way to put the repo files in a doc space or something and only get repoquery to use them, not normal dnf commands? I can't think of how to make it work, but perhaps dnf people could? could we request a special /etc/dnf/repoquery.d/ dir or something? Failing that, can they at least have a big comment block explaining that you shouldn't use them to install any packages with? kevin signature.asc Description: 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://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: Problems with yum update
On Thu, Jul 16, 2020 at 04:29:08PM -0400, warron.french wrote: > Actually the file indicates DEFAULT already. Odd. Thats the only time I have seen any errors like those. YOu might try a sudo update-crypto-policies --set DEFAULT and see if it helps anyhow. kevin -- > > -- > Warron French > > > > On Thu, Jul 16, 2020 at 4:12 PM Kevin Fenzi wrote: > > > On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote: > > > I work in a lab environment that has a proxy somewhere on the network. > > > > > > I have my VMware VM running CentOS8 and have installed the > > > epel-latest-release package. > > snip... > > > > > > I don't know what to do to fix this. Can someone please explain what the > > > problem is on a high level and then what to do about it so that I can > > learn > > > from this? > > > > What does: > > > > cat /etc/crypto-policies/state/current > > > > show? > > > > If it's FUTURE, thats the problem. You can do back to default with: > > > > sudo update-crypto-policies --set DEFAULT > > > > 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 signature.asc Description: 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://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: Problems with yum update
On Thu, Jul 16, 2020 at 03:59:23PM -0400, warron.french wrote: > I work in a lab environment that has a proxy somewhere on the network. > > I have my VMware VM running CentOS8 and have installed the > epel-latest-release package. snip... > > I don't know what to do to fix this. Can someone please explain what the > problem is on a high level and then what to do about it so that I can learn > from this? What does: cat /etc/crypto-policies/state/current show? If it's FUTURE, thats the problem. You can do back to default with: sudo update-crypto-policies --set DEFAULT kevin signature.asc Description: 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://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: EPEL repos packaged for Fedora (for repoquery)
On Tue, Jun 30, 2020 at 06:46:43PM -, Miro Hrončok wrote: > To scratch my own itch I've packaged EPEL repos for Fedora. I've decided to > use the existing epel-release component for this (but I am OK to get a > different name, such as epel-repos). > > See https://src.fedoraproject.org/rpms/epel-release/pull-request/9 > And https://bugzilla.redhat.com/show_bug.cgi?id=1852583 > > Package review and any other feedback is appreciated. I don't think a package-review is needed? It would just be unretiring the fedora branches of an existing package? That said, I am -1 on the idea. You have no idea how many people try to install epel packages on fedora. We had to explicitly add a Conflicts to try and reduce this, and that was with them in another repo entirely! I fear if we do this more people will start installing stuff from epel on fedora and cause a lot of breakage. Whats your goal here? To have them easily available to query from fedora installs? > (Side note: I'm using the hyperkitty web interface to send this email, as I > cannot connect to my email from Thunderbird, sorry if the email is somewhat > weird.) Seems fine to me. kevin signature.asc Description: 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://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: unable to submit updates to stable: 504 Gateway Time-out
On Wed, Jun 03, 2020 at 07:13:06AM -0700, Troy Dawson wrote: > On Tue, Jun 2, 2020 at 8:14 AM Felix Schwarz > wrote: > > > > > > Am 01.06.20 um 17:25 schrieb Troy Dawson: > > > I was having a similar problem last week, I opened a > > > fed-infrastructure ticket and they extended the time out time. But it > > > looks like things have gotten so bad that even that extended time > > > isn't good enough. > > > I have re-opened the ticket. > > > > Thank you - I was able to submit my updates to stable this morning :-) > > > Something happened, though my ticket wasn't updated. I was able to > see my update again ... once. > But my smaller updates and overrides are working now. > I'm glad it's working for you now. > Troy To clarify we knew it was having problems and tried a bunch of things to get it working, and it seems that it is now? But the actual root cause of the slowdown is still unknown. ;( kevin signature.asc Description: 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://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: Modules again
On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John Smoogen wrote: > On Tue, 19 May 2020 at 11:05, Paul Howarth wrote: > > > On Tue, 19 May 2020 09:07:30 -0400 > > Stephen John Smoogen wrote: > > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth wrote: > > > > > > > Yes, I'm using vanilla configs straight from mock-core-configs for > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl, > > which has the PowerTools repo defined and not disabled. > > > > (I generally use my own configs and don't touch the original ones, so I > > know that if I try the original ones from upstream then they should > > work as intended) > > > > Note that the error message doesn't say it can't find Judy-devel, it > > says that it (and Judy) is/are excluded. I don't know why that is. > > > > > Ohhh sorry. I missed the obvious. I am going to guess from past problems, > the system is trying to pull in mariadb which filters it out and > mariadb-devel which has it in. So when it sees the filters it says 'nope > can't do this sorry'. I wish there was a 'no I know it might break my > system do it anyway!' flag but I don't see one looking > through /usr/share/doc/mock/site-defaults.cfg . This was one of the reasons > for grobisplitter being used. You should be able to set: module_hotfixes = True in your dnf/yum/mock config. From the dnf man page: "Set this to True to disable module RPM filtering and make all RPMs from the repository available. The default is False. This allows user to create a repository with cherry-picked hotfixes that are included in a package set on a modular system." kevin signature.asc Description: 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://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: Incompatible upgrade for oniguruma in EPEL 7
On Fri, May 15, 2020 at 03:59:57PM -0500, Carl George wrote:
> The current version of oniguruma in EPEL 7 is affected by multiple CVEs.
>
> * rhbz#1466750 - CVE-2017-9224 CVE-2017-9225 CVE-2017-9226
> CVE-2017-9227 CVE-2017-9228 CVE-2017-9229
> * rhbz#1728967 - CVE-2019-13225
> * rhbz#1728972 - CVE-2019-13224
> * rhbz#1768999 - CVE-2019-16163
> * rhbz#1770213 - CVE-2019-16161
> * rhbz#1777538 - CVE-2019-19246
> * rhbz#1802053 - CVE-2019-19012
> * rhbz#1802063 - CVE-2019-19203
> * rhbz#1802072 - CVE-2019-19204
>
> I've discussed doing an incompatible upgrade of the package with the
> other maintainers (rhbz#1777660), and so far no one is opposed to it.
> As far as I can tell, the only package that would need to be rebuilt
> is jq.
>
> ```
> [root@c7-container:~]# repoquery --provides oniguruma | grep '\.so'
> libonig.so.2()(64bit)
> [root@c7-container:~]# repoquery --whatrequires 'libonig.so.2()(64bit)'
> jq-0:1.6-1.el7.x86_64
> oniguruma-devel-0:5.9.5-3.el7.x86_64
> [root@c7-container:~]# repoquery --quiet --disablerepo \*
> --queryformat '%{name}' --archlist src --enablerepo
> epel-source,epel-testing-source --whatrequires oniguruma-devel
> jq
> ```
>
> Let me know your thoughts and concerns about moving forward with this.
+1 here and thanks for making epel a safer place.
kevin
signature.asc
Description: 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://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: What to do about python 3.4 in EPEL7?
On Thu, May 07, 2020 at 12:11:58PM +0200, Miro Hrončok wrote:
> On 07. 05. 20 11:46, Dominik 'Rathann' Mierzejewski wrote:
> > Question: should I be using %{python3_pkgversion} at all? Some packages
> > still use it, e.g. python3-ply (python36-ply binary package), and
> > some don't.
>
> 0) It is no longer required from technical point of view.
> 1) There was no announcement not to use it.
> 2) There was never a hard rule to use it.
> 3) I'd personally still use it, for consistency.
Would it be needed if we moved from say python 3.6 to python 3.8?
But I guess python 3.6 is going to be maintained the entire life of
rhel7?
kevin
signature.asc
Description: 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://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: Playground policy
On Fri, May 01, 2020 at 10:48:54AM -0700, Michel Alexandre Salim wrote: > > > On 5/1/20 1:10 AM, Petr Pisar wrote: > > On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote: > > > Generally speaking (I can make this a separate thread if that helps) - do > > > we > > > expect every package in EPEL8 to also be built for EPEL8-playground, > > > either > > > through package.cfg or by building directly from the epel8-playground > > > branch? > > > > There is no such rule, but in my opinion, it is welcomed for exactly the > > terrible > > experience anybody gets when he tries to use epel8-playground. > > > Right, but if some package repos are missing packages.cfg and the maintainer > does not build it separately for epel8-playground, it is a terrible > experience for other packages depending on this missing package -- everytime > the maintainer submits an epel8 build, the epel8-playground target will > report a build failure. There was no 'rule' but the intent was everyone would keep the package.cfg and build for both. If they were not making any playground changes, they didn't need to commit anything, and fedpkg build would just build for both epel8 and epel8-playground. The problem is that the packages.cfg commit annoys everyone who does a 'merge origin/master' because it's not on the master branch, so they delete it to get their workflow back. I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8. Failing that, we could just look at dropping playground if it's not useful for people. > > The purpose of epel8-playground is to diverge when needed. That's why the > > epel8 > > branch contains package.cfg by default. > > > That seems to be the case for packages branched normally (fedpkg > request-branch). *However* I've seen some packages where the epel8 branch > and master branch are identical -- not sure how it happens, maybe the > committer has force-push permission? Or is there a way to request that a > branch be cloned from another branch instead of created from scratch? There's no force-push allowed. They likely just deleted it and are merging master over it. kevin signature.asc Description: 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://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: Looking for someone to take ngircd in EPEL
On Thu, Apr 30, 2020 at 08:39:48PM -0600, Orion Poplawski wrote: > Anyone willing to take over ngircd for EPEL? > > https://bugzilla.redhat.com/show_bug.cgi?id=1830182 Sure. I can do that. Will add it to my list. 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] Re: Upgrade to rdiff-backup in EPEL-7
On Mon, Apr 20, 2020 at 09:59:17AM -0700, Lance Albertson wrote: > What does the upgrade path look like from if folks are currently creating > backups using 1.x and they suddenly switch to 2.x? Is there an upgrade > path? Is there a way in EPEL to allow for both versions to exist to ease > migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we don't > end up breaking all of our backups. You can stay on the old 1.2 version on all machines and keep on the way you have been. Of course it won't get any updates or fixes, but thats pretty much been the case for the last N years anyhow. Just 'exclude=rdiff-backup-2*' in your yum.conf. For new installs you can get it from koji or from Frank's copr. If you upgrade to 2.0, you need to do so on all clients and servers at the same time so they can talk to each other. The existing backups you have on disk will work with either version. Does that help clarify any? kevin -- > > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford > wrote: > > > We have pushed into testing and intend to eventually release a new version > > of rdiff-backup which has a significant incompatibly with the current > > distributed version, when used in client-server mode. > > > > The current version is v1.2.8 and written in Python2, while the new > > version is v2.0.0 and written in Python3, and the language change breaks > > client-server mode, due to incompatible data representations between > > Python2 and Python3. In all other respects the two versions are compatible > > including the ability to read and write existing backup repositories. > > > > It should be noted that the v1.2.8 was released over 11 years ago and > > while a small number of bug fixes have been added by the community, there > > has been no co-ordinated work for a number of years, and no further > > development will occur on the Python2 version. All future work, > > enhancements and bugfixes, including security bugfixes, will be to the > > Python3 version. > > > > If it is necessary to stay with the Python2 version, it is recommended > > that you exclude rdiff-backup from future updates. > > > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > > the dependencies (python3-pyxattr and py3libacl) are also in the testing > > repositories. > > > > If you have any questions about the update, please contact me. > > > > Frank Crawford > > FAS: frankcrawford > > ___ > > 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 > > > > > -- > Lance Albertson > Director > Oregon State University | Open Source Lab > ___ > 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 signature.asc Description: 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://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: Extras not enabled on koji?
On Sun, Apr 05, 2020 at 03:37:29PM -0500, Richard Shaw wrote: > On Sun, Apr 5, 2020 at 9:52 AM Stephen John Smoogen > wrote: > > > OK so swig3 seems to just be in CentOS extras and not in RHEL extras. > > > > Is this the way it should be? All the EPEL test instances are CentOS, > right? If I run mock it uses CentOS extra. So why would the official > builders be different? EPEL has always built against RHEL. Unfortunately we can't simply provide RHEL free to everyone that wants to test against it, but you can get a free developer subscription and use that. > This doesn't make for a good packager experience :) Well, not sure how to make it better. We could move to building against CentOS, but that would be a big undertaking and some folks would like that and some would not. We could perhaps advertise the developer rhel subscription more for testing? Open to other ideas... kevin signature.asc Description: 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://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: Putting qt5 srpm macro into epel-rpm-macros
On Fri, Apr 03, 2020 at 09:59:24AM -0700, Troy Dawson wrote:
> RHEL 8.2 will have a newer qt5 (qt5-5.12.5).
> They have also cleaned up their qt5-srpm-macros, to remove a macro for
> a package they do not support, nor plan on supporting. I have
> verified this was their intention and they do not plan on putting it
> back.
>
> %qt5_qtwebengine_arches %{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el
>
> The problem is that this is in all the KDE spec files for EPEL8 that
> depend on qtwebengine. It's essentially telling them to not build on
> s390x.
>
> I've look at all the alternatives, and putting that macro into
> epel-rpm-macros solves the problem.
> I have verified that rpmfusion doesn't build on s390x, so they will
> not be affected by this problem.
>
> I'll be putting that in today, and letting it sit testing for the
> usual time. If anyone has any problems, please let me know before the
> two weeks are up.
Seems fine to do to me...
kevin
signature.asc
Description: 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://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: RHEL8 package list
On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote: > > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi > > > Please file a bug in bugzilla, requesting both of these to be added to > > EPEL8. > > It's possible that we might need to use the older version from Fedora > > 30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4) > > > > Troy > Yes, currently there are old versions of both in epel8-playground (those you > built some time ago)... I only wanted to check if there was the possibility > to upgrade them to the latest version, but util-linux is still too old to > support them. > > Mattia kevin signature.asc Description: 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://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: RHEL8 package list
On Sun, Mar 29, 2020 at 06:11:28PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Sunday, 29 March 2020 at 15:59, Mattia Verga wrote:
> > Is there a way to get the package list and their version available in
> > RHEL8? For example, I would like to make kpmcore and
> > kde-partitionmanager available in EPEL8, but they require util-linux
> > >= 2.33.2. Since I can't find what version is available in
> > Bodhi/Koji/etc. I would like to know if there's some other web
> > service where I can find that without having to install a VM just for
> > that...
>
> Unofficial, but very useful:
> http://rpms.remirepo.net/rpmphp/zoom.php
There's also:
https://infrastructure.fedoraproject.org/repo/json/
which are pulled from the repos epel uses in koji.
Looks like util-linux is 2.32.1...
"util-linux": {"channels": {"codeready-builder-for-rhel-8-aarch64-rpms":
[{"release": "17.el8", "epoch": "0", "versions": "2.32.1"},
kevin
signature.asc
Description: 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://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: Ansible & Python 3 in EPEL7
On Mon, Mar 02, 2020 at 11:46:49AM +0100, Igor Gnatenko wrote: > Hey folks, > > We recently started to use Ansible more and we are using some ansible > collection which is not compatible with Python 2. > > Are there any plans to switch Ansible to Python 3 in EPEL7 or are > there any recommendations what to do in such cases as we have? It's pretty possible to start doing python2 and python3 subpackages (with python2 default). We did this for Fedora for a while when things were changing. I'll try and see about getting that working in my spare (ha) time. If someone else would like to work on it and make a PR, please feel free to do so. kevin signature.asc Description: 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://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: EPEL Steering Committee Meeting Time
On Fri, Feb 21, 2020 at 12:11:19PM -0800, Troy Dawson wrote: > It seems that it is a tradition that when we have a new chair for the > EPEL steering committee, we also have a new time for meeting. > Something that fits better with all the current, active members. > > We currently have the meeting on Wedensdays at 1800 UTC. > date -d "Wed 1800 UTC" > 1:00pm Eastern U.S. 10:00am Pacific U.S. 02:00am Beijing China > > What day and time would people like? > If you haven't been able to come to the meeting due to the time, what > would be best for you? Perhaps we should make a https://whenisgood.net/ or whatever that fully open source one is ( frame a date?), and let people vote for a week or so? kevin signature.asc Description: 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://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: Proposed official change to EPEL guidelines: modules and RHEL
On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote: > On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote: > > This is what I was trying to get to in the thread recently about > > libssh2. However it's still not entirely clear to me. > > > > Does this mean if there's a package foo that is a rhel package, but not > > in a module, that it can be overlapped with a foo package thats in a > > epel non default module? ie, does it only mean the modular case or does > > it mean any rpm? > > I don't understand the last sentence. To the first question: yes, and that > non-default module package will only get installed if the module is > explicitly enabled. Consider: 1. foo rpm that is in the RHEL baseos. It's not in any module. Can epel make a foo (non default) module that overrides it? 2. foo rpm that is in a RHEL default module. Can epel make a foo (non default) module that overrides it? 3. foo rpm that is in a RHEL non default module. Can epel make a foo (non default) module that overrides it? I think we all agree 3 is fine. I think 2 could cause problems, but perhaps it would work. I would think 1 would be fine also. kevin signature.asc Description: 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://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: Proposed official change to EPEL guidelines: modules and RHEL
On Thu, Feb 13, 2020 at 07:54:24AM -0500, Matthew Miller wrote: > I've been saying this for a while as if it's fact, but of course it's not > actually fact until approved, so I'm puting this to the EPEL team to > hopefully do so. > > The current guidelines * say: > >EPEL packages should only enhance and never disturb the Enterprise Linux >distributions they were built for. Thus packages from EPEL should never >replace packages from the target base distribution - including those on the >base distribution as well as layered products; kernel-modules further are >not allowed, as they can disturb the base kernel easily. > > With modularity in EPEL 8, we have the opportunity to allow more flexibility > while preserving the primary goal of not disturbing the base distribution. > Therefore, I propose adding: > > In EPEL 8 or later, it is permitted to have module streams which contain > packages with alternate versions to those provided in RHEL. These packages > may be newer, built with different options, or even older to serve > compatibility needs. These MUST NOT be the default stream -- in every > case, explicit user action must be required to opt in to these versions. > > > (Note that the base package _does not_ have to be part of a module for this > to work.) > > What do you think? This is what I was trying to get to in the thread recently about libssh2. However it's still not entirely clear to me. Does this mean if there's a package foo that is a rhel package, but not in a module, that it can be overlapped with a foo package thats in a epel non default module? ie, does it only mean the modular case or does it mean any rpm? kevin signature.asc Description: 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://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: Can we enable some "-devel" modules from CBR in the EPEL8 buildroot?
On Thu, Feb 13, 2020 at 10:23:52AM +0100, Miro Hrončok wrote: > Hello EPEL. > > It seems that we have a python38-devel module in the RHEL 8.2 Beta Code > Ready Builder repository. It has only one stream but it is not a default > stream due to some technical limitations. > > Can we please enable such stream in the EPEL8 buildroot trough some Ursa > Major/Prime/... thing? Nope. We don't ever sync or use betas... once it's released it should be possible to use it however. > Is that technically possible on EPEL side? Yeah, the way we have things now it should be possible. > Is that possible by policy? I think so... kevin signature.asc Description: 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://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: Need to get Steering Committee consensus: packages in old modules
On Mon, Feb 03, 2020 at 02:15:19PM -0800, Troy Dawson wrote: > On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa wrote: > > > > On Mon, Feb 3, 2020 at 2:36 PM Stephen John Smoogen > > wrote: > > > > > > > > > My main job is working with Fedora Infrastructure, and we are trying to > > > work out how to handle: > > > > > > https://pagure.io/fedora-infrastructure/issue/8558 > > > > > > The problem is that various tools filter what packages can be branched > > > into Fedora see that libssh2 was in a module that RHEL shipped in 8.0 but > > > it is no longer in the release with 8.1. > > > > > > Do we need to make libssh2 a module? > > > Should we allow libssh2 be branched as a 'bare' package in EPEL proper? > > > Other? > > > > > > > Since libssh2 is being dropped from RHEL, I think we should just > > permit it as a regular package in EPEL proper. That maximizes its > > usefulness to everyone. > > > > I second that. > I don't think it matters if it was in a module or not. If it is no > longer in RHEL8, then it should be permitted as a regular EPEL8 > package. I agree, but... what about packages that are modules. What does epel promise not to overlap with? Just bare rpms? Any rpm in any modules also? ie, would it have been ok to make a normal rpm of libssh2 before when it was in a module? kevin signature.asc Description: 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://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: playground being built off beta or stream ?
On Thu, Jan 23, 2020 at 08:57:56AM -0800, Troy Dawson wrote: > Hi, > A while ago, there was some discussion about epel8-playground using > RHEL8.x-beta, or CentOS-Stream, as the buildroot. > What was the outcome of that discussion? I don't think there was a clear consensus... > I know I had some concerns about not knowing which date of > CentOS-Stream a package was built off. And that still is a concern I > have. > > But, now I have a real world problem. With the release of RHEL8.2 > Beta, I have learned that some of my epel8 packages will not install > on RHEL 8.2 without a rebuild. But if I do rebuild them, then they > won't run on RHEL 8.0 or 8.1. > > I'm sure we won't have anything in place before RHEL 8.2 is released, > but I was wondering how that discussion ended, and if, in the future, > we will have epel8-playground use CentOS-Stream. I think we may be need more data? Like someone writing up all the pros and cons? I think it might be nice to use stream, but not sure if there's workflows that would break. kevin signature.asc Description: 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://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
