[EPEL-devel] Re: Proposed incompatible change: python-botocore + boto3
On Wed, May 1, 2024 at 2:38 PM Major Hayden wrote: > > Hello there, > > We were recently packaging a different package in RHEL 9 (efs-utils) that > lists python-botocore as a dependency. As part of that process, we brought > python-botocore into RHEL 9. Packaging efs-utils in RHEL did not work out in > the end. > > I'm looking to bring python-botocore back to EPEL (from CentOS Stream 9), but > as part of the packaging work, we needed to bump the version to 1.31.62, > which is newer than the existing 1.25.10 version in epel9. > > This also requires moving boto3 and s3transfer to later versions as well. The > boto3 update is another incompatible change but s3transfer should not be > disruptive. > > As discussed in today's meeting on Matrix, it makes more sense to move > botocore forward than to revert to the original version prior to the CentOS > Stream 9 and RHEL work. > > Relevant BZ tickets: > > https://bugzilla.redhat.com/show_bug.cgi?id=2243017 > https://bugzilla.redhat.com/show_bug.cgi?id=2236795 > > Meeting notes: > > > https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-05-01/epel.2024-05-01-18.00.log.html > > Thanks for your time! > > -- > Major Hayden > -- > ___ > 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 We discussed this today at the EPEL Steering Committee meeting. https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-05-15/epel.2024-05-15-18.00.html Committee members voted +6,0,0 to approve this. Please proceed with the rest of the EPEL incompatible update process. -- Carl George -- ___ 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
Re: Redis will no longer be OSS... now what?
Redis is not shipped in EPEL9, because it's in RHEL9. Same with EPEL8 and RHEL8. It is shipped in EPEL7 at version 3.2, presumably because updating any further would be an incompatible update. The license change announcement clearly states it will only be for 7.4 and up. The prior branches (6.2.x, 7.0.x, and 7.2.x) are still going to be maintained as per their security policy [0], and I haven't seen any indication that these maintenance updates will be anything other than BSD-3-Clause licensed. The license change commit has only occurred upstream in their unstable branch (future 7.4), and the 7.2 branch still has the previous license file [1]. This isn't like when mongodb switched to SSPL for all future versions, including maintenance/security updates to older branches. Considering these factors, F39+ can stay on 7.2.x for quite some time. F38 can stay on 7.0.x for the rest of its lifecycle. The only thing we can't do is update any branch to 7.4.x. Having keydb obsolete redis in Fedora would not be appropriate in my opinion, because they are still different software, and a user may want to have both installed at the same time. Additionally, keydb in EPEL definitely can't obsolete redis in RHEL. Maybe at some point we'll go the obsolete route in Fedora with a change proposal and FESCo approval, but I don't think we're at that point yet. [0] https://github.com/redis/redis/security/policy [1] https://github.com/redis/redis/blob/7.2/COPYING On Thu, Mar 21, 2024 at 1:19 PM Scott Williams wrote: > > Redis-6 is currently shipped in EPEL9, so it seems like a more obvious > step-forward wrt EPEL. > > > > Honestly trying to replace redis with KeyDB in Fedora would be a step > > backwards and cause headaches so I don't think it's feasible, at least > > until redis v7 features are merged into KeyDB. > > Unfortunately, it's still the best option we have. Ideally, redis wouldn't > have done this, but since redis is no longer license compatible, can we > really continue to ship redis-7 in Fedora 40 if we can't patch and maintain > it? If KeyDB were to merge and release a v7 version against the latest BSD > code, I agree that it would be a much better target for Fedora 40. > Unfortunately, we're in the awful position of having to choose between a > breaking change for a small amount of users or shipping something that we > can't patch or realistically maintain. If we have some clue that a v7 > merge/release is on the very near horizon for KeyDB, then maybe it makes > sense to keep redis and obsolete it for KeyDB after GA, but it would be > preferable, IMO, to have a clean break on Fedora 40 release if possible, > which will also give us a better chance to document it so the small amount of > impacted end-users wrt v7-specific things can prepare for it. > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] retiring klee in EPEL 9
I am retiring the klee package in EPEL 9. In accordance with the retirement policy [0], I proposed this retirement two weeks ago on the epel-devel mailing list [1]. This software is not compatible with LLVM 15 or newer [2][3][4]. RHEL 9 regularly updates LLVM, is already defaulting to LLVM 15 in 9.2, and is expected to update to LLVM 16 in 9.3. Since klee cannot be rebuilt to work with the newer LLVM versions, we must retire it. The package was already retired from Fedora earlier this year [5]. The Fedora maintainer also orphaned the package, resulting in there being no maintainers for the EPEL 9 package. I am stepping in to retire the package as a proven packager. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/VIP6GZFVNFRC2MZUB6OUEDF2SSW4BBVI/ [2] https://github.com/klee/klee/blob/v3.0/.github/workflows/build.yaml#L39 [3] https://github.com/klee/klee/pull/1648 [4] https://github.com/klee/klee.github.io/pull/347 [5] https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8 -- Carl George ___ 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
Closing the loop here, I've retired klee in EPEL 9. https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/SP2624QZPY33N3NZNX5QLSMO2HZBHNNQ/ On Fri, Sep 29, 2023 at 12:01 PM Kevin Fenzi wrote: > > 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 > ___ > 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 -- Carl George ___ 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: Are we sticking with exa or moving to eza in EPEL?
On Tue, Oct 10, 2023 at 10:10 PM Ian Laurie wrote: > > I realize exa is still in the EPEL9 repos, was wondering if there is an > intention to move to its replacement eza as was done in F39 and F40? > > Ian > -- > Ian Laurie > FAS: nixuser | IRC: nixuser > TZ: Australia/Sydney > ___ > 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 At a quick glance, I don't see obsoletes, provides, or conflicts in the Fedora spec file, so it wasn't a direct replacement per se. It was rust-exa being retired and rust-eza being added, which didn't happen in the same release. It's up to the relevant package maintainers (Fabio and the Rust SIG) to decide if they want to retire rust-exa from EPEL 9 and/or add rust-eza to EPEL 9. If retirement of rust-exa is the chosen route, an unmaintained upstream can certainly be viewed as the underlying reason why a maintainer would have "no desire" to keep maintaining the package in EPEL. https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire Here is a general guide for requesting packages in EPEL (tldr; file a bugzilla). https://docs.fedoraproject.org/en-US/epel/epel-package-request/ -- Carl George ___ 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] retirement of klee from EPEL 9
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. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2241277 [1] https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8?branch=rawhide [2] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SSJWCMXP45ERM76XH6MIW6Z76GIC7DFN/ [3] https://github.com/klee/klee/pull/1648 [4] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ -- Carl George ___ 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] Revisting conflicts policy for EPEL compat packages
In Fedora, it is allowed for compat packages to conflict with their non-compat equivalents. EPEL policy allows for the same behavior between EPEL packages, but not between EPEL packages and RHEL packages. The current policy includes the phrase "at this time" for that limitation. I believe it is time we revisit that part of the policy. I brought this up at a recent EPEL Steering Committee meeting, and the general consensus was to open a wider discussion about the topic. I've written about this in more detail on the Fedora Discussion site. I'm sending this email for awareness, but please centralize your feedback on the Discussion thread. https://discussion.fedoraproject.org/t/revisting-conflicts-policy-for-epel-compat-packages/90605 -- Carl George ___ 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-ANNOUNCE incompatible update of caddy in EPEL 9
On Thu, Aug 24, 2023 at 1:44 AM Carl George wrote: > > I am performing an incompatible upgrade of the caddy package in EPEL > 9. In accordance with the incompatible upgrade policy [0], I proposed > this upgrade just over a week ago on the epel-devel mailing list [1]. > For reasons detailed in the previous email, it is no longer possible > to update the package at the current version, preventing me from > resolving known CVEs. Today the EPEL Steering Committee voted to > approve this upgrade [2]. > > This upgrade will take the package from version 2.4.6 to 2.6.4. This > includes a few backwards-incompatible changes. I believe these > changes are on the milder side, and most users shouldn't notice a > difference. Here are the most notable removals/changes: > > - Reverse proxy: Incoming X-Forwarded-* headers will no longer be > automatically trusted, to prevent spoofing. > - Logging: Removed the deprecated common_log field from HTTP access > logs, and the single_field encoder. > - Logging: The remote_addr field has been replaced by remote_ip and > remote_port fields in HTTP access logs, which split up the two parts > of the remote address. > - Caddyfile: The reverse_proxy directive's handle_response > subdirective has had its status replacement functionality moved to a > new replace_status subdirective. > > There are also a few additional changes to features labeled as > experimental, and some deprecations (not yet removed). For a full > list, see the upstream release notes [3][4]. > > If you are able, please test and provide karma for the update [5]. > > [0] > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > [1] > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CDNDAKTIAQTFTNDHOIHKQJ4B2LAV5ZSS/ > [2] > https://meetbot.fedoraproject.org/fedora-meeting/2023-08-23/epel.2023-08-23-20.00.html > [3] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 > [4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 > [5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f > > -- > Carl George > ___ > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue This update has been in the testing repo for the mandatory 1 week period. I am pushing it to stable now. -- Carl George ___ 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] incompatible update of caddy in EPEL 9
I am performing an incompatible upgrade of the caddy package in EPEL 9. In accordance with the incompatible upgrade policy [0], I proposed this upgrade just over a week ago on the epel-devel mailing list [1]. For reasons detailed in the previous email, it is no longer possible to update the package at the current version, preventing me from resolving known CVEs. Today the EPEL Steering Committee voted to approve this upgrade [2]. This upgrade will take the package from version 2.4.6 to 2.6.4. This includes a few backwards-incompatible changes. I believe these changes are on the milder side, and most users shouldn't notice a difference. Here are the most notable removals/changes: - Reverse proxy: Incoming X-Forwarded-* headers will no longer be automatically trusted, to prevent spoofing. - Logging: Removed the deprecated common_log field from HTTP access logs, and the single_field encoder. - Logging: The remote_addr field has been replaced by remote_ip and remote_port fields in HTTP access logs, which split up the two parts of the remote address. - Caddyfile: The reverse_proxy directive's handle_response subdirective has had its status replacement functionality moved to a new replace_status subdirective. There are also a few additional changes to features labeled as experimental, and some deprecations (not yet removed). For a full list, see the upstream release notes [3][4]. If you are able, please test and provide karma for the update [5]. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CDNDAKTIAQTFTNDHOIHKQJ4B2LAV5ZSS/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-08-23/epel.2023-08-23-20.00.html [3] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 [4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 [5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f -- Carl George ___ 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] retiring caddy in EPEL 7
I am retiring the caddy package from EPEL 7. In accordance with the retirement policy [0], I proposed this retirement just over a week ago on the epel-devel mailing list [1]. For reasons detailed in the previous email, it is no longer possible to update the package with the same major version, preventing me from resolving known CVEs. Doing an incompatible update to the next major version is not an appealing option with only ten months left until the retirement of EPEL 7 as a whole. Users that wish to keep using caddy on RHEL 7 can use the Copr repo from the upstream project [2][3]. Caddy is also available from EPEL 8 and EPEL 9 for users that are ready to migrate to a newer operating system version. Both of these options will involve the disruptive update from caddy v1 to v2, but users can opt-in to it at their own pace. The upstream project has a migration guide in their documentation to help [4]. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JZRLEWOCX5QX3XZ7INLUZIB7LPAMDUZC/ [2] https://caddyserver.com/docs/install#fedora-redhat-centos [3] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ [4] https://caddyserver.com/docs/v2-upgrade -- Carl George ___ 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
Re: %pyproject_save_files license handlers
On Sat, Aug 19, 2023 at 4:58 PM Maxwell G wrote: > > On Sat Aug 19, 2023 at 22:13 +0200, Miro Hrončok wrote: > > On 19. 08. 23 19:44, Maxwell G wrote: > > > Hi Pythonistas, > > > > > > %pyproject_save_files automatically handles marking license files > > > with %license when a build backend installs them into a package's > > > dist-info directory and the License-File header is specified in the > > > METADATA file. Currently, only setuptools and hatchling meet this > > > criteria. Notably, poetry and flit do not support this. They will > > > install license texts into the dist-info directory, but they do not add > > > the License-File metadata. The License-File tag is not standardized, and > > > discussion on PEP 639 which defines this standard has stalled. I believe > > > relying on this feature is a problem, as if a project changes build > > > systems or some other config and a packager doesn't realize, suddenly > > > the license file won't be marked with %license or even worse, not > > > installed at all. Since the pyproject macros read the build backend from > > > pyproject.toml without packagers having to manually specify anything > > > (which is generally great!), this situation seems likely to occur. > > > > > > Until these issues are resolved, I propose banning this in Fedora and > > > requiring packagers to manually mark files with %license or at least > > > adding a large warning to the Packaging Guidelines. It can be similar to > > > the `'*' +auto` flags which are used by pyp2spec for automatic PyPI > > > builds in Copr but not allowed in Fedora proper. > > > What do y'all think? Am I missing something? > > > > Hey. Alternatively to banning this: what if we make %pyproject_save_files > > fail > > without a license? Obviously, that would be a breaking change, so it could > > be > > opt-in first. > > > >%pyproject_save_files -l ... > > > > When used like this, no License-File header would result in an error. > > > > > We could introduce a reverse flag -L (don't fail without a license), and > > have a > > discussion about changing the default later. > > > > The guidelines could than say something like: If there is a license file you > > MUST do one of the following when using %pyproject_save_files: > > > > 1) use -l and don't list it in %files explicitly > > 2) use -L and list it in %files explicitly > > > > That way, we ensure the license is packaged (and marked as %license) while > > not > > reducing automation. > > > > I like -l flag idea, but I don't think we can make it fail by default > for the foreseeable future, given the status of PEP 639 and build system > adoption. > We could use a heuristic (such as a hardcoded list of globs) to match > license files in dist-info directories if License-File doesn't exist, > but I'm not sure that's the best idea. > I'm hesitant about adding a noop -L flag until we actually have a > plan/criteria on when to start enforcing -l, but I don't feel strongly. > > > > -- > Maxwell G (@gotmax23) > Pronouns: He/They > ___ > python-devel mailing list -- python-devel@lists.fedoraproject.org > To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue I like this plan overall. The only part I would adjust is the guidelines having a MUST requirement to use one flag or the other. Fewer required flags is better, which is why we would have a default at all. I'm totally fine with a transition to making the default behavior to fail if a license isn't found. The guidelines can say that packages should use `%pyproject_save_files -L` if it is known that it won't detect a license and it will be specified manually with %license in %files, which will be a noop now but will prevent packages from FTBFS when we make the switch. -- Carl George ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] incompatible update of caddy in EPEL 9
Per policy [0], this is an announcement that I would like to do an incompatible update of the caddy package in EPEL 9. The version in the EPEL 9 repo is currently 2.4.6. RHEL 8 currently has golang 1.19. Based on my recent investigation of the EPEL 7 package [1], I've discovered just how sensitive caddy is to the version of golang it is built with. Upstream caddy only ever tested version 2.4.6 with golang 1.16 and 1.17 [2]. I did previously build caddy 2.4.6 with golang 1.18, which required swapping out the bundled quic library to work [3]. Thankfully that worked without patching the caddy code, but updating the bundled quic further in order to build with golang 1.19 would require significant patching, which isn't even guaranteed to work. I do not believe that rebuilding caddy at the current version in EPEL 9 is feasible, which prevents even attempting to backport outstanding CVEs. I'm currently tracking two CVEs for the EPEL 9 package that I would like to fix. - CVE-2022-28923 [4][5][6] - CVE-2022-41721 [7][8][9] To resolve these CVEs, and to get compatible with RHEL 9's golang 1.19, I think the best version of caddy to update to is 2.6.4. Updating caddy from 2.4.6 to 2.6.4 includes some backwards-incompatible changes (hence this email). After review, I believe these changes are on the milder side, and most users shouldn't notice a difference. Here are the most notable removals/changes: - Reverse proxy: Incoming X-Forwarded-* headers will no longer be automatically trusted, to prevent spoofing. - Logging: Removed the deprecated common_log field from HTTP access logs, and the single_field encoder. - Logging: The remote_addr field has been replaced by remote_ip and remote_port fields in HTTP access logs, which split up the two parts of the remote address. - Caddyfile: The reverse_proxy directive's handle_response subdirective has had its status replacement functionality moved to a new replace_status subdirective. There are also a few additional changes to features labeled as experimental, and some deprecations (not yet removed). For a full list, see the upstream release notes [10][11]. Finally, I'll note that RHEL 8 has the same version of golang as RHEL 9, so I also targeted caddy 2.6.4 for the initial EPEL 8 package that is on its way to testing [12]. It will be nice to have the same version of caddy in both EPEL 8 and EPEL 9. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JZRLEWOCX5QX3XZ7INLUZIB7LPAMDUZC/ [2] https://github.com/caddyserver/caddy/blob/v2.4.6/.github/workflows/ci.yml#L22 [3] https://src.fedoraproject.org/rpms/caddy/c/8a639d7060ef6ff610880429d161b5f0275deee1?branch=epel9 [4] https://bugzilla.redhat.com/show_bug.cgi?id=2226939 [5] https://access.redhat.com/security/cve/CVE-2022-28923 [6] https://nvd.nist.gov/vuln/detail/CVE-2022-28923 [7] https://bugzilla.redhat.com/show_bug.cgi?id=2232267 [8] https://access.redhat.com/security/cve/CVE-2022-41721 [9] https://nvd.nist.gov/vuln/detail/CVE-2022-41721 [10] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 [11] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 [12] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163 -- Carl George ___ 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] retiring caddy in EPEL 7
Per policy [0], this is an announcement that I intend to retire the caddy package in EPEL 7. This package is in a bit of a weird state. The version in the EPEL 7 repo is currently 1.0.3, which was released upstream on 2019-08-14. Upstream development on v1 stopped with the release of 1.0.5 on 2020-02-28. Recently I updated the package from 1.0.3 to 1.0.5 to bring it as current as possible without breaking changes. At the same time I updated a bundled library to resolve CVE-2022-3064 [1], and also expected that rebuilding it with a newer golang would resolve CVE-2022-41717 [2]. I published this update [3] to the testing repo with the intention of testing it myself, but life got in the way and it was promoted to stable before I had a chance to. I also forgot that while I had enabled the test suite in Fedora, I did not have it enabled in the epel7 branch. Unfortunately, I discovered that the binary in this package would core dump immediately and was completely non-functional. As a quick partial mitigation, I asked RelEng to untag the broken build to revert the repository back to the previous build [4]. After investigating the problem, and consulting with upstream, I believe that it is simply not possible to build a working caddy v1 binary with golang 1.19 (the version currently available EPEL 7). Caddy is rather sensitive to the version of golang that it is built with, both for the minimum version, and as I discovered during this ordeal, the maximum version as well. I considered doing an incompatible update to bring the EPEL 7 package to a version of caddy that works with golang 1.19, but ultimately decided against it. It would be a very disruptive incompatible update because the config file format changed drastically between v1 and v2. With a mere ten months left before EPEL 7's retirement, I do not believe it is worth the effort or disruption to do such an incompatible update. Due to the outstanding CVEs, and the inability to even rebuild the package, I think the best course of action is to just retire it. Per policy, I will take this action in one week. As an alternative, the upstream project maintains a Copr repository [5][6] that provides the latest version, even for RHEL 7. This will still be a disruptive update from caddy v1 to v2, but users can opt-in to it at their own pace if they are unable/unwilling to migrate away from RHEL 7 yet. Caddy is also available in EPEL 9, and will be available in EPEL 8 soon [7], so upgrading to RHEL 8 or 9 is another possible route if users are ready to migrate their OS. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons [1] https://nvd.nist.gov/vuln/detail/CVE-2022-3064 [2] https://nvd.nist.gov/vuln/detail/CVE-2022-41717 [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-284c34a6cc [4] https://pagure.io/releng/issue/11606 [5] https://caddyserver.com/docs/install#fedora-redhat-centos [6] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ [7] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163 -- Carl George ___ 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: Please branch and build libusbauth-configparser, usbauth and usbauth-notifier in epel9
On Sat, Jul 29, 2023 at 5:15 AM Stefan Koch wrote: > > Hi > > Please branch and build libusbauth-configparser, usbauth and usbauth-notifier > in epel9. > Package are already in epel8. > > There was no response to the following Bugs within 6 months: > > - Please branch and build libusbauth-configparser in epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161706 > > - Please branch and build usbauth epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161707 > > - Please branch and build usbauth-notifier in epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161708 > > Thanks > > Stefan > ___ > 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 Howdy Stefan, You appear to be the sole maintainer of all three of those packages, as well as the most recent committer and assignee for the bugs. Package maintainers can create branches with fedpkg, e.g. `fedpkg request-branch epel9`. https://docs.fedoraproject.org/en-US/epel/fedora-package-in-epel/ -- Carl George ___ 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: Proposed incompatible security update for llhttp in EPEL9
Thanks Ben for following the incompat process and for the detailed email. It makes sense to me, the plan is sound, and I plan to vote yes when we hold the official vote in next week's steering committee meeting. On Wed, Aug 9, 2023 at 1:35 PM Troy Dawson wrote: > > On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley wrote: >> >> This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to >> 8.1.1, which would break the ABI and bump the SONAME version, under the >> EPEL Incompatible Upgrades Policy[1]. >> >> The llhttp package is a C library (transpiled from TypeScript) that >> provides the low-level HTTP support for NodeJS and for python-aiohttp. >> Currently, only python-aiohttp depends on the llhttp package in EPEL9. >> >> Versions of llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an >> HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated >> Moderate by Red Hat. The GitHub advisory for llhttp is >> GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is >> GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by >> updating llhttp (which they bundle, but we unbundle) in release 3.8.5. >> >> I am not comfortable attempting to backport the fix to an older release >> of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] >> and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI >> break in llhttp would only affect python-aiohttp; the python-aiohttp >> update itself is compatible (by upstream intent, and verified in >> COPR[7]); and a number of packages that depend on python-aiohttp would >> benefit from the fix. >> >> If this exception request is not approved, my fallback plan is to >> propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, >> which would convert it to a pure-Python package. This is a documented >> mitigation, but comes with potentially serious performance regressions, >> again affecting a number of dependent packages. The llhttp package would >> become a leaf package and would remain unpatched. >> >> The same incompatible update was approved by FESCo for Fedora 37[8]. >> >> The purpose of this email is to document and explain the proposed >> update, to begin the minimum one-week discussion period mandated by the >> EPEL Incompatible Upgrades Policy, and to request that the update be >> added to the agenda for an upcoming EPEL meeting. >> >> [1] >> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades >> >> [2] https://access.redhat.com/security/cve/CVE-2023-30589 >> >> [3] https://github.com/advisories/GHSA-cggh-pq45-6h9x >> >> [4] >> https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w >> >> [5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14 >> >> [6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26 >> >> [7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/ >> >> [8] https://pagure.io/fesco/issue/3049 > > > Thank you for the nice write-up. > > I have created an EPEL issue. Not really for discussion but more for voting > and make sure this is on the meeting agendas. > https://pagure.io/epel/issue/241 > > Troy > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
gt; > Then for epel7 the rpm's would have the original option turned off, but > > > for > > > > epel8 and 9 the option could be there and update wouldn't be a breaking > > > > update. > > > > > > > > That would allow users that have machines on RHEL 7,8 and 9 to use the > > > same > > > > version and secure options. > > > > Users that only have machines on RHEL 8 and 9, would then have the > > > > option > > > > to move to the more secure option when the time is good for them. > > > > > > > > Troy > > > > > > > > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel < > > > > epel-devel@lists.fedoraproject.org> wrote: > > > > > > > > > The NVD analysis at > > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > > > > > is now finished and they agreed with the impact score that I gave it. > > > > > They ended up with an even higher rating because they said the attack > > > > > complexity was low. I think the complexity is high, but in either > > > case the > > > > > overall severity is rated High. > > > > > > > > > > Dave > > > > > > > > > > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > > > > > > DT, > > > > > > > > > > > > I am not all arguing that CVE-2022-1184 impact score was incorrect. > > > I > > > > > can't imagine why you think that. > > > > > > > > > > > > By itself, CVE-2022-1184 is not a privilege escalation, because it > > > can > > > > > normally only be exploited by someone with write access to the > > > filesystem > > > > > boots, that is, root. Only with setuid-root apptainer/singularity > > > does it > > > > > become a privilege escalation. > > > > > > > > > > > > I have said that I think that CVE-2022-1184's "Privileges Required" > > > was > > > > > incorrect. It was you who suggested USB automounts being available to > > > > > users may have been their reason for setting it to "low". If that's > > > what > > > > > they meant, then I think it makes perfect sense that they don't count > > > that > > > > > as a privilege escalation because physical access already gives > > > privilege > > > > > escalation in much easier ways. I said that that's probably why they > > > only > > > > > counted it as denial of service since that was the only thing new. > > > > > > > > > > > > Dave > > > > > > > > > > > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > > > > > > Dave, > > > > > > > > > > > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel > > > wrote: > > > > > > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > > > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > > > > > > > ... > > > > > > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same > > > > > breakdown as the > > > > > > > > > > > NVD CVSS score. Both rate the "privileges required" > > > property > > > > > as low. > > > > > > > > > > > From what I can tell that property would be rated high if > > > they > > > > > > > > > > > considered root privileges to be required. How does > > > > > apptainer's use > > > > > > > > > > > of setuid change anything here? > > > > > > > > > > > > > > > > > > > > According to the explanation I received from the ext4 kernel > > > > > developer, > > > > > > > > > > Red Hat's CVSS rating was incorrect on that property. > > > Without > > > > > singularity > > > > > > > > > > or apptainer it does require high privileges to exploit. > > > >
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel wrote: > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel > ... > > > The summary of the CVE is that the way that apptainer & singularity > > > allow mounts of ext3 filesystems in setuid mode raises the severity of > > > many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 > > > driver). OS vendors consider those CVEs to be low or moderate priority > > > because they assume that users do not have write access to the > > > underlying bits of the filesystem, but apptainer/singularity setuid mode > > > gives that access to users by default (before this release of apptainer). > > > Since vendors don't see urgency to patch low/moderate CVEs, it can take > > > a very long time for them to patch them and in fact RHEL7 is not patched > > > for one in particular. All this information came from a reliable source, > > > the owner of the ext4 kernel driver. > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > NVD CVSS score. Both rate the "privileges required" property as low. > > From what I can tell that property would be rated high if they > > considered root privileges to be required. How does apptainer's use > > of setuid change anything here? > > According to the explanation I received from the ext4 kernel developer, > Red Hat's CVSS rating was incorrect on that property. Without singularity > or apptainer it does require high privileges to exploit. Red Hat's CVSS score breakdown for CVE-2022-1184 is: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H You're suggesting that Red Hat's rating should have been higher because they didn't factor in low privileges, but that is objectively false because they did score it with low privileges. If they had scored it for high privileges, that would have dropped the rating down from 5.5 to 4.4. There is no reason to believe that CVE-2022-1184 should have been marked as higher impact than it was, and thus I see no reason to justify the likely duplicate CVE-2023-30549 as high. https://access.redhat.com/security/cve/CVE-2022-1184 https://nvd.nist.gov/vuln/detail/CVE-2022-1184 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > I am sorry to see that I have already done one step too many according > > > to the incompatible changes policy, and have made the release available > > > to epel-testing. However, I think it's important to make it available > > > that way for system administrators to install early. The large High > > > Energy Physics community that I represent has security teams that want > > > to be able to notify their site administrators to upgrade to respond to > > > this high severity CVE, and it would be so much better if the > > > announcement they send can say to install from epel-testing rather than > > > having to provide URLs to download from koji. > > > > You can't just ignore the policy because you feel it's important to > > make a particular update available quickly. If you feel the policy > > needs to allow for things to be done in that order, propose a change > > to the policy. > > The policy does already say parenthetically that a short-circuit is > needed for security updates. I will propose a change to make such a > short-circuit. > > > > So, to the EPEL Steering Committee members: must I unpublish this update > > > from testing, or may I leave it there and send an announcement to > > > epel-announce that it is there and pending approval by the committee? > > > The bodhi settings are set so they won't get auto-updated by karma or > > > time. > > > > We discussed this earlier today at the Steering Committee meeting. No > > one seemed to have an issue with allowing these updates to stay in the > > testing repo until we vote on it next week. Next time, follow the > > policy steps correctly. > > Thank you, I will do that. I apologize for starting off on the wrong > foot. I neglected to read the policy again in my focus on getting the > release done. > > Dave > ___ > 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,
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel wrote: > > We believe that it is important to apply this change to all EPEL releases, > for these reasons: > 1. The general vulnerability described in this CVE applies equally to all > currently supported Linux distributions. The Singularity/Apptainer CVE-2023-30549 only applies to apptainer on RHEL 7 because the underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and 9. > community has long been aware that making setuid-root kernel > filesystem mounts available to all users has been a risk, because > https://lwn.net/Articles/652468/ briefly explained that kernel > developers considered that to be a great risk. System admins have > been willing to live with the risk because (a) nobody had identified > an attack, (b) the functionality was so useful, especially the > squashfs mounts, and (c) there wasn't an alternative. With the new > information from the ext4 kernel filesystem owner, we now have more > specifics on how the attack can be done including an example > vulnerability, the ext3 mounts aren't as widely used as squashfs, > and Apptainer has an alternative using unprivileged user namespaces. > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default, > so the functionality will still be available to most of the users. > It does not automatically switch to the alternative, but there's a > clear error message saying that it is disabled by configuration and > suggesting that users add the --userns option (and of course if > apptainer-suid is not installed it uses the user namespace mode > automatically). > 3. It is important to have consistency across platforms, since users and > administrators often use more than one and it would be confusing to > have different behavior on different platforms. Admins can also If consistency across platforms is important, then it seems prudent to avoid this incompatible update across all three platforms, especially this late in the RHEL 7 lifecycle. > install the rpm on RHEL8 & 9 directly from github, and it would not > be good to have different behavior when installed from EPEL. > > Dave > > > On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote: > ... > > EPEL 9: > > > > RHEL 9 has the fix for CVE-2022-1184. CVE-2023-30549 requires > > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > > incompatible update for apptainer in EPEL 9. Apptainer in EPEL 9 > > should be modified to set the "allow setuid-mount extfs" option to yes > > for compatibility, even if that isn't the upstream default. > > > > EPEL 8: > > > > RHEL 8 has the fix for CVE-2022-1184. CVE-2023-30549 requires > > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > > incompatible update for apptainer in EPEL 8. Apptainer in EPEL 8 > > should be modified to set the "allow setuid-mount extfs" option to yes > > for compatibility, even if that isn't the upstream default. > > > > EPEL 7: > > > > RHEL 7 appears to be vulnerable to CVE-2022-1184. CVE-2023-30549 > > requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it > > actually impacts the EPEL 7 apptainer package. This CVE has not yet > > been rated by NVD. If the NVD assigns a rating of high (matching the > > CNA suggestion) or critical, I would be agreeable to an incompatible > > update of apptainer in EPEL 7. If the NVD assigns a rating of medium > > (matching CVE-2022-1184) or low, I would be opposed to an incompatible > > update of apptainer in EPEL 7. > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > ___ > 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 -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
gt; >> ___ > >> 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 > > > > > > -- > > Jonathan Wright > > AlmaLinux Foundation > > Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan> > > ___ > > 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 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 Thanks everyone for the detailed information provided so far. We should evaluate each of these updates separately since the conditions surrounding them are not the same across the board. EPEL 9: RHEL 9 has the fix for CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched. Because of this I'm opposed to an incompatible update for apptainer in EPEL 9. Apptainer in EPEL 9 should be modified to set the "allow setuid-mount extfs" option to yes for compatibility, even if that isn't the upstream default. EPEL 8: RHEL 8 has the fix for CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched. Because of this I'm opposed to an incompatible update for apptainer in EPEL 8. Apptainer in EPEL 8 should be modified to set the "allow setuid-mount extfs" option to yes for compatibility, even if that isn't the upstream default. EPEL 7: RHEL 7 appears to be vulnerable to CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it actually impacts the EPEL 7 apptainer package. This CVE has not yet been rated by NVD. If the NVD assigns a rating of high (matching the CNA suggestion) or critical, I would be agreeable to an incompatible update of apptainer in EPEL 7. If the NVD assigns a rating of medium (matching CVE-2022-1184) or low, I would be opposed to an incompatible update of apptainer in EPEL 7. https://nvd.nist.gov/vuln/detail/CVE-2023-30549 -- Carl George ___ 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
Re: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 12:24 AM Benson Muite wrote: > > On 4/21/23 04:24, Chris Adams wrote: > > Once upon a time, Matthew Miller said: > >> I am proposing that over the course of 2023, starting with the Changes > >> process, we move Fedora development conversations from this mailing list to > >> the Discourse-based Fedora Discussion. > > > > I feel this is a case of trading one group of people (email list users) > > for a different group of people (web forum users). I have seen this > > done multiple times over the years, tried to follow a few times, and > > always dropped off fairly rapidly. I'm solidly in the "email list > > users" group. > Discourse is very nice. It is open source, uses a reasonable license > [0] (though [1] would be better), and is great for casual interactions > that maybe spread out over time. Would highly recommend it for moderate > size community discussion. > > However, it doesn't seem like we can hack on it to better suite > community needs, for example to have the same functionality as mailing > lists[2]. It is not standards driven and is primarily developed by one > company - something that follows Apache way[3] or has a community > governance process would be better in the long term for a large project > with many contributors who have technical expertise. > > Email clients offer significant customizability that a one size fits all > web interface cannot provide. Mailing list mode for Discourse is > helpful, but not at the same level as email lists, where once one has > gained sufficient knowledge, interaction can be done from the comfort of > the client of your choice. As such, simply adopting it because it can be > deployed may leave out many contributors, in particular those who drive > development forward. Mailing lists are not perfect, but it is not clear > Discourse is a good replacement for the devel list. As Matthew stated, Ben has measured it and fewer people are participating on the mailing list over time. We are already leaving out many contributors. Those conversations are largely moving to issue trackers, which are also not perfect but are clearly more appealing than email for many people. Discourse has the potential to be a more attractive alternative than both email and issue trackers. To me this seems like a solid strategy for reversing the trend and getting more people participating in development discussions. > > 0) https://github.com/discourse/discourse/blob/main/LICENSE.txt > 1) https://www.gnu.org/licenses/agpl-3.0.en.html > 2) > https://discourse.cmake.org/t/cmake-discourse-mailing-list-mode-incorrectly-personally-addresses-all-email/738 > 3) https://apache.org/theapacheway/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
On Thu, Apr 20, 2023 at 8:25 PM Chris Adams wrote: > > Once upon a time, Matthew Miller said: > > I am proposing that over the course of 2023, starting with the Changes > > process, we move Fedora development conversations from this mailing list to > > the Discourse-based Fedora Discussion. > > I feel this is a case of trading one group of people (email list users) > for a different group of people (web forum users). I have seen this > done multiple times over the years, tried to follow a few times, and > always dropped off fairly rapidly. I'm solidly in the "email list > users" group. > > Web forums far from fit how I use communication tools. For example, I'm > highly keyboard driven and dislike lots of things that force me to use a > mouse. I use mutt to read email, which works great. I have email > filters to organize and save things, I can flag messages for later > review/reference, and more. > > Web forums also seem in my experience to be much more casual > interaction, where people come and go for long stretches of time, much > more than email lists. If I just don't click on your bookmark for a day > or two, it's out of mind quickly and I might not come back for weeks or > months (or ever, which is usually the case). And then even if I do come > back, now I'm pretty much too far behind to ever catch up. That cuts both ways. If I just don't click on [email filter folder] for a day or two, it's out of mind quickly and I might not come back for weeks or months. And then even if I do come back, now I'm pretty much too far behind to ever catch up. > > I guess you're hoping for enough overlap between email and web forum > users to keep an active developer community... I wish you luck with > that. > > -- > Chris Adams > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: It’s time to transform the Fedora devel list into something new
the announcement lists to stay for the foreseeable future > (although we might feed them from Discourse rather than the other way > around). Other lists which are patches, commit messages, and other > automations might stick around for a while — but really might be better > served by a log aggregation and analysis system or something else. > > Other teams who want to keep mailing lists can, but I’d like to move > those too, and eventually I think we’ll want to shut them down too — or > perhaps convert them to announcement lists. > > > Next steps > -- > > I know this is a big change. I’ve been thinking of writing this message > for a long time. I’d really like to convince everyone that it’s the > right thing — or at least, an acceptable one. > > > What about specific decisions related to my proposal? For each: > > Because altering the Changes process is a FESCo decision, I’ll file a > ticket about that shortly. > > FESCo moving their own other conversations is, of course, also a FESCo > decision. > > Assuming the first moves forward, I will create the general #devel tag > (or other name we come up with) when I create the #change-proposal tag. > > Moving the packaging list is a Packaging Committee decision. > > Automated posts can be moved at any time. I can work with the people > who own the generation of those reports to figure out a good answer for > each. > > The outcome for other team lists is up to each team. > > And, I think shutting down devel overall is ultimately a Fedora Council > decision. > > For right now, though: let’s discuss — on the list! > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/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?
That sounds great, thanks. On Thu, Mar 30, 2023, 8:28 AM Troy Dawson wrote: > It doesn't look like they've done their merge yet, so I'll see if I can > get your change in. > How does this sound? > > Subject: > Notice: will be automatically retired from EPEL when > RHEL . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. Please do not update in > EPEL so the RHEL version can have a higher version and release. > When RHEL . is released, EPEL automation will remove > from EPEL and close this bug. > > > On Tue, Mar 28, 2023 at 9:14 AM Carl George wrote: > >> I'm also late to the party with this feedback, but just in case it's >> not too late to include, can we include something about not updating >> the package further? Beyond just "you do not need to take any >> action", we should advise against making any changes at that point, as >> often the RHEL package will be exactly one release higher than the >> current EPEL package, and updating the EPEL package further (either >> release or version) will screw up the upgrade path. >> >> On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: >> > >> > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok >> wrote: >> >> >> >> On 20. 03. 23 12:20, Neal Gompa wrote: >> >> >> I could think of other reasons as well. E.g. it's not important for >> customers >> >> >> but it's important for Red Hat. Or maybe it is a not-so-important >> dependency of >> >> >> something else. >> >> >> >> >> > Does Red Hat have any other motivation with RHEL other than a >> customer >> >> > needing the functionality? Those other reasons are generally driven >> by >> >> > someone needing it. >> >> >> >> See e.g. https://bugzilla.redhat.com/2175213 >> > >> > >> > 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. >> > It looks like this change still hasn't been merged in so I'll see if I >> can get a change in. How about this? >> > >> > Subject: >> > Notice: will be automatically retired from EPEL when >> RHEL . is released >> > >> > Comment: >> > >> > This issue is purely informational, you do not need to take any >> action. Thank you for your work maintaining in EPEL . >> Red Hat considers this package important enough to promote it to official >> RHEL. It will be part of RHEL .. When that is released, >> EPEL automation will remove from EPEL and close this bug. >> > >> > ___ >> > 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 >> >> >> >> -- >> Carl George >> ___ >> 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 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 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
orphaning golang-github-exoscale-egoscale
I just orphaned golang-github-exoscale-egoscale. I'm no longer interested in maintaining it. It's up for grabs for any interested parties. Do note that currently it fails to install in F39 [0] because one of its dependencies was retired [1], so that will need to be sorted out to keep the package around. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2176050 [1] https://src.fedoraproject.org/rpms/golang-github-deepmap-oapi-codegen/c/2792c7c77ff7815f82a942a944ccf48f0401c0a1?branch=rawhide -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/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?
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path. On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: > > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok wrote: >> >> On 20. 03. 23 12:20, Neal Gompa wrote: >> >> I could think of other reasons as well. E.g. it's not important for >> >> customers >> >> but it's important for Red Hat. Or maybe it is a not-so-important >> >> dependency of >> >> something else. >> >> >> > Does Red Hat have any other motivation with RHEL other than a customer >> > needing the functionality? Those other reasons are generally driven by >> > someone needing it. >> >> See e.g. https://bugzilla.redhat.com/2175213 > > > 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. > It looks like this change still hasn't been merged in so I'll see if I can > get a change in. How about this? > > Subject: > Notice: will be automatically retired from EPEL when RHEL > . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. When that is released, EPEL automation > will remove from EPEL and close this bug. > > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Wed, Mar 8, 2023 at 9:43 AM Troy Dawson wrote: > > > > On Wed, Mar 8, 2023 at 6:31 AM Troy Dawson wrote: >> >> On Tue, Mar 7, 2023 at 7:16 PM Carl George wrote: >>> >>> On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson wrote >>> > >>> > RHEL has been very good (lately) about their NVR's being higher than >>> > EPEL's. >>> > If that is so, the EPEL packages don't take precedence over RHEL's. >>> >>> They may not when you first check. The risk in leaving the branch >>> active is that a maintainer may bump the version and/or release and >>> start overriding the RHEL package at any given time. We don't >>> currently have a mechanism to freeze the distgit branch but leave the >>> package in the repo. Our current calculus is "if the package is in >>> RHEL, it needs to be promptly retired from EPEL". Leaving packages >>> longer means that someone needs to continually check that the >>> duplicating packages haven't started overriding their RHEL equivalent. >> >> >> Before I dig through all my emails, let me ask if you have got any examples >> of EPEL packagers updating a package after RHEL has released it? >> (Within a reasonable time frame, which is to say a month after the release) The most recent example I remember is python-sqlalchemy. It was available in EPEL 9 at version 1.4.37. That same version was added to CentOS Stream 9 in preparation to go into RHEL 9.1. The EPEL maintainer didn't notice the retirement warning bug and continued to update the package to newer versions in EPEL 9. It made it up to version 1.4.44 before it was retired. That last update to 1.4.44 was pushed to stable on 2022-11-23, eight days after the RHEL 9.1 release. Anyone that had it installed previously won't get upgraded to the RHEL 9.1 package which is still at version 1.4.37. Thankfully the RHEL maintainer agreed to rebase it in RHEL 9.2 to eventually resolve the upgrade path. https://bugzilla.redhat.com/show_bug.cgi?id=2098498 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cee8cb8dc1 https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/KGKSCFABQE6MJ5F4RKR3HUXW73GGTSU6/ https://bugzilla.redhat.com/show_bug.cgi?id=2152649 It's happened before, and I'd like to minimize the window where it can happen again in the future. I understand wanting to be courteous to rebuild users, but we need to find the right balance. > > > I'm sorry, it's sounding like I'm trying to argue with you, and I'm not. > I just have no idea why you feel packagers updating after RHEL has released a > package is a problem. It's not just updating after RHEL, it's updating the package to a higher NVR than what RHEL plans to release, as we saw in the sqlalchemy example. > Back before we started doing this EPEL2RHEL, we did have a problem, and that > was because many packagers had no idea that their package was in RHEL. > Since we started EPEL2RHEL we've had the opposite problem. They get so > excited about not having to maintain the package that they drop it too soon. > If I've missed things, please let me know. Because I feel like I'm not > seeing a problem that you are seeing. > >> >> Beyond the reasoning about timing, here's my other problem. >> In the script I'm writing, I can't check if a package has been released by >> RHEL, I can only check if a package has been released by Alma and/or Rocky. >> It's the same reason that willit is only checking against Alma. >> The whole subscription problem. >> >> Troy >> > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson wrote: > > > > On Tue, Mar 7, 2023 at 11:38 AM Carl George wrote: >> >> On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson wrote: >> > >> > On Mon, Mar 6, 2023 at 8:48 PM Carl George wrote: >> >> >> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé >> >> wrote: >> >> > >> >> > >> >> > There is also the case of the RHEL rebuilds whose users consume EPEL >> >> > packages. Depending how quick they are, the rebuild distros might not >> >> > have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2 >> >> > is first available. My projects' upstream CI is all based on AlmaLinux >> >> > and I don't want to see it broken again by premature capstone retirement >> >> > from EPEL. >> >> >> >> Historically, when CentOS was a rebuild, many EPEL maintainers would >> >> wait for corresponding CentOS rebuild release before changing their >> >> EPEL packages to work on RHEL. This was true both for soname rebuilds >> >> and retirements. CentOS would usually take about a month to catch up >> >> to RHEL minor versions. The new rebuilds are doing much better in >> >> this area. Alma is routinely getting their minor versions out 1-2 >> >> days after RHEL. The other rebuilds aren't far behind. If we were to >> >> delay package retirements, I don't think it's necessary to delay for >> >> more than a few days. >> > >> > >> > Do you mean "a few days after both Alma and Rocky are up to the latest >> > release." or "a few days after RHEL is released."? >> > >> > If you mean "a few days after RHEL is released." then I have to disagree >> > with you. >> > It does no harm to leave the packages in EPEL for a few weeks/months. >> > It does harm to rip the packages out too early. >> >> I do mean a few days after a RHEL release. Between the distgit >> retirement, compose, and mirror sync delay, the package doesn't become >> unavailable for nearly a business week (~5 days). > > > We already know this isn't true. > We've had packagers accidentally retire packages early and people get hit > literally the next day. Got any examples of this "next day" timing? The problem in the bugzilla linked at the start of this thread was that the retirement took place long before the package was in RHEL. I don't see any mention in the bug of observing the lack of the package on the mirrors, just discussion spurred by the maintainer commenting that he performed the retirement. Anecdotally I recall there being at least several days delay between retirement and the rare complaints about the package not being available in EPEL anymore. If users are consistently seeing the effects of a retirement the next day, then of course waiting a little bit longer could make sense. > > >> >> Users that already >> have the package installed are unaffected. If a user is using a RHEL >> rebuild that hasn't got their release done yet by that point, the only >> effect is that the package is unavailable in the EPEL repo, but it's >> still available for manual download from Koji or the snapshot >> archives. Harm is far too strong a word for this. It's a temporary >> annoyance that can be resolved by several workarounds, including >> switching to a rebuild that gets releases done faster. >> >> It's important that EPEL packages don't take precedence over RHEL >> packages, and you said yourself it's too difficult to continuously >> monitor which packages are a lower NVR than their RHEL equivalent and >> allow them to stay longer. EPEL targets RHEL, and we should minimize >> any delay of correcting issues that violate the core principle of >> EPEL. > > > RHEL has been very good (lately) about their NVR's being higher than EPEL's. > If that is so, the EPEL packages don't take precedence over RHEL's. They may not when you first check. The risk in leaving the branch active is that a maintainer may bump the version and/or release and start overriding the RHEL package at any given time. We don't currently have a mechanism to freeze the distgit branch but leave the package in the repo. Our current calculus is "if the package is in RHEL, it needs to be promptly retired from EPEL". Leaving packages longer means that someone needs to continually check that the duplicating packages haven't started overriding their RHEL equivalent. > I don't see the need for a rush. > You seem like you are going for the lett
[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases
On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson wrote: > > On Mon, Mar 6, 2023 at 8:48 PM Carl George wrote: >> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé >> wrote: >> > >> > >> > There is also the case of the RHEL rebuilds whose users consume EPEL >> > packages. Depending how quick they are, the rebuild distros might not >> > have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2 >> > is first available. My projects' upstream CI is all based on AlmaLinux >> > and I don't want to see it broken again by premature capstone retirement >> > from EPEL. >> >> Historically, when CentOS was a rebuild, many EPEL maintainers would >> wait for corresponding CentOS rebuild release before changing their >> EPEL packages to work on RHEL. This was true both for soname rebuilds >> and retirements. CentOS would usually take about a month to catch up >> to RHEL minor versions. The new rebuilds are doing much better in >> this area. Alma is routinely getting their minor versions out 1-2 >> days after RHEL. The other rebuilds aren't far behind. If we were to >> delay package retirements, I don't think it's necessary to delay for >> more than a few days. > > > Do you mean "a few days after both Alma and Rocky are up to the latest > release." or "a few days after RHEL is released."? > > If you mean "a few days after RHEL is released." then I have to disagree with > you. > It does no harm to leave the packages in EPEL for a few weeks/months. > It does harm to rip the packages out too early. I do mean a few days after a RHEL release. Between the distgit retirement, compose, and mirror sync delay, the package doesn't become unavailable for nearly a business week (~5 days). Users that already have the package installed are unaffected. If a user is using a RHEL rebuild that hasn't got their release done yet by that point, the only effect is that the package is unavailable in the EPEL repo, but it's still available for manual download from Koji or the snapshot archives. Harm is far too strong a word for this. It's a temporary annoyance that can be resolved by several workarounds, including switching to a rebuild that gets releases done faster. It's important that EPEL packages don't take precedence over RHEL packages, and you said yourself it's too difficult to continuously monitor which packages are a lower NVR than their RHEL equivalent and allow them to stay longer. EPEL targets RHEL, and we should minimize any delay of correcting issues that violate the core principle of EPEL. This should all be much simpler in EPEL 10. Package retirement will be per-minor-release. We'll be able to actually follow the guidelines in CentOS Stream, retiring the package in that EPEL repo without affecting RHEL users. When a new RHEL minor version happens, they'll switch from an EPEL repo that has the package to an EPEL repo that doesn't have the package (but it will be available in RHEL at that point). Anyone using an older minor version (whether EUS, a manually pinned release, or a RHEL rebuild that is lagging) can explicitly point to the EPEL repo that matches their minor version by passing the `--releasever` flag to dnf with the appropriate value. > > Troy > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Fri, Mar 3, 2023 at 11:57 AM Nick Howitt via epel-devel wrote: > > On 03/03/2023 15:33, Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote: > > We are currently in the middle of changing the workflow of retiring these > packages. We are changing it so that the package maintainer doesn't do the > removing. It will be automated, or semi-automated, so there is a > consistent time when all of them are removed. > > That's a good idea. > > When do you actually remove the packages from the EPEL repository? > It has been agreed that it will be after both Alma and Rocky have their > latest release out. > > Ok, that's good, and should at least avoid breaking my upstream CI > use case since our containers should transparently start receiving > the 9.2 content when Alma releases their rebuilt container iamges. > > But how long after? > Immediately after? a month? 6 months? > > I personally am leaning towards a month after. > Here is my reasoning. > At the time a new RHEL release is released, we take a snapshot of the EPEL > repo and put it in the archives. > So all the packages that were built, and run on RHEL 9.1 are available in > that archive. > > snip > > Anyway, if some users are still doing new installs of RHEL 9.1 (or > compatible) after that month, then they should probably add the epel 9.1 > archive to their yum repositories. > > That's interesting, I didn't know about the y-stream archive > snapshots. > > Is there any mileage in considering a way to make the use of the epel > 9.1 archive automatic so users don't have risk of breakage needing manual > reconfiguration to keep working ? > > eg perhaps have 2 yum repos provided and enabled by epel-release. One > repo URL always the latest release and one repo URL always the current > 9.x release number, with a lower priority number set. The latter repo > initially empty of packages, but at the start of 9.2 it receives the > snapshot of 9.1 content, and so becomes dominent over the former repo > which will henceforth be holding 9.2 content. > > With regards, > Daniel > > Is this one of those cases where it would be better not to use an el9 package > suffix but something alphanumerically lower than el9, then Redhat's packages > would always take priority if they come along? Changing the disttag to sort lower will only have an effect if the RHEL package has the exact same version and release digit as the EPEL package. This almost never happens in practice. The RHEL maintainer is much more likely to select an older version for specific reasons or choose the same version with a higher release to provide a clean upgrade path. > > Nick > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Fri, Mar 3, 2023 at 9:33 AM Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote: > > We are currently in the middle of changing the workflow of retiring these > > packages. We are changing it so that the package maintainer doesn't do the > > removing. It will be automated, or semi-automated, so there is a > > consistent time when all of them are removed. > > That's a good idea. > > > When do you actually remove the packages from the EPEL repository? > > It has been agreed that it will be after both Alma and Rocky have their > > latest release out. > > Ok, that's good, and should at least avoid breaking my upstream CI > use case since our containers should transparently start receiving > the 9.2 content when Alma releases their rebuilt container iamges. > > > But how long after? > > Immediately after? a month? 6 months? > > > > I personally am leaning towards a month after. > > Here is my reasoning. > > At the time a new RHEL release is released, we take a snapshot of the EPEL > > repo and put it in the archives. > > So all the packages that were built, and run on RHEL 9.1 are available in > > that archive. > > snip > > > Anyway, if some users are still doing new installs of RHEL 9.1 (or > > compatible) after that month, then they should probably add the epel 9.1 > > archive to their yum repositories. > > That's interesting, I didn't know about the y-stream archive > snapshots. > > Is there any mileage in considering a way to make the use of the epel > 9.1 archive automatic so users don't have risk of breakage needing manual > reconfiguration to keep working ? The current EPEL snapshot archives are flawed. They are done manually when Fedora Releng remembers. It has happened where packages made it into a snapshot labeled "EPEL X.Y" that were actually built against RHEL X.Y+1. We're actually planning a more robust and holistic approach to solving this problem for EPEL 10. The full proposal is over on Fedora Discussion. I cross posted it to this list back in November. Last month the EPEL Steering Committee approved the general direction of the plan (without commiting to exact implementation details). Please check it out and share your thoughts. https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > > eg perhaps have 2 yum repos provided and enabled by epel-release. One > repo URL always the latest release and one repo URL always the current > 9.x release number, with a lower priority number set. The latter repo > initially empty of packages, but at the start of 9.2 it receives the > snapshot of 9.1 content, and so becomes dominent over the former repo > which will henceforth be holding 9.2 content. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
er to Y-stream work, they're talking about work in CentOS Stream in preparation for the next RHEL minor version. > > Solutions to the problems have to take all three of those impediments into > consideration to be done. My attempt with EPEL-playground in 8 broke down on > (2) Fedora packagers not having the capacity to deal with different workflows > and (1) infrastructure limits. EPEL-Next seems to be running into 1, 2 and 3. > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. -- > Ian MacClaren > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
r that delays updating, many more are updating at their first opportunity in order to stay current. > > > > The package added to RHEL should (must) have a newer NEVR than the > existing package in EPEL, so even if we leave it in EPEL, it will > be ignored if the newer version is present in RHEL repos. The current "retire immediately" stance originated at a time when RHEL did less coordination with EPEL, and there was no CentOS Stream to publicly see what was planned for the next minor version. It was common for RHEL to choose an older NVR than what was available in EPEL, or for the EPEL maintainer to continue to do version/release bumps after a version had been selected to bake into the next RHEL minor version. Either way resulted in EPEL having a higher NVR than what ended up in RHEL. This necessitated quick retirement so that users that were on the current RHEL minor versions got the RHEL package, not the EPEL package. EPEL's core principle is to only be extra packages and not disturb or replace RHEL packages. We also are not able to mandate what RHEL ships. If they choose to ship foo 2.5, but EPEL has been shipping foo 3.1, foo still must be retired from EPEL. > > The main important thing I see is that the EPEL branch in dist-git > must be made read-only and/or prevented from submitting new builds, > once the package has been built in CentOS Stream. ie to ensure the > EPEL NEVR doesn't creep back above the pending RHEL package's NEVR. As far as I know we don't currently have a mechanism to do this in the current structure. The only mechanism to prevent changes to the distgit branch and prevent new builds is retirement, which also removes the package from the repo. > > > If that's done it should be fine to leave it in EPEL for a prolonged > period after 9.2 is released, to allow sufficient time for users to > actually switch from deploying 9.1 over to 9.2. > > I guess someone might say that EPEL only targets the very latest > y-stream of RHEL, so continuing to use 9.1 after 9.2 is released > is unsupported ? Even if that is technically the case, I think > in practice users won't take that into account, and thus expect > it to keep working and generally that should be fine. Only if a > EPEL package is rebuilt such that it depends on a newly added > API/ABI is that a problem. Other than nitpicking over the over-loaded term "support", I would say that's accurate. We don't have to theorize about this, as this already happens in practice. Oftentimes EPEL packages install correctly on older minor versions. When they don't, we see users file bugs or ask in communication channels about the error they see. They're informed that EPEL only targets the current minor versions,and then directed towards the koji history, the archive snapshots, or the spec file to build it themselves. It's a thing that happens periodically, and I wouldn't characterize it as overwhelming. Typically the response is "oh yeah I know I need to get updated to the current minor version". > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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 -- Carl George ___ 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
Re: ImageMagick 7 is landing in Rawhide
Autotrace supports building against GraphicsMagick, so I sent a pull request to switch it to that. https://src.fedoraproject.org/rpms/autotrace/pull-request/3 On Fri, Jan 6, 2023 at 3:45 PM Neal Gompa wrote: > > Hey all, > > The initial rebase of ImageMagick to v7 is landing in Rawhide now: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9d3e9afbfd > > Most packages in the reverse dependency chain were rebuilt, though a > few are still left to fix and will be addressed separately. > > The ones remaining are: > > * autotrace (contacting upstream planned) > * q (dead upstream, orphaned) > * vdr-scraper2vdr (maybe dead upstream?) > * vdr-skinnopacity (dead upstream) > * vdr-tvguide (dead upstream) > > Either these will switch to GraphicsMagick or we'll introduce an > ImageMagick6 compatibility package for them. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Updating tox to 4 in EPEL 9
I would prefer using the incompat process [0] to upgrade epel9's python-tox to version 4, and introducing a python-tox3 compat package. We could use the same naming scheme in Fedora if it makes any sense to keep tox 3 around there for some period of time. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ On Wed, Dec 14, 2022 at 8:45 AM Miro Hrončok wrote: > > Hello folks. > > A new major version of tox was released. The bump form version 3 to version 4 > should be flawless to users but breaks all the plugins that have not been > updated to the new API yet. > > I would like to avoid the need to maintain tox 3 in EPEL9 for many years after > upstream abandoned it (they have no intention to do maintenance releases for > tox 3.x). > > We are currently upgrading to tox 4 in Fedora Rawhide. When the dust settles > I'd like to have the possibility to update it in EPEL too. > > One way to do it is to package a new tox4 component in EPEL 9 (and make it > conflict with tox < 4) and keep the old tox around until it breaks (the > breakage might mean it no longer supports a newly added Python version being > added to RHEL 9). > > Is that a sensible approach for EPEL? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ 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] retirement of python-pyghmi in EPEL 8
python-pyghmi was added to RHEL 8.5 [0]. Per EPEL policy [1][2], it must be retired from EPEL 8. The version-release of the RHEL 8 package (1.5.29-1.el8) is higher than the last one provided in EPEL 8 (1.5.19-2.el8), so there is a clean upgrade path. The only loss of functionality is that EPEL 8 included the python-pyghmi-doc and python3-pyghmi-tests subpackages, but these were not included in RHEL. Nothing else in EPEL 8 depends on these subpackages. [0] https://access.redhat.com/errata/RHEA-2021:4331 [1] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_package_in_rhel -- Carl George ___ 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] retirement of python-tornado in EPEL 9
python-tornado has been added to RHEL 9.1 [0]. Per EPEL policy [1][2], it must now be retired from EPEL 9. The version-release of the RHEL 9 package (6.1.0-8.el9) is higher than the last one provided in EPEL 9 (6.1.0-6.el9), so there is a clean upgrade path. The only loss of functionality is that EPEL 9 included the python-tornado-doc subpackage, but this was not included in RHEL. Nothing else in EPEL 9 depends on this subpackage. [0] https://access.redhat.com/errata/RHBA-2022:8193 [1] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_package_in_rhel -- Carl George ___ 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
python-lockfile deprecation
Howdy Python SIG and python-lockfile maintainers, I recently noticed that pylockfile (packaged as python-lockfile in Fedora and EPEL) is no longer maintained upstream (since 2017). https://github.com/openstack-archive/pylockfile I see 10 packages that still (build)require this, so retirement is probably premature, but is anyone opposed to me marking the package as deprecated so that new packages can't (build)require it? https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ -- Carl George ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 10 proposal
On Wed, Nov 23, 2022 at 2:27 PM Maxwell G via epel-devel wrote: > > On Wed Nov 23, 2022 at 00:52 CST, Carl George wrote: > > I would also ask that feedback be provided there instead of as email > > replies here on the list. > > I don't think there's been a formal discussion about moving EPEL > discussions over to the forums. We already have communication split > between the issue tracker and the ML, so I'm -1 to also adding the > forums. In general, I find it easier to keep up with and participate in > discussions on mailing lists than on forums. However, it seems to me > that this is just for this one proposal, so I guess my comment is off > topic. > > -- > Best, > > 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 EPEL is part of Fedora. discussion.fpo is one of the official places to talk about Fedora things [0]. We already have an #epel tag there with multiple posts [1]. The platform (discourse) has some support for email if you prefer that. On the tag page there is a bell icon that lets you subscribe to a tag, which I believe will email you for every topic started in that tag. You can reply to topics by replying to those emails. The regular mailing lists are also a valid place to discuss Fedora things, but in this instance I wanted to use discussion.fpo for two specific reasons: 1) I wanted to use markdown tables, and 2) I wanted to be able to edit the original post to add FAQ items as feedback comes in. [0] https://docs.fedoraproject.org/en-US/project/help/#_fedora_discussion [1] https://discussion.fedoraproject.org/tag/epel -- Carl George ___ 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] EPEL 10 proposal
Now that EPEL 9 is in full swing, I'd like to start planning ahead for what comes next. CentOS Stream 10 is expected to be available in 2024. We should be able to start EPEL 10 around the same time. Until then, we have the opportunity to evaluate what we can improve in EPEL. I am proposing a new workflow and structure for EPEL 10. The high level summary is for EPEL 10 to have unique branches, build targets, and repos for each minor version of RHEL 10, including CentOS Stream 10 as the upcoming minor version. This would be a significant change from how EPEL works today, but I think it would address several pain points for maintainers and users. I am opening this topic for discussion as early as possible before the EPEL 10 launch to gather feedback. Please note that this is currently just a proposal and has yet to be voted on by the EPEL Steering Committee. Please visit this thread on the Fedora Discussion site for the full proposal. https://discussion.fedoraproject.org/t/epel-10-proposal/44304 I would also ask that feedback be provided there instead of as email replies here on the list. -- Carl George ___ 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: How can I add a component for fedora to request a packges?
On Fri, Oct 21, 2022 at 5:26 PM Betty Liu wrote: > > Hi, I want to request a package in EPEL8 and I follow the steps in the > documentation > If isn’t found in Component under "Fedora EPEL" or "Fedora" > Products, it should be added to Fedora first > > The package name is webkit2gtk-4.0 and I saw it in Fedora, but not in the > RedHat Bugzilla. Can anyone teach me how to add the component to fedora? > ___ > 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 The component in bugzilla corresponds to the source package name, not the binary package name. Often times these are the same, but you've run into one of the instances where they are not. One way to check for this is to use the dnf repoquery command, in this case on Fedora since that's where the package is present and query-able. [root@f37-container:~]# dnf repoquery --quiet --info webkit2gtk4.0 | grep --max-count 1 Source Source : webkitgtk-2.38.0-3.fc37.src.rpm Alternatively, you can search for the package name in the Fedora Packages web app. https://packages.fedoraproject.org/search?query=webkit2gtk4.0 This returns one result, which shows webkit2gtk4.0 as a "subpackage" of webkitgtk. That's another way to describe the source/binary relationship. https://packages.fedoraproject.org/pkgs/webkitgtk/webkit2gtk4.0/ Whichever way you discover the source name, use that as the component for your bugzilla request. https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=webkitgtk -- Carl George ___ 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 8 Modules get the axe on Halloween 2022
or modular packages because it does not > transport a stream name. > > -- Petr > ___ > 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 -- Carl George ___ 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: EL selinux policy
On Tue, Sep 13, 2022 at 8:46 PM Mukundan Ragavan wrote: > > > I have a packaging question - > > One of the packages I maintain, nextcloud-client, fails to execute in > EPEL-9. It is being blocked by SELinux policy. > > getsebool selinuxuser_execmod is off in EL9. > > Is it even allowed to change SELinux rule in, for example, %post? > > I suspect the correct way to do this is to file a bug, correct? > > Thanks. > > -- > GPG Key: E5C8BC67 > ___ > 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 I've never seen anything prohibiting it. In the caddy package I set some SELinux booleans, fcontexts, and ports in %post. To avoid hard dependencies on the tools I wrap the commands in an if statement that checks for the relevant binary. https://src.fedoraproject.org/rpms/caddy/blob/rawhide/f/caddy.spec#_232-250 Grepping through other spec files I see a quite a few other examples of setsebool and semanage commands in scriptlets. -- Carl George ___ 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: packaging multiple versions and compat packages
On Mon, Sep 5, 2022 at 2:22 PM Mark E. Fuller wrote: > > Hi all, > > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? > > Thanks > > -- > Mark E. Fuller, Ph.D. > ful...@fedoraproject.org > ful...@mefuller.dev > @fuller:fedora.im > @fuller:one.ems.host > https://www.stossrohr.net > PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue For naming of the package, please follow the Fedora guidelines for "Multiple packages with the same base name". You'll find many other styles of naming these kind of packages, both in RHEL and EPEL, but please stick with the current Fedora guidelines on this. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple Also make sure your package name and none of the files in your package conflict with anything shipped in RHEL. This may require manually renaming some files. https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy Once you have a working spec file, you can request a dist-git repo with the exception flag because it would fall under the second bullet point for exceptions. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process If the package is intended to be EPEL-only, make sure to retire the rawhide branch. -- Carl George ___ 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
Re: EPEL: packaging multiple versions and compat packages
On Mon, Sep 5, 2022 at 2:22 PM Mark E. Fuller wrote: > > Hi all, > > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? > > Thanks > > -- > Mark E. Fuller, Ph.D. > ful...@fedoraproject.org > ful...@mefuller.dev > @fuller:fedora.im > @fuller:one.ems.host > https://www.stossrohr.net > PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue For naming of the package, please follow the Fedora guidelines for "Multiple packages with the same base name". You'll find many other styles of naming these kind of packages, both in RHEL and EPEL, but please stick with the current Fedora guidelines on this. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple Also make sure your package name and none of the files in your package conflict with anything shipped in RHEL. This may require manually renaming some files. https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy Once you have a working spec file, you can request a dist-git repo with the exception flag because it would fall under the second bullet point for exceptions. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process If the package is intended to be EPEL-only, make sure to retire the rawhide branch. -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sqlcipher soname change in rawhide
On Fri, Aug 26, 2022 at 3:59 PM Fabio Valentini wrote:
>
> On Fri, Aug 26, 2022, 21:20 Demi Marie Obenour wrote:
>>
>> On 8/26/22 06:12, Fabio Valentini wrote:
>> > On Fri, Aug 26, 2022 at 3:12 AM Carl George wrote:
>> >>
>> >> sqlcipher has been requested to be built in epel9 [0]. Rather than
>> >> branching it from the current rawhide version, I plan to update
>> >> rawhide to the latest upstream version first [1]. This involves an
>> >> soname change from libsqlcipher-3.34.1.so.0 to
>> >> libsqlcipher-3.39.2.so.0. This will require six packages to be
>> >> rebuilt.
>> >>
>> >> [root@f38-container:~]# repoquery --repo
>> >> rawhide-source,rawhide-modular-source \
>> >>> --quiet --queryformat '%{name}' --archlist src --whatrequires
>> >>> sqlcipher-devel
>> >> libgda
>> >> python-peewee
>> >> sqlitebrowser
>> >> [root@f38-container:~]# repoquery --repo
>> >> rawhide-source,rawhide-modular-source \
>> >>> --quiet --queryformat '%{name}' --archlist src --whatrequires
>> >>> 'pkgconfig(sqlcipher)'
>> >> kmymoney
>> >> rust-libsqlite3-sys
>> >> skrooge
>> >
>> > Please do not rebuild rust-libsqlite3-sys. It is a source-only package
>> > that does not ship any compiled code.
>> > All packages built from rust-libsqlite3-sys are noarch (i.e. they
>> > can't - by definition - contain architecture-specific binaries).
>> > Any built binaries that link against libsqlcipher are only used for
>> > tests, but not shipped with built packages.
>>
>> Rust FFI uses the ABI, not the API, so if rust-libsqlite3-sys is based on
>> bindgen
>> then the generated Rust code will need to be recreated.
>
>
> Yes, and that happens on-the-fly in the crate's build.rs script, so
> rebuilding the package has zero effect, because the bindings are *always*
> generated from headers at build-time, and are not included in the package at
> all.
>
> Fabio
>
>
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
Thanks for the heads up on rust-libsqlite3-sys. I also realized that
python-peewee doesn't link against this either, so I dropped that one
from the rebuild too. I've completed the rebuilds in a side tag and
merged it.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-647b3781fd
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
sqlcipher soname change in rawhide
sqlcipher has been requested to be built in epel9 [0]. Rather than
branching it from the current rawhide version, I plan to update
rawhide to the latest upstream version first [1]. This involves an
soname change from libsqlcipher-3.34.1.so.0 to
libsqlcipher-3.39.2.so.0. This will require six packages to be
rebuilt.
[root@f38-container:~]# repoquery --repo rawhide-source,rawhide-modular-source \
> --quiet --queryformat '%{name}' --archlist src --whatrequires sqlcipher-devel
libgda
python-peewee
sqlitebrowser
[root@f38-container:~]# repoquery --repo rawhide-source,rawhide-modular-source \
> --quiet --queryformat '%{name}' --archlist src --whatrequires
> 'pkgconfig(sqlcipher)'
kmymoney
rust-libsqlite3-sys
skrooge
I've worked with Jonathan to do a test run of rebuilding these
packages in copr [2], and everything was successful. I will build the
new sqlcipher in a side tag and then complete the rebuilds in the side
tag myself via proven packager permissions.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2120882
[1] https://src.fedoraproject.org/rpms/sqlcipher/pull-request/3
[2] https://copr.fedorainfracloud.org/coprs/jonathanspw/sqlcipher/builds/
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Poco soname bump in rawhide/f37
The updates policy requires that you notify this list and the maintainers whose packages depend on poco a week in advance. https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide I found out about this due to the mumble FailsToInstall bugs that were filed earlier today. https://bugzilla.redhat.com/show_bug.cgi?id=2120237 https://bugzilla.redhat.com/show_bug.cgi?id=2120233 In the future, please follow the policy so everyone has a chance to adapt to stuff like this in time. It's especially painful for this to happen on the day before the change code completion deadline. On Sun, Aug 21, 2022 at 9:40 PM Robin Lee wrote: > > Poco 1.12.2 landed in rawhide/f37 with a soname bump. > > -robin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
orphaned python-pdir2
I've just orphaned python-pdir2 as I no longer use it. Feel free to take ownership if you like. Fair warning, it's failing to build for Python 3.11 in rawhide, and updating to the latest version will require packaging pdm-pep517. -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
If you're happy with the current version 1.0.49 from rawhide being branched for epel9, then the stalled process would be a good fit. With collaborator permissions on epel* branches, you can request the epel9 branch, merge commits from rawhide to epel9, create builds, and create bodhi updates. If you're interested in helping with the long term maintenance of the package, to include getting it updated to the latest version (perhaps before building it for epel9 so that package can start on the latest version), then it's worth considering the unresponsive maintainer process. On Wed, Jun 29, 2022 at 3:51 PM Chris Adams wrote: > > Jumping in on this... I opened BZ 2095512 a few weeks ago about getting > pure-ftpd for EPEL 9, with a follow-up a week ago. There's already an > EPEL 8 branch, so I guess that maintainer was notified (or do all get > notified)? > > Looking at src.fedoraproject.org, it doesn't look like any of the > maintainers have been active in a bit, and the only pure-ftpd changes in > a while have been rebuilds and such. There's been a couple of new > upstream releases (one just last week), noted in BZ 2026153, with no > update to the Fedora or EPEL packages... wondering if any of the > maintainers are still active. > > What's the correct approach here? I'd need to look at the package to > see if I'd be interested in taking it on (my BZ request so far was just > to ask for the existing maintainers to branch it). > > -- > Chris Adams > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
On Wed, Jun 29, 2022 at 2:30 PM Vitaly Zaitsev via devel wrote: > > On 29/06/2022 21:06, Stephen Smoogen wrote: > > Maintainers are custodians and do not own the package. > > This becomes true with the new EPEL policy. I think it should be > revisited to follow Fedora's non-responsive maintainer procedure with an > explicit FESCo approval on a case-by-case basis. It was true before the EPEL stalled policy. Fedora is all of our distribution. No one owns packages, we maintain them. Requiring FESCo sign off for this on every package would significantly hamper EPEL growth. We're not going to do that. The origin of this policy is that the full unresponsive maintainer process is overkill for getting a package added to EPEL. Maintainer1 shouldn't have to suggest that all of maintainer2's packages be orphaned or assigned to themselves in order to be added as a collaborator on an EPEL branch. If you don't like the policy, then you can avoid it simply by handling EPEL branch requests promptly (faster than 3 weeks). > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
On Wed, Jun 29, 2022 at 1:09 PM Vitaly Zaitsev via devel wrote: > > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made contact for > > EPEL bugs. > > Newly added EPEL maintainers can make any changes to Fedora branches. I > don't like that. This is false. The EPEL stalled process results in the new maintainer being added as a collaborator on branches matching the epel* pattern. > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Request for fence-agents-pve package
Correct, a fence-agents-epel package is probably the best choice here.
Are you interested in creating and maintaining that? It's described
in further detail in the EPEL docs [0], although it's lacking
examples.
[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
On Tue, Jun 21, 2022 at 9:15 AM Alex Talaran wrote:
>
> Carl,
>
> it looks like this will not be included in centos stream per RH. so
> looks like option 2 or 3 would be next right? to help the greater
> community 3 might be better since other agents are missing too.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2098360
>
> On 2022-06-17 16:28, Carl George wrote:
> > On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
> >>
> >> would anyone be willing to package this in epel or help get it in the
> >> existing package please?
> >>
> >> i asked on bugzilla [1] but the current maintainer isnt able to help at
> >> the moment. from what i can tell it might just need uncommented in the
> >> spec file [2]. someone else asked about it [1][3] and the ownership is
> >> being thrown back and forth between epel and rhel.
> >>
> >>
> >> [1]
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2029251
> >>
> >> [2]
> >> https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33
> >>
> >> [3]
> >> https://github.com/ClusterLabs/fence-agents/issues/456
> >> ___
> >> 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
> >
> > In Fedora fence-agents-pve is a subpackage of fence-agents.
> > fence-agents is in RHEL, so the Fedora package cannot be branched
> > as-is for EPEL. Some possible alternatives:
> >
> > - Open a CentOS Stream bugzilla and request that fence-agents-pve be
> > added to the fence-agents spec file. If the maintainer agrees, it
> > will show up in the next RHEL minor release ("next" being contingent
> > on timing). This is the ideal solution from a packaging perspective
> > but has a fair chance of being declined if RHEL doesn't want to
> > ship/support that subpackage.
> > - Create a stand-alone fence-agents-pve package, and get it reviewed
> > as an EPEL-only package. That would be allowed in EPEL because
> > neither the srpm or rpm name would conflict with RHEL.
> > - Create a fence-agents-epel package that contains all the subpackages
> > that are disabled in the RHEL spec file. Similar to the previous
> > option, this would be EPEL-only and would be allowed because the srpm
> > and rpm names don't conflict with RHEL.
> > - Rebuild the Fedora spec file with all subpackages somewhere where
> > replacing base packages is allowed, such as a copr or a CentOS SIG.
> >
> ___
> 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
--
Carl George
___
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 8:38 AM Miroslav Suchý wrote: > > Hi. > I want to get your feedback: > > When you enable Copr repository you can run: >dnf copr enable myname/project epel-9-x86_64 > The last parameter is optional and most people usually runs: >dnf copr enable myname/project > > Dnf-plugins-core tries to guess [3] the correct chroot. On Fedora it is easy. > For Fedora 35 it is fedora-35-$arch. > But for RHEL/Centos/Centos Stream it is a bit tricky. > > E.g. for C9S we now defaults to centos-stream-9-$arch. But this gets some > pushback [1,2]. I want to know if this opinion > is minority or whether majority of people wants this. > I do not think there is an option which is correct. So it is about choosing a > default which is correct for most people. > > 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 > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2058471 > [2] > https://gitlab.com/redhat/centos-stream/rpms/dnf-plugins-core/-/merge_requests/7 > [3] > https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/copr.py#L472 > > Miroslav > ___ > 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 In most cases, epel-9-$arch will be the correct choice. In the bug [0] it is suggested that when the guess is wrong it's simple to add the chroot as an explicit argument. Instead of making the majority of users do `dnf copr enable epel-9-`, why can't we have a tiny number of users do `dnf copr enable centos-stream-9-` and have the plugin guess the correct thing for the majority of users? [0] https://bugzilla.redhat.com/show_bug.cgi?id=2058471#c1 -- Carl George ___ 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: Request for fence-agents-pve package
On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
>
> would anyone be willing to package this in epel or help get it in the
> existing package please?
>
> i asked on bugzilla [1] but the current maintainer isnt able to help at
> the moment. from what i can tell it might just need uncommented in the
> spec file [2]. someone else asked about it [1][3] and the ownership is
> being thrown back and forth between epel and rhel.
>
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=2029251
>
> [2]
> https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33
>
> [3]
> https://github.com/ClusterLabs/fence-agents/issues/456
> ___
> 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
In Fedora fence-agents-pve is a subpackage of fence-agents.
fence-agents is in RHEL, so the Fedora package cannot be branched
as-is for EPEL. Some possible alternatives:
- Open a CentOS Stream bugzilla and request that fence-agents-pve be
added to the fence-agents spec file. If the maintainer agrees, it
will show up in the next RHEL minor release ("next" being contingent
on timing). This is the ideal solution from a packaging perspective
but has a fair chance of being declined if RHEL doesn't want to
ship/support that subpackage.
- Create a stand-alone fence-agents-pve package, and get it reviewed
as an EPEL-only package. That would be allowed in EPEL because
neither the srpm or rpm name would conflict with RHEL.
- Create a fence-agents-epel package that contains all the subpackages
that are disabled in the RHEL spec file. Similar to the previous
option, this would be EPEL-only and would be allowed because the srpm
and rpm names don't conflict with RHEL.
- Rebuild the Fedora spec file with all subpackages somewhere where
replacing base packages is allowed, such as a copr or a CentOS SIG.
--
Carl George
___
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: Thoughts: epel-release auto-enable crb repo
On Fri, Jun 17, 2022 at 8:33 AM Troy Dawson wrote: > > > > On Thu, Jun 16, 2022 at 10:22 PM Carl George wrote: >> >> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson wrote: >> > >> > I'm totally top-posting, and I apologize for that. >> > >> > For right now, I'm going to put my enable-crb script in epel-release, but >> > not automatically run it in a %post script or anything. >> > The debate about putting it in a post script, or a separate package, can >> > go on independently of the script. >> > >> > This does a few things. >> > - give people a single, easy to remember way to enable crb >> > -- Right now if you install anything but RHEL you might remember "dnf >> > install epel-release" but then you forget what the dnf command is to >> > enable a repo, and you might forget if it's crb or powertools. >> > -- It will make scripting easier because you just have one command that >> > will work across all RHEL compatibles. >> > >> > - gives the script a chance to find all the corner cases >> > -- It's worked on everything I've tried thus far, but I'm sure there are >> > some corner cases or two where the script doesn't work. >> > >> > I was thinking of it being >> > /usr/bin/enable-crb >> > /usr/bin/epel-enable-crb (a link to enable-crb) >> > >> > Thoughts? >> > >> > Troy >> > >> I think it would be nice to be able to both enable and disable from >> the same script. This would come in handy when you are looking for >> things that don't install when crb is disabled. I don't see anything >> else in Fedora or RHEL that ships a command with the name crb, so how >> about that? >> >> crb enable >> crb disable > > > That shouldn't be too hard. I'm going to give it a shot. > If that takes too long, I'll just push what I currently have for now. > > I notice that you said crb-enable, crb-disable. > Do you like having the name first, or the function first? > > enable-crb vs crb-enable ? > > either way I want to have it by itself, as well as starting with epel > > epel-enable-crb vs epel-crb-enable ? > > Troy > > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure I was specifically suggesting /usr/bin/crb, accepting a single argument of enable or disable. I can't find anything else in Fedora or RHEL using that path. What would be the purpose of prefixing it with "epel-"? It's not "CRB from EPEL", it's a generic script for enabling/disabling the crb repo that just happens to be included in the epel-release package. -- Carl George ___ 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: Thoughts: epel-release auto-enable crb repo
On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson wrote: > > I'm totally top-posting, and I apologize for that. > > For right now, I'm going to put my enable-crb script in epel-release, but not > automatically run it in a %post script or anything. > The debate about putting it in a post script, or a separate package, can go > on independently of the script. > > This does a few things. > - give people a single, easy to remember way to enable crb > -- Right now if you install anything but RHEL you might remember "dnf install > epel-release" but then you forget what the dnf command is to enable a repo, > and you might forget if it's crb or powertools. > -- It will make scripting easier because you just have one command that will > work across all RHEL compatibles. > > - gives the script a chance to find all the corner cases > -- It's worked on everything I've tried thus far, but I'm sure there are some > corner cases or two where the script doesn't work. > > I was thinking of it being > /usr/bin/enable-crb > /usr/bin/epel-enable-crb (a link to enable-crb) > > Thoughts? > > Troy > > https://pagure.io/epel/issue/128 > https://src.fedoraproject.org/rpms/epel-release/pull-request/21 > ___ > 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 I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that? crb enable crb disable -- Carl George ___ 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: Thoughts: epel-release auto-enable crb repo
On Sat, Jun 4, 2022 at 3:52 PM Troy Dawson wrote: > > When I first created the EPEL issue to auto-enable crb repo[1] I was only > thinking of CAN we do it. I wasn't thinking SHOULD we do it. > We've come to the point that we actually can do it. But before we go down > that road, I wanted to take a step back and ask, should we do it. > > The more I think about it, the more I think we shouldn't auto-enable the crb > repo for epel8 and epel9. Here are my reasons why. > > 1 - The need to auto-enable crb isn't as big as it was before. > At the time that I wrote that issue, I was getting quite alot of bugs / pings > / emails about epel packages not being installable. I think on average > about 2 a month. > With epel being in fedora-docs, and with Carl's re-write of how to enable > epel, that number has dropped significantly. I possibly still average one a > month, but that's an average over a year, with most of them being last year. > In short, I believe the documentation is better, and easier to find, allowing > people to enable crb on their own, without automation. > > 2 - crb isn't an epel repo > We really shouldn't be messing with other repo's that we, epel, don't own. > > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where > people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd > places for us to not hit some odd use cases we didn't expect. We'd have to > keep fixing the scripts. > > I could go into more explanation on each of those things, but in the end, > I've talked myself out of wanting to auto-enable crb for epel8 and epel9. > But I also wanted to get others' thoughts before I close the bug and pull > request. > > What do others think? > > Troy > > > [1] - https://pagure.io/epel/issue/128 > ___ > 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 I have sympathy for the issue we are trying to solve, but I do not think it's that big a deal. Enabling crb is a documented part of setting up EPEL. Anyone having issues because crb isn't enabled failed to follow the instructions. Continuing to redirect people to the instructions will eventually result in this being common knowledge, and the instances of having to tell people about it will continue to fall. We can further reduce these instances by requesting EPEL runtime dependencies be "promoted" from crb to baseos or appstream. In the mean time, it's not that much work to copy/paste "the missing dependencies are in crb/powertools, follow the setup instructions again" to the occasional bug report. When we were first setting up the repo definitions for CentOS Stream 9, I suggested the idea of moving the crb repo file to a separate package (centos-release-crb), with enabled=1 but not installed by default. This would allow epel-release to recommmend centos-release-crb. There was push back to this idea because there is a desire for the "enable crb" action in CentOS Stream to look roughly similar to how it works in RHEL (`dnf config-manager --set-enabled crb` and `subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms`). Maybe we can revisit this idea for CentOS Stream 10. -- Carl George ___ 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
Re: Ancient Puppet version in EPEL-7: remove it?
On Tue, Apr 26, 2022 at 1:25 PM Ewoud Kohl van Wijngaarden wrote: > > Hello everyone, > > There is an ancient version of Puppet in EPEL-7. Version 3.6 has been > EOL for ages now. https://binford2k.com/2016/11/22/puppet-3.x-eol/ has a > nice EOL overview: > > * Puppet 3 - 2016-12-31 > * Puppet 4 - 2018-10-?? > * Puppet 5 - 2021-02-?? > > Puppet 6 requires a newer Ruby version than is available in EL7 so > rebasing the whole stack is not going to work. In theory you could use > SCLs but I think it's unrealistic to expect that. > > However, all bugs open for Puppet relate to EPEL-7[1] so I'm wondering > what to do. > > We can close all bugs as WONTFIX (including the security ones), but > would it be better to also remove the package from EPEL-7? > > Regards, > Ewoud Kohl van Wijngaarden > > [1]: > https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=puppet_id=12574395=Fedora=Fedora%20EPEL > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Retiring epel7's puppet may be the preferred option. It is allowed [0], but if you go this route please mention it on the epel-devel list (and perhaps epel-announce) first. Alternatively, have you considered doing an incompatible update [1] to version 5? It may already be EOL, but surely that's a better option than the current version 3 or removing it entirely. [0] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#what_can_be_retired [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [HEADS UP] ImageMagick side-tag for epel8
On Wed, Apr 13, 2022 at 5:05 PM Carl George wrote: > > On Fri, Apr 8, 2022 at 5:17 PM Troy Dawson wrote: > > > > > > > > On Fri, Apr 8, 2022 at 3:00 PM Sérgio Basto wrote: > >> > >> On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote: > >> > >> > >> > >> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto wrote: > >> > >> On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote: > >> > > This update changes a library soname, which makes it an > >> > > incompatible > >> > > upgrade. It must follow the EPEL incompatible upgrades policy [0]. > >> > > This email can count as step 1 once you reply with the specific > >> > > CVEs > >> > > this will address. Then it must be open for discussion on list for > >> > > one week (step 2) before being added as an agenda item at next > >> > > week's > >> > > EPEL Steering Committee meeting [1] (step 3). > >> > > > >> > > [0] > >> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > >> > > [1] https://calendar.fedoraproject.org/epel/#m9854 > >> > > >> > OK , thank you > >> > >> > >> Hi, > >> have we any new ? > >> > >> I'd like move on before rhel 8.6 be available . > >> > >> > >> Thank you > >> > >> > >> Hi Sérgio, > >> Could you list the CVE's that this update addresses. > >> If that list is fairly long, at least the important ones > >> > >> > >> > >> we got 82 reported on bugzilla > >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=ImageMagick_id=12543908=Fedora%20EPEL_format=advanced > > > > > > Youch! > > Next time, lead with that. :) > > I joke, but that's really what we were waiting for. > > It's a Friday afternoon, and I'm pretty certain we won't get enough of the > > committee reading this to give a full vote until next week. > > But, as for me, I give it a +1. > > Troy > > > > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > This was approved [0] in today's EPEL Steering Committee meeting. > Please continue with the process for incompatible upgrades from step 4 > forward [1]. > > [0] https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html > [1] > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades > > -- > Carl George Based on repoquery it looks like only three packages need to be rebuilt for this. converseen digikam dvdauthor -- Carl George ___ 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: [HEADS UP] ImageMagick side-tag for epel8
On Fri, Apr 8, 2022 at 5:17 PM Troy Dawson wrote: > > > > On Fri, Apr 8, 2022 at 3:00 PM Sérgio Basto wrote: >> >> On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote: >> >> >> >> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto wrote: >> >> On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote: >> > > This update changes a library soname, which makes it an >> > > incompatible >> > > upgrade. It must follow the EPEL incompatible upgrades policy [0]. >> > > This email can count as step 1 once you reply with the specific >> > > CVEs >> > > this will address. Then it must be open for discussion on list for >> > > one week (step 2) before being added as an agenda item at next >> > > week's >> > > EPEL Steering Committee meeting [1] (step 3). >> > > >> > > [0] >> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ >> > > [1] https://calendar.fedoraproject.org/epel/#m9854 >> > >> > OK , thank you >> >> >> Hi, >> have we any new ? >> >> I'd like move on before rhel 8.6 be available . >> >> >> Thank you >> >> >> Hi Sérgio, >> Could you list the CVE's that this update addresses. >> If that list is fairly long, at least the important ones >> >> >> >> we got 82 reported on bugzilla >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=ImageMagick_id=12543908=Fedora%20EPEL_format=advanced > > > Youch! > Next time, lead with that. :) > I joke, but that's really what we were waiting for. > It's a Friday afternoon, and I'm pretty certain we won't get enough of the > committee reading this to give a full vote until next week. > But, as for me, I give it a +1. > Troy > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure This was approved [0] in today's EPEL Steering Committee meeting. Please continue with the process for incompatible upgrades from step 4 forward [1]. [0] https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades -- Carl George ___ 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: Dependency issue hwinfo/libx86emu
On Fri, Apr 8, 2022 at 2:23 AM Nick Howitt via epel-devel wrote: > > > > On 08/04/2022 04:38, Carl George wrote: > > On Thu, Apr 7, 2022 at 7:33 PM Gemneye via epel-devel > > wrote: > >> > >>>> > >>>> Error: Package: hwinfo-21.68-1.el7.x86_64 (epel) > >>>> Requires: libx86emu.so.1()(64bit) > >>>> Removing: libx86emu-1.1-2.1.x86_64 > >>>> (@/libx86emu-1.1-2.1.x86_64) > >>>> libx86emu.so.1()(64bit) > >>>> Updated By: libx86emu-3.5-1.el7.x86_64 (epel) > >>>>~libx86emu.so.3()(64bit) > >>>> You could try using --skip-broken to work around the problem > >>>> You could try running: rpm -Va --nofiles --nodigest > >>>> > >>>> Any suggestions and help appreciated. > >>> > >>> Hello > >>> > >>> > >>> You can install hwinfo if you either disable epel-testing or filter > >>> out (yum --exclude) libx86emu-3.5-1.el7. This package was pushed to > >>> epel-testing and indeed, hwinfo which depends on libx86emu would need > >>> a rebuild against it. > >>> > >>> > >>> wolfy > >>> > >> > >> Thank you for the response. > >> > >> It looks like libx86emu-3.5-1.el7.x86_64 is in the main epel repository. > >>Using --disablerepo=epel-testing, nor disabling repo in > >> /etc/yum.repos.d/epel-testing.repo caused the issue to go away. > >> > >> You are correct in that hwinfo can be installed by using > >> --exclude=libx86emu, but is still looks like there is a packing issue?? > >> ___ > >> 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 > > > > This just recently happened in EPEL8 too [0]. I've created a > > corresponding bug for EPEL7 [1]. This incompatible soname bump in > > libx86emu is not allowed by EPEL policy [2]. If an update like this > > must happen for security reasons, it should follow the incompatible > > upgrades policy [3], which includes discussion on this list and > > announcements on epel-announce. Obviously that's not what happened > > here. The quickest fix is to rebuild hwinfo against the new soname. > > I did that for EPEL8 a few days ago, and just submitted the EPEL7 one > > now. Follow along in the bugzilla for future updates. > > > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=2071639 > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2073238 > > [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/ > > [3] > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > > > Or, as a short term kludge, can you force the installation of both > packages and then symlink libx86emu.so.1 to so.3? > ___ > 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 That is awful advice. Please don't tell people to do that. When an soname changes the library developer is explicitly stating that the interfaces have changed. You are gambling that the application using the library isn't using any of the changed interfaces. -- Carl George ___ 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: Dependency issue hwinfo/libx86emu
On Thu, Apr 7, 2022 at 7:33 PM Gemneye via epel-devel wrote: > > >> > >> Error: Package: hwinfo-21.68-1.el7.x86_64 (epel) > >>Requires: libx86emu.so.1()(64bit) > >>Removing: libx86emu-1.1-2.1.x86_64 > >> (@/libx86emu-1.1-2.1.x86_64) > >>libx86emu.so.1()(64bit) > >>Updated By: libx86emu-3.5-1.el7.x86_64 (epel) > >> ~libx86emu.so.3()(64bit) > >> You could try using --skip-broken to work around the problem > >> You could try running: rpm -Va --nofiles --nodigest > >> > >> Any suggestions and help appreciated. > > > > Hello > > > > > > You can install hwinfo if you either disable epel-testing or filter > > out (yum --exclude) libx86emu-3.5-1.el7. This package was pushed to > > epel-testing and indeed, hwinfo which depends on libx86emu would need > > a rebuild against it. > > > > > > wolfy > > > > Thank you for the response. > > It looks like libx86emu-3.5-1.el7.x86_64 is in the main epel repository. > Using --disablerepo=epel-testing, nor disabling repo in > /etc/yum.repos.d/epel-testing.repo caused the issue to go away. > > You are correct in that hwinfo can be installed by using > --exclude=libx86emu, but is still looks like there is a packing issue?? > ___ > 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 This just recently happened in EPEL8 too [0]. I've created a corresponding bug for EPEL7 [1]. This incompatible soname bump in libx86emu is not allowed by EPEL policy [2]. If an update like this must happen for security reasons, it should follow the incompatible upgrades policy [3], which includes discussion on this list and announcements on epel-announce. Obviously that's not what happened here. The quickest fix is to rebuild hwinfo against the new soname. I did that for EPEL8 a few days ago, and just submitted the EPEL7 one now. Follow along in the bugzilla for future updates. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2071639 [1] https://bugzilla.redhat.com/show_bug.cgi?id=2073238 [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/ [3] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- Carl George ___ 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: [HEADS UP] ImageMagick side-tag for epel8
rgio M. B. > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure This update changes a library soname, which makes it an incompatible upgrade. It must follow the EPEL incompatible upgrades policy [0]. This email can count as step 1 once you reply with the specific CVEs this will address. Then it must be open for discussion on list for one week (step 2) before being added as an agenda item at next week's EPEL Steering Committee meeting [1] (step 3). [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://calendar.fedoraproject.org/epel/#m9854 -- Carl George ___ 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] slowing down the stalled request process
EPEL has a stalled request policy [0] that allows packagers to get themselves added as collaborators on epel* branches. Prior to this policy being implemented, requests to add Fedora packages to EPEL would often go unanswered for long periods of time. Packagers wanting to help had only one option to force action: Fedora's non-responsive maintainer policy [1]. This was view by many as overkill, as it results in all of the non-responsive maintainer's packages being orphaned or transferred to the requester. The stalled request policy is much friendlier and enables greater collaboration. 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. The current process allows a collaborator to be added after a two week period. When the stalled policy was implemented I was a fan of this duration, but now I think it is too short. Extending it slightly would be a good compromise to give maintainers a bit more time to respond while still allowing the request to eventually be completed. I have two suggestions for alternative steps for the process. Current process (two bugzilla pings, two weeks total time): - 1st request - one week goes by - 2nd request - one week goes by - releng ticket to be added as a collaborator Proposal A (three bugzilla pings, three weeks total time): - 1st request - one week goes by - 2nd request - one week goes by - 3rd request - one week goes by - releng ticket to be added as a collaborator Proposal B (two bugzilla pings, four weeks total time): - 1st request - two weeks go by - 2nd request - two weeks go by - releng ticket to be added as a collaborator I also think we can improve the process by having the last bugzilla comment include setting the needsinfo flag. Please share your thoughts on these alternative process steps. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ -- Carl George ___ 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 Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi wrote: > > 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. What I suggested as policy would be to allow weak dependencies on non-base channels, not to incorrectly identify all hard dependencies as weak if they're in these channels. If an EPEL package has a hard dependency, that dependency should be in the target base or EPEL itself. If the dependency actually is weak (optional), it would be useful to allow those to be provided by non-target-base channels. The plugin example is a bit of a grey area. If the software is designed as such that no one uses the plugin directly, but rather the plugin extends the functionality of the main software which is used directly, then I think users can figure out they need to install both the main software and the plugin, regardless of the dependency relationship. This will vary case by case, and we could allowed these by Steering Committee exception only. > > 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. ;( As far as I know RHEL doesn't really drop packages, they stay on the CDN for the life of distro. Even if they do get dropped, this seems like an edge case we shouldn't really need to worry too much about. If it happens and it results in an EPEL package not working, we'll know it should have been a Requires and not a Recommends all along, which will lead to either the maintainer adding the necessary dependency to EPEL, or retiring the package with the missing dependency. > > 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. ;( This is already allowed, which is why we have EPEL packages that would need to be retired if HA/RS are added to the target base. > > Perhaps instead of a strict rule we could just ask everything that has > this issue to get an exception? As stated above I'd be fine with an exception workflow if a maintainer feels it's justified to intentionally mislabel a hard dependency as weak, but the general case of truly weak (optional) dependencies from non-target-base channels shouldn't need exceptions IMO. > > Not an easy case. > > kevin > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe
[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?
On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote: > > On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson wrote: > > > > > > > > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera wrote: > >> > >> I've been checking the packages that won't install on EPEL [1] and found > >> out that drbd-pacemaker cant get installed > >> because of a missing dependency (pacemaker). While researching why, I saw > >> that pacemaker exists on EPEL7 because it's > >> provided by the HighAvailability repo, but by policy [2] that repo is not > >> a base for EPEL8 nor EPEL9. > >> > >> When I asked on how to handle this cases on the steering meeting, some > >> proposed ideas were: > >> > >> * Rebuild the dependencies as -epel > >> * Retire the packages > >> * Bringing back HA & RS repo > >> > >> The only other package that i've found also has this problem is > >> resalloc-aws that depends on awscli. > >> > >> Is there a policy on this cases? Are EPEL packages allowed to require > >> packages outside of the policy approved? > >> I would like more feedback on how to proceed so we can file bugs for this > >> packages correctly. > >> > >> Package: drbd-pacemaker-9.20.2-1.el9 > >> Error: Problem: conflicting requests - nothing provides pacemaker needed > >> by drbd-pacemaker-9.20.2-1.el9.x86_64 > >> > >> Package: resalloc-aws-1.1-1.el9 > >> Error: Problem: conflicting requests - nothing provides awscli needed by > >> resalloc-aws-1.1-1.el9.noarch > >> > >> Package: drbd-pacemaker-9.17.0-1.el8 > >> Error: Problem: conflicting requests - nothing provides pacemaker needed > >> by drbd-pacemaker-9.17.0-1.el8.x86_64 > >> > >> [1] > >> https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html > >> [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy > > > > > > Someone can tell me I'm wrong, but I believe if something is in HA or RS in > > RHEL8 or 9 it is fair game for EPEL8 or EPEL9. > > Those packages are currently not being excluded when you request a package > > for epel8 or epel9. > > > > So, my opinion, build pacemaker in EPEL. > > > > Troy > > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > 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 > 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. HA8 package EPEL8 package awscli-1.14.50-5.el8 awscli-1.18.156-1.el8 google-api-python-client-1.6.5-3.el8 google-api-python-client-1.6.7-10.el8 python-boto3-1.6.1-2.el8 python-boto3-1.15.15-1.el8 python-botocore-1.9.1-2.el8 python-botocore-1.18.15-1.el8 python-fasteners-0.14.1-14.el8 python-fasteners-0.14.1-20.el8 python-oauth2client-4.1.2-6.el
[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?
On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson wrote: > > > > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera wrote: >> >> I've been checking the packages that won't install on EPEL [1] and found out >> that drbd-pacemaker cant get installed >> because of a missing dependency (pacemaker). While researching why, I saw >> that pacemaker exists on EPEL7 because it's >> provided by the HighAvailability repo, but by policy [2] that repo is not a >> base for EPEL8 nor EPEL9. >> >> When I asked on how to handle this cases on the steering meeting, some >> proposed ideas were: >> >> * Rebuild the dependencies as -epel >> * Retire the packages >> * Bringing back HA & RS repo >> >> The only other package that i've found also has this problem is resalloc-aws >> that depends on awscli. >> >> Is there a policy on this cases? Are EPEL packages allowed to require >> packages outside of the policy approved? >> I would like more feedback on how to proceed so we can file bugs for this >> packages correctly. >> >> Package: drbd-pacemaker-9.20.2-1.el9 >> Error: Problem: conflicting requests - nothing provides pacemaker needed by >> drbd-pacemaker-9.20.2-1.el9.x86_64 >> >> Package: resalloc-aws-1.1-1.el9 >> Error: Problem: conflicting requests - nothing provides awscli needed by >> resalloc-aws-1.1-1.el9.noarch >> >> Package: drbd-pacemaker-9.17.0-1.el8 >> Error: Problem: conflicting requests - nothing provides pacemaker needed by >> drbd-pacemaker-9.17.0-1.el8.x86_64 >> >> [1] >> https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html >> [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy > > > Someone can tell me I'm wrong, but I believe if something is in HA or RS in > RHEL8 or 9 it is fair game for EPEL8 or EPEL9. > Those packages are currently not being excluded when you request a package > for epel8 or epel9. > > So, my opinion, build pacemaker in EPEL. > > Troy > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure 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 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 ___ 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] EPEL Office Hours
The EPEL Steering Committee has implementing monthly office hours for the EPEL project. These will be held on the first Wednesday of each month at 1700 UTC. The openSUSE Heroes team has agreed to let us host the meeting on their Jitsi Meet instance. Please join us at https://meet.opensuse.org/epel with all your EPEL questions. https://discussion.fedoraproject.org/t/join-us-for-the-epel-office-hours-every-month/37235 -- Carl George ___ 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: EPEL9 Rollout Proposals
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson wrote: > > In our last EPEL Steering Committee meeting, Carl brought up a new proposal > for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to > explain things like that, it got a little confusing. Carl and I had a good > video chat to clean up confusion and talk about some pros and cons of the > various proposals. > Here are the three proposals. > > * PLAN A > Plan A is basically what we've been working towards for the past couple of > months. > - launch epel9-next now-ish (ideally aligned with c9s launch promotion) > - After RHEL9 goes GA > -- perform a mass branch and mass rebuild to populate epel9 > -- launch epel9 after RHEL9 GA is launched. > > ** Plan A Pros: > - epel9-next and epel9 are only set up once, and not changed > - ready to go now > > ** Plan A Cons: > - complexity and added work of mass branch and mass rebuild > - mass rebuild will have a moderate rate of failure due to buildroot > differences (unshipped devel packages) > - epel9 not available at rhel9 ga > - confusing messaging to packagers: > -- target epel9-next for ~6 months > -- after epel9 exists target that instead, only use epel9-next when needed > - confusing messaging to users: > -- use epel9-next now for c9s and rhel9 beta > -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled > -- use epel9 primarily once it exists > > > * PLAN B > - epel9-next stays the way it is currently setup. > - Setup epel9 using RHEL9 Beta for the buildroot. > -- Pull in any errata as it comes. > -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB > - Launch epel9 and epel9-next together (In 1-2 weeks). > - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 > GA > > ** Plan B Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan B Cons: > - potential for large divergence between rhel9 beta and ga > - changing our messaging right before the launch > > > * PLAN C > - epel9-next stays the way it is currently setup. > - setup up epel9 using c9s for the buildroot > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > - freeze epel9 buildroot before c9s switches to 9.1 content > - launch epel9 and epel9-next together (1-2 weeks) > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > ** Plan C Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan C Cons: > - potential infrastructure complexity of freezing the epel9 buildroot > - changing our messaging right before the launch > > > Please let us know what you think. > If we do choose to go with Plan B or C we will need to make the decision > fairly quickly. > > Troy > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C. https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions. -- Carl George ___ 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 22, 2021 at 8:37 AM Vitaly Zaitsev via devel
wrote:
>
> On 22/11/2021 15:00, Pavel Raiskup wrote:
> > - builds will require a valid Red Hat subscription (the no-cost variant is
> >OK as well, though [2])
>
> I'm going to retire all my EPEL8 packages as I can't build/test them in
> mock without any subscriptions.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
This has always been allowed. EPEL packagers are not required to
maintain their packages for the entire corresponding RHEL lifecycle.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_epel
I will point out that it's trivial to avoid dealing with a
subscription by doing koji scratch builds, or by using the existing
oraclelinux-epel-8-x86_64 mock chroot, or by submitting equivalent
{clone}-epel-8-{arch} chroots to mock-core-configs for your preferred
clone. Mass retiring all of your epel8 packages seems like an
overreaction to me, but it is your choice. If you do decide to go
that route I hope you're welcoming to other maintainers that offer to
co-maintainer your packages to be responsible for the epel8 branch
going forward. Ideally you would also send an email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
--
Carl George
___
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
Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:37 AM Vitaly Zaitsev via devel
wrote:
>
> On 22/11/2021 15:00, Pavel Raiskup wrote:
> > - builds will require a valid Red Hat subscription (the no-cost variant is
> >OK as well, though [2])
>
> I'm going to retire all my EPEL8 packages as I can't build/test them in
> mock without any subscriptions.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
This has always been allowed. EPEL packagers are not required to
maintain their packages for the entire corresponding RHEL lifecycle.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_epel
I will point out that it's trivial to avoid dealing with a
subscription by doing koji scratch builds, or by using the existing
oraclelinux-epel-8-x86_64 mock chroot, or by submitting equivalent
{clone}-epel-8-{arch} chroots to mock-core-configs for your preferred
clone. Mass retiring all of your epel8 packages seems like an
overreaction to me, but it is your choice. If you do decide to go
that route I hope you're welcoming to other maintainers that offer to
co-maintainer your packages to be responsible for the epel8 branch
going forward. Ideally you would also send an email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/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 22, 2021 at 8:27 AM Miroslav Suchý wrote: > > Dne 22. 11. 21 v 15:10 Miro Hrončok napsal(a): > > > > However, enough of my personal views. Since we have not used RHEL for > > copr/mock EPEL buidlroots until now, but we used > > a downstream freely-available RHEL-copy (CentOS Linux), could we not > > continue doing so by using e.g. AlmaLinux? > > For day to day work I would suggest to move to centos-stream + epel-next > (hmm, we do not have a config for that). > > But EPEL is built against RHEL (not Alma, not Rocky). So we either use > default config which will differ from Koji or we > have to fiddle with entitlements: > > https://rpm-software-management.github.io/mock/Feature-rhelchroots > > https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription#step_2__download_no_cost_rhel > > Miroslav > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Agreed, for quick local builds it's fine to use epel8-next (c8s) to verify it builds and then submit the koji build to the epel8 (rhel8) target. If the local build works but the koji build doesn't, you likely have a candidate for an official epel8-next koji build. -- Carl George ___ 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
Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:27 AM Miroslav Suchý wrote: > > Dne 22. 11. 21 v 15:10 Miro Hrončok napsal(a): > > > > However, enough of my personal views. Since we have not used RHEL for > > copr/mock EPEL buidlroots until now, but we used > > a downstream freely-available RHEL-copy (CentOS Linux), could we not > > continue doing so by using e.g. AlmaLinux? > > For day to day work I would suggest to move to centos-stream + epel-next > (hmm, we do not have a config for that). > > But EPEL is built against RHEL (not Alma, not Rocky). So we either use > default config which will differ from Koji or we > have to fiddle with entitlements: > > https://rpm-software-management.github.io/mock/Feature-rhelchroots > > https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription#step_2__download_no_cost_rhel > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Agreed, for quick local builds it's fine to use epel8-next (c8s) to verify it builds and then submit the koji build to the epel8 (rhel8) target. If the local build works but the koji build doesn't, you likely have a candidate for an official epel8-next koji build. -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:11 AM Miro Hrončok wrote: > > On 22. 11. 21 15:00, Pavel Raiskup wrote: > > - builds will require a valid Red Hat subscription (the no-cost variant is > >OK as well, though [2]) > > I cannot help myself but I consider this very unpleasant for EPEL packagers. > > Getting and configuring the subscription was always so unfriendly for me that > I've been using EPEL mocks even for my RHEL work. This basically means using > EPEL mocks will once again be as complicated as using RHEL. > > However, enough of my personal views. Since we have not used RHEL for > copr/mock > EPEL buidlroots until now, but we used a downstream freely-available RHEL-copy > (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure I'm not aware of a RHEL clone that offers all the architectures that EPEL does. As far as I can tell, the three most popular (Alma, Rocky, Oracle) only offer x86_64 and aarch64 but are missing ppc64le and s390x. That said CentOS Linux 8 doesn't offer s390x either, so we already have this problem, but switch the EPEL mock chroot to one of those clones would make the situation worse by also dropping ppc64le. -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/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 22, 2021 at 8:11 AM Miro Hrončok wrote: > > On 22. 11. 21 15:00, Pavel Raiskup wrote: > > - builds will require a valid Red Hat subscription (the no-cost variant is > >OK as well, though [2]) > > I cannot help myself but I consider this very unpleasant for EPEL packagers. > > Getting and configuring the subscription was always so unfriendly for me that > I've been using EPEL mocks even for my RHEL work. This basically means using > EPEL mocks will once again be as complicated as using RHEL. > > However, enough of my personal views. Since we have not used RHEL for > copr/mock > EPEL buidlroots until now, but we used a downstream freely-available RHEL-copy > (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure I'm not aware of a RHEL clone that offers all the architectures that EPEL does. As far as I can tell, the three most popular (Alma, Rocky, Oracle) only offer x86_64 and aarch64 but are missing ppc64le and s390x. That said CentOS Linux 8 doesn't offer s390x either, so we already have this problem, but switch the EPEL mock chroot to one of those clones would make the situation worse by also dropping ppc64le. -- Carl George ___ 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: EPEL9 Rollout Proposals
On Fri, Nov 19, 2021 at 5:26 PM Miroslav Suchý wrote: > > Dne 20. 11. 21 v 0:04 Troy Dawson napsal(a): > > Do we keep everything in epel9-next until RHEL9 GA and then do a mass > > branch over and mass rebuild? (Plan A) > > And again with 9.1 GA? And again with 9.2 GA? // I do not expect answer, just > pointing that minor releases should be > part of the solution. > > Miroslav > ___ > 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 Historically most EPEL packages don't need to be rebuilt with every minor release, as RHEL libraries don't change often. When they do need to be rebuilt, it's been left up to the individual maintainers to take care of as their time allows. This has mostly worked OK for us. Plan A would be a departure from the norm, where we do a mass rebuild at 9.0 for a "bootstrap" of epel9 content from epel9-next. At the last EPEL Steering Committee meeting we talked about doing mass rebuilds at every future minor release, but more or less agreed that this would be overkill and would result in a drastic increase in disk usage in the infrastructure. Additionally our existing mass rebuild tooling doesn't account for changes that exist in the epel9-next branches that need to be merged to the epel9 branches before building. Plans B and C are more like the status quo, where packagers target epel9, and do individual package rebuilds as needed after a RHEL minor release. -- Carl George ___ 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 12:33 PM Kevin Fenzi wrote: > > 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? +1 to putting this on the agenda for next week's meeting. > > 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 > ___ > 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 -- Carl George ___ 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: EPEL9 Rollout Proposals
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson wrote: > > In our last EPEL Steering Committee meeting, Carl brought up a new proposal > for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to > explain things like that, it got a little confusing. Carl and I had a good > video chat to clean up confusion and talk about some pros and cons of the > various proposals. > Here are the three proposals. > > * PLAN A > Plan A is basically what we've been working towards for the past couple of > months. > - launch epel9-next now-ish (ideally aligned with c9s launch promotion) > - After RHEL9 goes GA > -- perform a mass branch and mass rebuild to populate epel9 > -- launch epel9 after RHEL9 GA is launched. > > ** Plan A Pros: > - epel9-next and epel9 are only set up once, and not changed > - ready to go now > > ** Plan A Cons: > - complexity and added work of mass branch and mass rebuild > - mass rebuild will have a moderate rate of failure due to buildroot > differences (unshipped devel packages) > - epel9 not available at rhel9 ga > - confusing messaging to packagers: > -- target epel9-next for ~6 months > -- after epel9 exists target that instead, only use epel9-next when needed > - confusing messaging to users: > -- use epel9-next now for c9s and rhel9 beta > -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled > -- use epel9 primarily once it exists > > > * PLAN B > - epel9-next stays the way it is currently setup. > - Setup epel9 using RHEL9 Beta for the buildroot. > -- Pull in any errata as it comes. > -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB > - Launch epel9 and epel9-next together (In 1-2 weeks). > - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 > GA > > ** Plan B Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan B Cons: > - potential for large divergence between rhel9 beta and ga > - changing our messaging right before the launch > > > * PLAN C > - epel9-next stays the way it is currently setup. > - setup up epel9 using c9s for the buildroot > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > - freeze epel9 buildroot before c9s switches to 9.1 content > - launch epel9 and epel9-next together (1-2 weeks) > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > ** Plan C Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan C Cons: > - potential infrastructure complexity of freezing the epel9 buildroot > - changing our messaging right before the launch > > > Please let us know what you think. > If we do choose to go with Plan B or C we will need to make the decision > fairly quickly. > > Troy > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Thanks everyone for the feedback so far. I would still like to talk with the Fedora Infra folks in a bit more depth about the difficulty level of each plan, but at this point in time I feel like plan C is the best option because of the benefits. - simple instructions to maintainers - simple instructions for users - no need for a mass rebuild, which is a big time saver - ability to have EPEL9 content ready on day 1 of the RHEL9 GA launch I'm stating this as my opinion right now, not as the final decision. I'll defer that to an EPEL Steering Committee vote of course. -- Carl George ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Cod
[EPEL-devel] Re: EPEL9 Rollout Proposals
gt; So, I am not against this idea as well. One thing I would like to > mention here is, even if we can setup this way since rhel 9 beta is > out, we cannot do that same thing during rhel10 time as we might setup > epel10-next way in advance before the rhel10 beta. We cannot keep this > plan consistent going further. I don't think we need to worry about making the exact same plan work for EPEL10 yet. Maybe we decide that our EPEL9 plan doesn't work for EPEL10 and we try something else. Maybe we plan from the start to launch EPEL10 after the RHEL10 Beta. I'd like to make the best choice for EPEL9 now, and then build off that when the time comes for EPEL10. > > > > > * PLAN C > > - epel9-next stays the way it is currently setup. > > - setup up epel9 using c9s for the buildroot > > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > > - freeze epel9 buildroot before c9s switches to 9.1 content > > - launch epel9 and epel9-next together (1-2 weeks) > > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > > > ** Plan C Pros: > > - simple messaging to packagers: > > -- epel9 is the primary target, use epel9-next only when needed (same as > > epel8-next) > > - simple messaging to users: > > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > > - no mass branching > > - no mass rebuild > > - No confusion from using the full CentOS Stream buildroot > > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > > > ** Plan C Cons: > > - potential infrastructure complexity of freezing the epel9 buildroot > > - changing our messaging right before the launch > > > > I can see how its advantageous, but I dont like this plan, since there > are some uncertainties, we dont really know when c9s will start > pointing to rhel 9.1, we can only guestimate currently. Even if we > know for sure, we have to ask centos stream folks to freeze their work > until we sort out things on our side. And what if the package versions > changed in rhel9 ga, because they found an issue in that build. We will have a really good idea of when c9s is preparing to switch to 9.1 content. And we don't have to ask CentOS Stream to do anything, we just need to stop syncing the mirror directory that corresponds to the EPEL9 koji target's external repo before 9.1 changes show up in c9s. It is extremely unlikely that a package version will change in a way that is significant to EPEL packages (library soname change) in that frozen time period. > > > > > Please let us know what you think. > > If we do choose to go with Plan B or C we will need to make the decision > > fairly quickly. > > I am okay with either plan A or plan B. > > > > > Troy > > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > 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 -- Carl George ___ 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: EPEL9 Rollout Proposals
ecurity changes don't change the soname, and dynamically linked packages don't need to be rebuilt. Staticly linked packages are another story, but those are fairly rare in EPEL due to the massive dependency burden of golang and rust. > > > - launch epel9 and epel9-next together (1-2 weeks) > > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > > > ** Plan C Pros: > > - simple messaging to packagers: > > -- epel9 is the primary target, use epel9-next only when needed (same as > > epel8-next) > > - simple messaging to users: > > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > > - no mass branching > > - no mass rebuild > > - No confusion from using the full CentOS Stream buildroot > > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > > > ** Plan C Cons: > > - potential infrastructure complexity of freezing the epel9 buildroot > > - changing our messaging right before the launch > > Another con: breaks a foundational promise of EPEL. > "builds against rhel". Now, of course we don't have that said anywhere, > but some people really really like that it's built against RHEL and will > be quite upset when it's built against stream. :( > Not to say we can't do it, but I bet there will be yelling. I see an easy pivot there of "built against RHEL, once it reaches GA release". I think far more people would be happy about having day 1 EPEL9 packages than would be upset about this slight shift. > > We already sync stream, but this will require us to 'freeze' it, which > could be tricky. I'm specifically interested in how difficult this would be from the infra perspective. That is definitely a factor. > > > Please let us know what you think. > > If we do choose to go with Plan B or C we will need to make the decision > > fairly quickly. > > I like A. ;) > > I think B is risky because of the possible changes between beta and ga, > and I think C is breaking the 'we build against rhel' implied promise as > well as leaving a window with no security updates between branching and > GA. > > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ 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: python-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 3:05 PM Josh Boyer wrote: > > On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa wrote: > > > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote: > > > > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer wrote: > > > > > > > > Hi folks, > > > > > > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we > > > > cannot build python-gevent on EPEL 9 easily. > > > > > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm > > > > > > You could request libev-devel in the composes. I remain confused why > > > it has to be in the compose though, because libev and it's devel > > > package are accessible in the CentOS Stream 9 buildroots today. > > > > > > > We can't use them in EPEL if they're not in CRB. > > Yes, that's what everyone keeps telling me. I don't understand why. EPEL builds against published RHEL content, not the CentOS Stream buildroot. Having a package available in the CentOS Stream buildroot doesn't make it accessible to EPEL builds. We can't change EPEL to use the CentOS Stream buildroot because that will cause some EPEL packages to not be installable on RHEL. On a related note, EPEL 9 Next _is_ being set up to build against the CentOS Stream 9 buildroot. This works for EPEL Next because it explicitly targets the next minor release of RHEL (i.e. CentOS Stream). This will allow more packages to be built, at the cost of potentially confusing packagers when their package builds successfully for EPEL 9 Next but not for EPEL 9. EPEL 8 Next currently builds against published CentOS Stream 8 content. If things go well with EPEL 9 Next using the CentOS Stream 9 buildroot, EPEL 8 Next may switch to using the CentOS Stream 8 buildroot in the future. > > 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
[EPEL-devel] Re: Rebasing nlohmann_json to 3.6.1 in EPEL7
On Mon, Aug 2, 2021 at 8:38 PM Kyle Knoepfel wrote: > > Hi all, > > I am rebasing nlohmann_json from 3.3.1 to 3.6.1 in epel7 to agree with the > version in epel8. This change is necessary for supporting a new epel7 package > jsonnet. > > Bodhi update: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b95dc99fad > > Assuming no issues or objections I will push it in to the stable when > possible. > > Thanks, > Kyle > ___ > 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 How compatible is this upgrade? You may need to take additional steps as detailed in the incompatible upgrade policy. https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy -- Carl George ___ 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
This looks great so far to me. Should we also encourage/require modifying the release to have a leading `0.` so that it will upgrade cleanly when/if RHEL adds the relevant subpackage? On Thu, Jul 1, 2021 at 5:30 PM Kevin Fenzi wrote: > > 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 > ___ > 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 -- Carl George ___ 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] EPEL 8 Next is now available
Howdy folks, On behalf of the EPEL Steering Committee, I'm happy to announce the availability of EPEL 8 Next. This is an additional repository that allows package maintainers to build against CentOS Stream 8 instead of RHEL 8. This is sometimes necessary when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL. You can read more about it in the wiki [0]. Special thanks goes out to the Fedora Release Engineering team for their help implementing this. [0] https://fedoraproject.org/wiki/EPEL_Next -- Carl George ___ 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: EPEL 8 Next
Howdy again folks, I know people have been curious about what happened with this proposal. I apologize for the lack of updates in this thread. The proposal was approved by unanimous vote by the EPEL Steering Committee last October [0]. It has been a regular topic at the weekly committee meetings since then, with slow but steady progress. I'm happy to report that we are near completion of the work to launch EPEL Next. Initial documentation is on the wiki [1]. Fedpkg 1.40-6 [2] added support for requesting epel8-next branches, and has been widely available since April. The epel-next-release subpackage is currently available in the testing repo [3]. There is already one package available in the repo (qt5-qtwebkit [4]), which we used to verify the pipeline worked correctly. Let me know if there is anything else you would like to see in the documentation, especially FAQ items [5]. I would also appreciate any testing and karma on the epel-next-release bodhi update [2]. If you have a package that requires an EPEL Next rebuild (mainly qt packages currently), go ahead and try the workflow [6] and report any issues. [0] https://meetbot.fedoraproject.org/teams/epel/epel.2020-10-23-21.01.html [1] https://fedoraproject.org/wiki/EPEL_Next [2] https://src.fedoraproject.org/rpms/fedpkg/c/ee2d8465803e11c236ae764d445b99593d835353?branch=rawhide [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-159d68a2ef [4] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2021-c0fcb78eb0 [5] https://fedoraproject.org/wiki/EPEL_Next#FAQ [6] https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow On Tue, Sep 8, 2020 at 11:00 PM 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) > - used *with* epel8, not *instead of* > > 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. > > 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. > > -- > Carl George -- Carl George ___ 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: What about future EPEL for Centos ?
I can confirm, this issue affects very few EPEL packages, less than 1% (excluding packages that don't install on RHEL8 either) [0]. The numbers were very similar when RHEL was 8.3 and CS8 tracked 8.4 content. Most of those got resolved with the RHEL 8.4 release, but in exchange CS8 now has that qt5 rebase which is coming in 8.5. These problems are short lived (~6 months), small in number, and we'll see even fewer of them over time as RHEL maintainers do fewer rebases later in the RHEL lifecycle. We also plan to make epel-next a fairly seamless experience for CS8 users by having epel-release recommend epel-next-release if centos-stream-release is installed [1]. [0] https://twitter.com/carlwgeorge/status/1396960645250158593 [1] https://src.fedoraproject.org/rpms/epel-release/pull-request/13 On Mon, Jun 7, 2021 at 10:53 AM Matthew Miller wrote: > > On Mon, Jun 07, 2021 at 01:51:36PM +, john tatt wrote: > > I mean: will Epel follow Centos Stream and in this case not surely be > > compatible with RHEL 8 ?, or > > Troy answered the overall questions separately, but... in practice, I expect > this to be a very small issue. How often has it been that RHEL minor updates > have required EPEL packages to be rebuilt, or EPEL packages built on the > latest to not install on older point-releases of RHEL? I'm sure it happens > occasionally, but it's not the typical case. > > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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 -- Carl George ___ 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: dpkg Requires po4a >= 0.59 on epel 8 but version available is po4a-0.52-4.el8
PowerTools is the CentOS equivalent of the RHEL CRB repository. EPEL
doesn't have any control over it. You'll have to convince the RHEL
maintainer to rebase that package.
https://bugzilla.redhat.com/enter_bug.cgi?product=Red Hat Enterprise
Linux 8=po4a=CentOS Stream
On Tue, May 11, 2021 at 6:13 PM Sérgio Basto wrote:
>
> Hi,
> Since this commit [1] I need po4a >= 0.59 to build dpkg , but [2],
> po4a is in powertools repo [3] , can we do something to update it ?
>
> Thank you.
>
>
> [1]
> https://github.com/guillemj/dpkg/commit/a74a91310260efe55cc986506fe208ae2776a45a
>
> [2]
> https://git.centos.org/rpms/po4a/
> import po4a-0.52-4.el8 CentOS Sources committed 2 years ago
>
> [3]
> dnf repoquery po4a --qf "%{repoid} %{sourcerpm}" --quiet
> powertools po4a-0.52-4.el8.src.rpm
>
> --
> Sérgio M. B.
> ___
> 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
--
Carl George
___
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: python39 in EPEL7
I think it's a fine idea, but I don't personally need it and don't have time to help. I think redefining %__python3 to /usr/bin/python3.9 on a per-specfile basis is fine, as long as we leave the default value (/usr/bin/python3.6) from RHEL alone. I'm not a fan of the %__python3_other macros, and would be happy to see them go away when python34 is retired (which can happen independently of python3.9). On Wed, Apr 7, 2021 at 2:36 AM Miro Hrončok wrote: > > On 07. 04. 21 4:50, Carl George wrote: > > What do you mean by support? The only thing EPEL supports (using the > > term loosely) is enabling Fedora packagers to branch and build their > > packages for EPEL. Any maintainer of the Fedora python3.9 package (or > > any related package necessary for bootstrapping) can request an epel7 > > branch and start building. The main thing to be aware of is to comply > > with EPEL policy [0], especially the part about not > > replacing/disturbing the base distribution. RHEL7 includes python3, > > so an epel7 python3.9 build would need to ensure it doesn't conflict > > with any filesystem paths from that package. > > > I believe the confusion is my fault. > > By "support" I've meant: Does EPEL-devel generally agree that adding Python > 3.9 > to EPEL 7 is a good idea, even if we don't phase out Python 3.4 at the same > time? > > E.g. building RPMs for Python 3.9 in EPEL would require redefining %__python3 > (or %__python3_other). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ 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: python39 in EPEL7
What do you mean by support? The only thing EPEL supports (using the term loosely) is enabling Fedora packagers to branch and build their packages for EPEL. Any maintainer of the Fedora python3.9 package (or any related package necessary for bootstrapping) can request an epel7 branch and start building. The main thing to be aware of is to comply with EPEL policy [0], especially the part about not replacing/disturbing the base distribution. RHEL7 includes python3, so an epel7 python3.9 build would need to ensure it doesn't conflict with any filesystem paths from that package. [0] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy On Tue, Mar 30, 2021 at 8:38 AM Pim Rupert wrote: > > Hello, > > I am posting to gather if there is enough support to provide python39 in EPEL. > > Currently, EL7 users wanting to run modern python apps under uwsgi can only > use uwsgi-plugin-pyton36@epel. New Django releases are expected to require > 3.8 or higher. There is a rh-python38 SCL, but this version does not have a > compatible uwsgi-plugin. > > From https://bugzilla.redhat.com/show_bug.cgi?id=1781940 I gather that there > is interest in getting python39 in EPEL. I talked to Miro Hrončok, who was > willing to work on packaging, if there would be sufficient support from EPEL. > > Thanks, > > Pim > ___ > 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 -- Carl George ___ 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: EPEL7 python3/python36 standardization
I had originally hoped to limit this guideline change to EPEL7's
python36 packages, not EPEL7's python34 packages or anything about
EPEL8. But I do see the appeal of taking it a step further to lay out
the guidelines for all EPEL python packages. The overall intent is to
have EPEL python package prefixes match the RHEL python stack they are
intended to work with. That means the recommended prefixes for EPEL7
would be python and python3. The recommended prefixes for EPEL8 would
be python2, python3, and python38.
Regarding EPEL7's python34 packages, all the changes discussed here
can take place without modifying the
python%{python3_other_pkgversion}- (python34-)
subpackages. EPEL7's python34 packages should just be retired as that
Python version is EOL upstream, but so far no one (myself included)
has stepped up to drive that effort. I don't know if it's worth the
effort, as surely some will complain about it being removed,
regardless of the upstream status.
I think a tracker bug would only be necessary if we made the prefix
recommendations a MUST. As a SHOULD, it would be fine to let packages
get corrected naturally over time. The important piece would be to
have the guideline in place for package reviews to reference, to
prevent any further packages using non-standard prefixes from being
added.
On Thu, Jan 21, 2021 at 11:28 AM Kevin Fenzi wrote:
>
> 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
> ___
> 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
--
Carl George
___
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
Re: [EPEL-devel] Re: EPEL7 python3/python36 standardization
I'm not sure I understand your question. This proposal is about python36 packages, not the existing python34 packages or hypothetical python38 packages. In any case, packages shouldn't be requiring python* directly. They automatically get a requirement on `python(abi) = X.Y` that serves this purpose. On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison wrote: > > > On Thu, 21 Jan 2021, Carl George wrote: > > > 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. > > Do we need to be explicit about how we spell any value of these keys > - e.g. should it be >Requires: python >= 38 > or >Requires: python >= 3.8 > ? > > -- > Andrew C. Aitchison Kendal, UK > and...@aitchison.me.uk > ___ > epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org -- Carl George ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7 python3/python36 standardization
I'm not sure I understand your question. This proposal is about python36 packages, not the existing python34 packages or hypothetical python38 packages. In any case, packages shouldn't be requiring python* directly. They automatically get a requirement on `python(abi) = X.Y` that serves this purpose. On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison wrote: > > > On Thu, 21 Jan 2021, Carl George wrote: > > > 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. > > Do we need to be explicit about how we spell any value of these keys > - e.g. should it be >Requires: python >= 38 > or >Requires: python >= 3.8 > ? > > -- > 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 -- Carl George ___ 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
Agreed. And if a maintainer decides to stick with the python36 name, they MUST provide the equivalent python3 name. I've captured those for what I'll add to the guidelines. On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote: > > On 21. 01. 21 7:19, Carl George wrote: > > 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. > > I'm fine with that, is we also say they MUST use %python_provide (or that the > packages MUST provide/obsolete python36-...). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- Carl George ___ 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
Re: [EPEL-devel] EPEL7 python3/python36 standardization
Agreed. And if a maintainer decides to stick with the python36 name, they MUST provide the equivalent python3 name. I've captured those for what I'll add to the guidelines. On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote: > > On 21. 01. 21 7:19, Carl George wrote: > > 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. > > I'm fine with that, is we also say they MUST use %python_provide (or that the > packages MUST provide/obsolete python36-...). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- Carl George ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
EPEL7 python3/python36 standardization
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.
--
Carl George
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
[EPEL-devel] Re: proposal: EPEL 8 Next
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? 2. I'm perfectly fine waiting until after F33 is done. That makes lots of sense. 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 > > > > > 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 beca
[EPEL-devel] Re: proposal: EPEL 8 Next
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. 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 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 > > > > -- > Carl George -- Carl George ___ 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
Re: Non-responsive maintainer: fedpop
Pull request has been rebased and is ready to be merged. Thanks for your help with this Richard. On Thu, Sep 24, 2020 at 6:59 PM Richard Shaw wrote: > > On Thu, Sep 24, 2020 at 4:34 PM Carl George wrote: >> >> I read the policy [0] as "major (bug | security) fixes", and the CVE >> is only rated as moderate [1]. Should the policy be read as "(major >> bug | any security) fixes"? I am not opposed to building the update >> on F31 as well. >> >> [0] >> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates >> [1] https://access.redhat.com/security/cve/CVE-2020-13962 > > > I'm not worried about getting that nit-pickey... If it addresses a CVE that's > good enough for me. > > It looks like mumble was rebuilt for a new protobuf, can you update (rebase) > your pull request so it's mergeable? > > If you can do that fairly soon I'll try to make some time to merge it and > perform the builds and push new updates. > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: fedpop
I read the policy [0] as "major (bug | security) fixes", and the CVE is only rated as moderate [1]. Should the policy be read as "(major bug | any security) fixes"? I am not opposed to building the update on F31 as well. [0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates [1] https://access.redhat.com/security/cve/CVE-2020-13962 On Thu, Sep 24, 2020 at 11:17 AM Ian McInerney wrote: > > In your original email you said that this resolves CVE bug [1], which says in > it: > > "NOTE: this issue affects multiple supported versions of Fedora. While only > one tracking bug has been filed, please correct all affected versions at the > same time. If you need to fix the versions independent of each other, you > may clone this bug as appropriate." > > That to me sounds like the CVE should be patched in F31 as well - so since > this update fixes it, the update would be suitable for F31. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1849735 > > -Ian > > On Thu, Sep 24, 2020 at 5:01 PM Carl George wrote: >> >> F32 is fine by me. Based on the updates policy [0], I don't believe >> this update qualifies under the "major bug fixes and security fixes" >> restriction for the previous stable release. >> >> [0] >> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates >> >> On Wed, Sep 23, 2020 at 2:54 PM Richard Shaw wrote: >> > >> > On Wed, Sep 23, 2020 at 2:42 PM Carl George wrote: >> >> >> >> Yes, the patch is from an upstream pull request [0] that has already >> >> been merged to the master branch [1] and is planned to be included in >> >> their next release [2] (it's not part of the current 1.3.2 tag). The >> >> pull request includes a comment linking to said pull request, per the >> >> packaging guidelines [3]. Mumble's traditional push-to-talk >> >> functionality doesn't work under Wayland; this patch adds dbus calls >> >> that can be mapped to keyboard shortcuts as a workaround. I've built >> >> it like this in COPR [4] and it's worked great for me so far. >> > >> > >> > So next, question... Do builds need to be performed all the way back to >> > f31, or is f32 okay? >> > >> > Thanks, >> > Richard >> > ___ >> > devel mailing list -- devel@lists.fedoraproject.org >> > To unsubscribe send an email to 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/devel@lists.fedoraproject.org >> >> >> >> -- >> Carl George >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to 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/devel@lists.fedoraproject.org > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: fedpop
F32 is fine by me. Based on the updates policy [0], I don't believe this update qualifies under the "major bug fixes and security fixes" restriction for the previous stable release. [0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#all-other-updates On Wed, Sep 23, 2020 at 2:54 PM Richard Shaw wrote: > > On Wed, Sep 23, 2020 at 2:42 PM Carl George wrote: >> >> Yes, the patch is from an upstream pull request [0] that has already >> been merged to the master branch [1] and is planned to be included in >> their next release [2] (it's not part of the current 1.3.2 tag). The >> pull request includes a comment linking to said pull request, per the >> packaging guidelines [3]. Mumble's traditional push-to-talk >> functionality doesn't work under Wayland; this patch adds dbus calls >> that can be mapped to keyboard shortcuts as a workaround. I've built >> it like this in COPR [4] and it's worked great for me so far. > > > So next, question... Do builds need to be performed all the way back to f31, > or is f32 okay? > > Thanks, > Richard > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org -- Carl George ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
