[EPEL-devel] Re: EPEL 10 status update
On Tue, Sep 3, 2024 at 4:01 PM Troy Dawson wrote: > I hope this helps. It does. Thanks. -- ___ 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: EPEL 10 status update
On Tue, Aug 13, 2024 at 9:12 AM Stephen Smoogen wrote: > This is something I wanted to do in previous EPEL splits, but it has usually > gotten too many complaints from packagers to consider. Many packagers don't > want their packages in EPEL at all but will do so if there are requests from > someone or that there is going to be a branch packager for EPEL packages. > Many EPEL branch packagers really only want to support one release because > that is what they are using versus multiple ones. There is also the case (I had one), where a package (in epel8) was later incorporated by RH into EL9, for which automatic branch requests might have been an issue (unless the automatic approval processes already checks for that and rejects the branch request). > That said, I think it is something to revisit like we did for EL7, EL8 and > EL9 :). Personally, automatic branching would work fine for me, but often my bigger issue is opening the bugzilla tickets for the often large dependency chain for some scripting languages asking for each package to be actually built, and then waiting for the packager to have the resources to build them. If one starts with the premise that the packagers should control the creation of all branches then auto-creating all those dependency branch/build bugzillas (and *their* dependency branch/build bugzillas, and so on) might be a better step forward to reduce the process delays. -- ___ 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 Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: > I see your point. It sometimes also happens when the EPEL package is a > dependency of the important package, the customers aren't actually asking for > the EPEL package. While I am sure that occasionally RH chooses to add a package to RHEL just because they think it is a good idea[0], I would expect that these days adding a package is mostly about customer requirements[1], even if it is an indirect requirement (even as a dependency of a dependency of a dependency). I think your new wording is fine. There will of course still be a few EPEL maintainers who will ask the question of "why now?", but those are likely to be few enough to handle on a case by case basis. Thanks. [0] Although I suspect that is not a common occurrence, as few organizations want to add to their ongoing support burden without something more formal than a whim. [1] Formal requests, or easily anticipated requests based on industry technology directions, and/or from the various industry advisory boards. ___ 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 Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski wrote: > It would be really nice if the wording of the bug could contain some > kind of a "thank you" note to the EPEL maintainers of the package in > question. Not everyone will understand this process as "great, I don't > have to maintain package X anymore, Red Hat will be doing that for me > from now on". Some folks may take it as "Oh no! Red Hat is taking away > my toy! Why?!" Ideally, there should still be a way for EPEL > maintainer(s) to continue contributing to the RHEL package. Perhaps add something like (wordsmithed by someone competent in such things): "The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product" ___ 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: Thoughts: epel-release auto-enable crb repo
On Sat, Jun 4, 2022 at 8:52 PM Troy Dawson wrote: > What do others think? Almost everything *I* care to do with el eventually needs epel and/or CRB/Powertools. I also do not think CRB/Powertools should be auto-enabled by epel (epel does not own them, and should not touch them). And, yes, a couple of my ansible scripts do enable epel and crb/powertools in order to install packages, but that is my choice, not someone else's. ___ 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: SPDX identifiers in old branches?
On Wed, May 25, 2022 at 12:47 AM Maxwell G wrote: > I don't follow. What "rpm spec file support" are you referring to? I interpreted the proposal as adding a new stanza SPDX: in addition to License: which requires changing the definition. The follow up suggested that the license field be differently formatted. I disagree with such explanatory prefixes, as it requires yet more apps to parse/support various prefixes. If msuchy's proposal is not accepted (allow packagers to use SPDX in all) lets just go back to one of the original proposals and have proven packagers just do a bulk conversion after giving existing packagers time to do their own conversion. One and done (and, yes, wrong some of the time, but that too can be fixed). ___ 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: SPDX identifiers in old branches?
On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > Would it make sense to make ALL the new tags be SPDX:, at least for > an interim period (of years most likely) where both old and new tags are > allowed? I don't think that is going to work unless the rpm spec file support would be backported to previous releases (without another macro that tries to do some magic). And the goal for some of us is to have one spec file work across all currently supported releases. ___ 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: Default for 'dnf copr enable'
On Mon, Apr 11, 2022 at 1:37 PM Miroslav Suchý wrote: > Can you please tell me what is good default for you: > > Centos Stream 9: > 1) epel-9-$arch > 2) centos-stream-9-$arch > 3) centos-stream+epel-next-9-$arch > 4) no default, print error and let user explicitly declare the chroot As someone who has experienced some of the challenges, if I have to choose from those, 4 is the only one that for me results in the least surprise (you know what you are getting). However, is there a 5th option? That would check to see if there are builds in only one chroot, and select that (with message), and if there more than one chroot that contains builds reject the request. I suppose there is also a 6th option, which would be to enable all the chroots (and let the section enabled, priorities and package versioning sort it all out). I don't really like 5 or 6, as they can lead to later surprises, but they at least have some appeal for some common use cases. ___ 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: slowing down the stalled request process
On Wed, Mar 30, 2022 at 5:03 AM Carl George wrote: > > However, despite the good intentions, I've observed some frustrations > among Fedora packagers when collaborators are added via this process. > We do not want maintainers to feel rushed or circumvented. That said, > I am firmly of the opinion that nobody "owns" Fedora packages, we > maintain them. Packagers wanting to take action on EPEL requests > should have a way to do that if the existing maintainers have not > taken action within a reasonable amount of time. What I would like to > discuss is what amount of time is reasonable. Have you asked the existing packagers who are unhappy with having other collaborators being added to a package when they have not yet responded why they did not respond? There difference between they never saw the email (and then sending even dozens might not matter), and they were so overwhelmed that they just had no time even to reply with something like "I'll get to this in (around) a month; ping me again then". And while you are asking that question, perhaps ask if the packager has any good ideas on alternative solutions that they think could work better (there may be some common thread in the responses). FWIW, while I think two weeks is a bit too tight (there are numerous events that can take someone away from such activities for more than two weeks(*)), knowing any common reasons for not responding may point to better approaches. Gary (*) And while a month seems better, I also see that timeframe being frustrating to others who want to use those packages, or to build dependent packages. No great answers. ___ 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 maintain upgrade path from EPEL 8?
On Sat, Feb 19, 2022 at 8:21 PM Miro Hrončok wrote: > Once I remove the Obsoletes line from Fedora, should I worry about merging > that > commit to the epel9 branch or not? Logic dictates that the Obsolete should > remain in EPEL 9 forever, but I wonder if there is a policy/rule of thumb. > E.g. > in Fedora, we only support upgrades to Fedora N+2. Do we support upgrades of > EL+EPEL systems as well and how "far"? My own personal rule of thumb is that while I much prefer spec file cleanliness, leaving the Obsoletes: in the spec file (essentially) forever does no harm, and can support less common situations, since "users do the darndest things". ___ 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: State of EPEL mock chroots?
On Fri, Feb 4, 2022 at 2:05 PM Richard Shaw wrote: > So most of them work, but not EPEL. That specific example is being tracked in RHBZ #2049024 The discussion started back in November 2021 https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/#7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F > So which SHOULD I be using for EPEL package development? I will note that mock-core-configs-36.4-1, which has been sitting in testing for some time (due to ongoing discussions and issues with some tooling, as I recall), and presumably the soon to be available next version of core configs have changed things around IRT the epel related mock cfgs (as I recall the new new version removes the epel-8 cfgs entirely, since they are, as you experienced, broken). The new normal for (at least) some use cases will be something of the form centos-stream+epel- ___ 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 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. ___ 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: The incredibly shrinking RHEL
On Sat, Jan 15, 2022 at 6:29 PM Orion Poplawski wrote: > I don't buy any of these arguments, and it doesn't really address the > situation of "missing -devel" packages. The missing devel packages for shipped libraries are a clear pain point for those that just want build something for their EL system(s), and not go through something like mock to do it (or create/build/maintain their own -epel package). This is not a new issue, though. A number of missing devel packages were identified with EL8, with the statement that the long term would be to open tickets requesting the devel packages be added to CRB. As I recall, some were, and some were not. I would have preferred the EL8 experience was taken to heart for EL9, and if it was felt necessary to ship the base library, the devel package would have been in CRB by default just to avoid a repeat of the pain point. To be fair, I have seen some devel packages for EL9 libraries (after a bugzilla ticket) being added to the stream 9 CRB repo, so the RH teams are being responsive, even as I am sure there are internal processes to work through. ___ 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: Libcec rebase for epel7 – incompatible upgrade?
On Tue, Jan 11, 2022 at 6:39 PM Andrew Bauer wrote: > I’ve read the EPEL documentation regarding incompatible upgrades, and I am > not entirely sure this falls under that category. Yes, it is a major version > upgrade, but it is unclear to me if that makes it “incompatible”. As I recall, v3 to v4 changed the API (hopefully they bumped the soname, but I do not know if they did). That means that upgrading to a new version would require you to create a side tag and rebuild (and possibly fix any FTBFS) all dependent packages, and/or you would need to create a compat package to continue to support the old API (possibly requiring changes to the packages to explicitly call out the old (compat) version(s)). In the case of libcec, I am going to guess that a fair number of the apps that use it are in 3rd party repos, making coordination of such upgrades a bit of a challenge (side tags obviously do not work across 3rd party repos, and other such bumps have created issues with those 3rd party repos). My gut says to leave EPEL7 alone (EL7 has moved to maintenance only support level as I recall), and only build/support the recent libcec (6.something) in EPEL8/9 for public consumption. ___ 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 5, 2021 at 4:09 AM Kevin Fenzi wrote: > yes, yesterday. > > See the announcement: > https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/ *sigh*. Sorry, I missed it (I think I need to add yet another mail list to the firehouse about Fedora that I get email from). Sorry for the noise. ___ 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
