[EPEL-devel] EPEL Steering Committee elections - nomination time

[Troy Dawson]

This is the first year[1] we are having elections for the EPEL Steering
Committee members.
We are still in the nomination phase and have a week to go.
If you want to be nominated, or want to nominate someone with their
consent, please add them to the Nomination wiki page by May 8, 2024.

https://fedoraproject.org/wiki/EPEL/Nominations

There are four seats being voted for and currently six people running.

Thank You
Troy

[1] - First election for a very long time
--
___
epel-devel 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 Steering Committee members - election is coming

[Troy Dawson]

As discussed in previous meetings, we are having elections for EPEL
Steering Committee members with the Fedora 40 election sessions.[1]  We
will be voting on 4 committee seats this election, but after looking at the
logs, I am only seeing 3 people who have volunteered for re-election.

- Pablo Greco (pgreco)
- Troy Dawson (tdawson)
- Carl George (carlwgeorge)

If someone else would volunteer, that would be great.
Also, if you volunteered, and want to change your mind, it's not too late.

We can/will discuss this in this weeks meeting.

Troy
p.s. I know the elections page does not have EPEL up there yet, but I am
working with Aoife and we'll get up there.

[1] https://docs.fedoraproject.org/en-US/program_management/elections/
--
___
epel-devel 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 Packages SIG page rewrite

[Troy Dawson]

I have done a first draft to rewrite the EPEL Packagers SIG page.[1]
The most dramatic thing was that I took out all of the "What is EPEL" stuff.
That is all found elsewhere in the EPEL docs and was (in my opinion) the
confusing stuff, making people think you needed to join the SIG, and that
by joining the SIG you had more permissions than you really did.
I really only did a minor change to the requirements, simply adding the
part I thought was significant to members of the sig.
Let me know what ya'll think.
I've added 'meeting' to the issue, so it will be on the agenda for next
weeks meeting.

Troy

[1] - https://pagure.io/epel/pull-request/270
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce

[Troy Dawson]

This was approved at the last EPEL Steering Committee meeting.
You may go ahead with your plan.
Thank you for following the procedure.

On Mon, Jan 29, 2024 at 6:33 AM David Trudgian via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Dear all,
>
> Following advice from Neal elsewhere on this list [1], I’m requesting that
> the singularity-ce EPEL packages may be updated to 4.1.0 following the
> incompatible upgrade procedure. The justification for the upgrade is that
> 3.x singularity-ce is no longer maintained upstream. Note that because
> singularity-ce necessarily bundles many Go dependencies specified in
> upstream go.mod/go.sum, lack of maintenance can quickly lead to inherited
> security issues.
>
> Upstream singularity-ce (https://github.com/sylabs/singularity)
> maintenance is limited to the latest x.y minor version, currently 4.1. The
> upstream project has committed more formally to semantic versioning
> conventions since 4.0.0, so any 4.y.z minor (y) and patch (z) version
> updates are expected to be compatible upgrades for EPEL purposes.
>
> At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to
> incompatible changes.
>
> Incompatibilities from 3.11.5 -> 4.1.0 are as follows:
>
> (a) The CLI has split some functionality previously provided by the
> `singularity remote` command into new `singularity registry` and
> `singularity keyserver` commands.
> (b) The `singularity remote add` command now sets a newly added remote as
> the default (unless suppressed). Previously the user had to set the default
> remote manually.
> (c) The `—vm` flag to start `singularity` inside a Virtual Machine has
> been removed. This was not intended to be user facing, but was used by a
> separate and proprietary Singularity Desktop project that has been retired
> for some time. `—vm` was unmaintained, and I don’t believe there is any
> practical use outside of this context.
>
> (d) Bind mounts are now performed in the order in which they are
> specified. Previously, image based bind mounts were performed before others.
> (e) Current working directory on the host is now created in the container,
> restoring a behaviour from Singularity <3.6.0 unless suppressed.
> (f) If the current directory paths on the container and host contains
> symlinks to different locations, the current working directory is not
> mounted.
>
> The above are expected to have a minor impact on users. Arguably
> (d)/(e)/(f) are bug fixes as they address issues reported by users as
> unexpected behaviour. Changes (e)/(f) were also previously included in the
> apptainer project's upgrade to their v1.2.0 that was not submitted as an
> incompatible upgrade.
>
> Highlighting also for Dave Dykstra’s benefit that any thoughts around the
> relevance of incompatible upgrade policy to (b) & (c) will also be relevant
> to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled both of
> these changes from singularity-ce upstream.
>
> Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible.
> Configuration files do not need to be modified.
>
> Many Thanks,
>
> Dave Trudgian
>
> [1]
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/IQENLTYUAIMOTAX4LUWHYINOPSCRWCIS/
> --
> ___
> epel-devel 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] Re: EL9: conflict gpgme1.22 vs gpgme

[Troy Dawson]

On Tue, Feb 6, 2024 at 8:07 AM Leon Fauster via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Am 06.02.24 um 16:57 schrieb Leon Fauster:
> > Hi troy,
> >
> > after deinstalling gpgme1.22 I get a broken linkage.
> > This link should not happen in the first place, right?
> >
> >
> > # ls -la /usr/lib64/libgpgme*
> > lrwxrwxrwx. 1 root root 20  6. Feb 14:35 /usr/lib64/libgpgmepp.so.6
> > -> libgpgmepp.so.6.19.0
> > lrwxrwxrwx. 1 root root 19  6. Feb 14:35 /usr/lib64/libgpgme.so.11
> > -> libgpgme.so.11.31.0
> > -rwxr-xr-x. 1 root root 350864 13. Mai 2022
> /usr/lib64/libgpgme.so.11.24.1
> >
> > # rpm -qf /usr/lib64/libgpgme.so.11
> > gpgme-1.15.1-6.el9.x86_64
> >
> >
>

Ugg ... you are correct.
Looks like the library linker needs to be re-run on post install.


>
>
> It seems that libreoffice-core needs "libgpgmepp.so.6()(64bit)" and dnf
> chooses  gpgme1.22 from epel instead gpgme from appstream.
>
>
> # LANG=C dnf whatprovides "libgpgmepp.so.6()(64bit)"
> Last metadata expiration check: 4:43:48 ago on Tue Feb  6 12:21:37 2024.
> gpgme1.22pp-1.22.0-1.el9.x86_64 : C++ bindings/wrapper for GPGME
> Repo: epel
> Matched from:
> Provide: libgpgmepp.so.6()(64bit)
>
> gpgmepp-1.15.1-6.el9.x86_64 : C++ bindings/wrapper for GPGME
> Repo: appstream
> Matched from:
> Provide: libgpgmepp.so.6()(64bit)
>

I really thought I'd gotten the provides right for that package.
That's not as straight forward as the linker not being run.
I wouldn't mind a hand poking at this so we can get it right.

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

[EPEL-devel] Re: Bodhi 8.0.2 deployed to prod today

[Troy Dawson]

On Mon, Feb 5, 2024 at 11:20 AM Mattia Verga via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Hello,
> I'd like to announce that Bodhi 8.0.2 has been deployed today and brings a
> feature which was requested specifically for EPEL: from now on (if
> everything works as expected) all builds submitted as buildroot overrides
> for EPEL9 will also be tagged as buildroot overrides for EPEL9N.
> This is not hardcoded, but is rather configurable in Bodhi config file.
> Here it is the example that makes the current EPEL9-EPEL9N inheritance:
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templates/production.ini.j2#_630
> The line above (commented out) is just an example to show that this can
> work for multiple releases at once.
>
> Apart from that, Bodhi 8.0 also makes possible to define different
> createrepo_c settings per release in an external config file.
> The file is:
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/backend/files/createrepo_c.ini
> and I hope it is sufficiently self explanatory and clear.
> I just want to write it here on the EPEL list, as the EPEL releases are
> those which need different settings from Fedora release. I copied the
> previously hardcoded values within Bodhi and I hope to have not misread any
> value.
>
> Mattia
>

Thank you.
The override on epel9 but not going to epel9-next has always been a pain
point for me and I really appreciate it getting fixed, especially when I
never opened a bug/feature request on it.  Your mind reading is awesome.

Thanks again,
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

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

Unless someone has objections (which I haven't heard any since my last
mail) I am canceling this weeks EPEL Steering Committee meeting.

We will be meeting at the new time next week (2024-02-07)


On Tue, Jan 30, 2024 at 10:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2024-01-31 from 18:00:00 to 19:00:00 UTC
>At fedora-meet...@chat.fedoraproject.org
>
> The meeting will be about:
> https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org
>
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #topic aloha
>
> #topic EPEL Issues https://pagure.io/epel/issues
> * https://pagure.io/epel/issues?tags=meeting=Open
>
> #topic Old Business
>
> #topic General Issues / Open Floor
>
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> --
> ___
> epel-devel 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] Re: Incompatible Upgrade Request - singularity-ce

[Troy Dawson]

On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa  wrote:

> On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel
>  wrote:
> >
> > Dear all,
> >
> > Following advice from Neal elsewhere on this list [1], I’m requesting
> that the singularity-ce EPEL packages may be updated to 4.1.0 following the
> incompatible upgrade procedure. The justification for the upgrade is that
> 3.x singularity-ce is no longer maintained upstream. Note that because
> singularity-ce necessarily bundles many Go dependencies specified in
> upstream go.mod/go.sum, lack of maintenance can quickly lead to inherited
> security issues.
> >
> > Upstream singularity-ce (https://github.com/sylabs/singularity)
> maintenance is limited to the latest x.y minor version, currently 4.1. The
> upstream project has committed more formally to semantic versioning
> conventions since 4.0.0, so any 4.y.z minor (y) and patch (z) version
> updates are expected to be compatible upgrades for EPEL purposes.
> >
> > At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to
> incompatible changes.
> >
> > Incompatibilities from 3.11.5 -> 4.1.0 are as follows:
> >
> > (a) The CLI has split some functionality previously provided by the
> `singularity remote` command into new `singularity registry` and
> `singularity keyserver` commands.
> > (b) The `singularity remote add` command now sets a newly added remote
> as the default (unless suppressed). Previously the user had to set the
> default remote manually.
> > (c) The `—vm` flag to start `singularity` inside a Virtual Machine has
> been removed. This was not intended to be user facing, but was used by a
> separate and proprietary Singularity Desktop project that has been retired
> for some time. `—vm` was unmaintained, and I don’t believe there is any
> practical use outside of this context.
> >
> > (d) Bind mounts are now performed in the order in which they are
> specified. Previously, image based bind mounts were performed before others.
> > (e) Current working directory on the host is now created in the
> container, restoring a behaviour from Singularity <3.6.0 unless suppressed.
> > (f) If the current directory paths on the container and host contains
> symlinks to different locations, the current working directory is not
> mounted.
> >
> > The above are expected to have a minor impact on users. Arguably
> (d)/(e)/(f) are bug fixes as they address issues reported by users as
> unexpected behaviour. Changes (e)/(f) were also previously included in the
> apptainer project's upgrade to their v1.2.0 that was not submitted as an
> incompatible upgrade.
> >
> > Highlighting also for Dave Dykstra’s benefit that any thoughts around
> the relevance of incompatible upgrade policy to (b) & (c) will also be
> relevant to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled
> both of these changes from singularity-ce upstream.
> >
> > Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible.
> Configuration files do not need to be modified.
> >
>
> This seems reasonable to me.
>

I agree with Neal, this looks good to me.
Thank you for the nice explanation/write-up.

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

[EPEL-devel] Canceling this weeks EPEL Steering Committee meeting

[Troy Dawson]

Hello,
Many of the EPEL Steering Committee members will be at a conference this
Wedensday.
We have also changed the meeting time to 1800 UTC  (Same date and location).
We don't have much (or anything) to cover.

Unless something dramatic comes up.  I would like to cancel this weeks
meeting.

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

Re: Fedora 40 Mass Rebuild *finish* delayed

[Troy Dawson]

On Wed, Jan 24, 2024 at 2:01 AM Miroslav Suchý  wrote:

> Dne 24. 01. 24 v 10:51 Aoife Moloney napsal(a):
> >
> > All other milestones remain the same at this time and the published
> schedule[4] has been updated to reflect these changes.
>
> https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
>
> Branching is set to 2024-02-06 while mass rebuilds are supposed to finish
> by 2024-02-20. That means we will branch
> during mass rebuilds?
>
> Historically we always branched *after* the mass rebuilds finishes.
>

The proposal that passed was this.
"Delay the F40 schedule 1 week for everything up to and including the start
of the Beta Freeze"
Branching falls into the list of tasks that is affected by one week.
Although they didn't change the schedule yet (and you aren't the first to
notice that) it has been pushed back a week.
So branching *should* be 2024-02-13

Troy
--
___
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: Broken version of wsdd released in EPEL7

[Troy Dawson]

The way to stop it from being pushed is to give it negative karma in it's
bodhi testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4e7c9d636e

You know what's strange, the updates-testing report that get's
automatically generated, doesn't put the bodhi link in for the new
packages.  It gives all sorts of details about the new package, but not the
bodhi testing link.
But it does give the link for the older packages.


On Fri, Dec 15, 2023 at 12:20 AM Nick Howitt via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> When it was announced that wsdd-0.7.1-1.el7 was available for testing, I
> responded to the announcement that it was a bad installation with
> breaking changes and raised a bug
> https://bugzilla.redhat.com/show_bug.cgi?id=2253415. Unfortunately, my
> bug report and mailing list response have been ignored and now there has
> bee a breaking release. How can we get it fixed and what could I have
> done differently to get it fixed prior to release?
>
> Regards,
>
>
> 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
>
--
___
epel-devel 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 (again) for llhttp in EPEL9

[Troy Dawson]

On Tue, Nov 28, 2023 at 8:37 AM Ben Beasley  wrote:

> This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 to
> 9.1.3, 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 python-aiohttp prior to 3.8.6[2] are affected by
> CVE-2023-47627[3][4], an HTTP request/response smuggling vulnerability
> rated 5.3 in CVSS v3 and rated Moderate by Red Hat. This was reported as
> RHBZ#2249825[5]. Since the flaw is only in the pure-Python parser, and
> we compile the llhttp-based parser, this affects only code using the
> AIOHTTP_NO_EXTENSIONS environment variable. Updating aiohttp from 3.8.5
> to 3.8.6 to fix that still requires updating llhttp from 8.x to 9.x.
> Additionally, according to the release notes this includes an
> llhttp-related security fix[6] with no assigned CVE, which provides
> added motivation to update.
>
> The ABI break in llhttp would only affect python-aiohttp. The
> python-aiohttp update itself is compatible (by upstream intent, and as
> already demonstrated in Rawhide and F39/F38); and a large list of
> packages that depend on python-aiohttp would benefit from the fix. The
> necessary rebuild would be conducted in a side tag.
>
> The same incompatible update was approved by FESCo for Fedora 38 and
> 39[7]. Furthermore, it appears that FESCo will approve a permanent
> exception for llhttp[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://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
>
> [3] https://access.redhat.com/security/cve/CVE-2023-47627
>
> [4]
> https://github.com/aio-libs/aiohttp/security/advisories/GHSA-gfw2-4jvh-wgfg
>
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=2249825
>
> [6] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
>
> [7] https://pagure.io/fesco/issue/3106
>
> [8] https://pagure.io/fesco/issue/3115
>
>
This exception, as well as a permanent exception, was approved this week in
the EPEL Steering Committee meeting.

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

[EPEL-devel] Re: Packages to be untagged from epel-next

[Troy Dawson]

I haven't heard any negative feedback from these.
I will untag these today.

On Wed, Nov 15, 2023 at 12:55 PM Troy Dawson  wrote:

> The following packages have the same version in epel-next as in epel.
> I plan on untagging them from epel-next unless people tell me otherwise.
>
> epel8-next:
> boinc-client-7.20.2-1.el8.next
> darktable-3.8.1-2.el8.next
> kimageannotator-0.6.1-1.el8.next
> ksnip-1.10.1-1.el8.next
> python3.11-dns-epel-2.2.1-2.el8.next
> python3.11-jmespath-epel-1.0.1-1.el8.next
>
> epel9-next:
> cargo2rpm-0.1.13-1.el9.next
> keepassxc-2.7.6-1.el9.next
> python3.11-dns-epel-2.2.1-2.el9.next
> python3.11-jmespath-epel-1.0.1-1.el9.next
> python3.11-netaddr-epel-0.8.0-1.el9.next
> python3.11-ntlm-auth-epel-1.5.0-1.el9.next
> rust-addr2line-0.19.0-1.el9.next
> rust-aho-corasick-1.1.2-1.el9.next
> rust-ansiterm-0.12.2-1.el9.next
> rust-arbitrary-1.3.0-1.el9.next
> rust-automod-1.0.13-1.el9.next
> rust-backtrace-0.3.67-2.el9.next
> rust-bitflags-2.4.1-1.el9.next
> rust-bstr0.2-0.2.17-1.el9.next
> rust-bstr-1.7.0-1.el9.next
> rust-bumpalo-3.14.0-1.el9.next
> rust-bytesize-1.3.0-1.el9.next
> rust-byte-unit-4.0.19-1.el9.next
> rust-cargo-0.64.0-3.el9.next
> rust-clap3-3.2.25-1.el9.next
> rust-clap_complete3-3.2.5-1.el9.next
> rust-clap_derive3-3.2.25-1.el9.next
> rust-crossbeam-epoch-0.9.15-2.el9.next
> rust-csv-1.3.0-1.el9.next
> rust-csv-core-0.1.11-1.el9.next
> rust-ctor-0.2.5-1.el9.next
> rust-deranged-0.3.8-1.el9.next
> rust-directories4-4.0.1-1.el9.next
> rust-directories-5.0.1-1.el9.next
> rust-env_logger-0.10.0-1.el9.next
> rust-env_logger0.9-0.9.3-1.el9.next
> rust-grep-cli-0.1.7-1.el9.next
> rust-grep-printer-0.1.7-1.el9.next
> rust-grep-regex-0.1.11-1.el9.next
> rust-grep-searcher-0.1.11-1.el9.next
> rust-half1-1.8.2-1.el9.next
> rust-hashbrown-0.14.2-1.el9.next
> rust-ignore-0.4.20-1.el9.next
> rust-indexmap-2.0.2-1.el9.next
> rust-is_executable-1.0.1-1.el9.next
> rust-jobserver-0.1.27-1.el9.next
> rust-lexopt-0.3.0-1.el9.next
> rust-libc-0.2.149-1.el9.next
> rust-libm-0.2.8-1.el9.next
> rust-lock_api-0.4.11-1.el9.next
> rust-memchr-2.6.4-1.el9.next
> rust-miniz_oxide0.5-0.5.4-1.el9.next
> rust-miniz_oxide-0.7.1-3.el9.next
> rust-num_enum-0.5.11-1.el9.next
> rust-num_enum_derive-0.5.11-1.el9.next
> rust-num-traits-0.2.17-1.el9.next
> rust-object-0.30.3-1.el9.next
> rust-os_pipe0.9-0.9.2-3.el9.next
> rust-os_str_bytes-6.6.1-1.el9.next
> rust-packaging-25.2-1.el9.next
> rust-parking_lot_core-0.9.9-1.el9.next
> rust-predicates-core-1.0.6-1.el9.next
> rust-print_bytes-1.2.0-1.el9.next
> rust-proc-macro2-1.0.69-1.el9.next
> rust-rayon-1.8.0-1.el9.next
> rust-rayon-core-1.12.0-1.el9.next
> rust-regex-1.10.2-1.el9.next
> rust-regex-automata-0.4.3-1.el9.next
> rust-regex-syntax0.7-0.7.5-1.el9.next
> rust-regex-syntax-0.8.2-1.el9.next
> rust-relative-path-1.9.0-1.el9.next
> rust-roff0.1-0.1.0-1.el9.next
> rust-roff-0.2.1-1.el9.next
> rust-rpassword5-5.0.1-1.el9.next
> rust-rpassword-7.2.0-1.el9.next
> rust-rstest-0.18.2-1.el9.next
> rust-rstest_macros-0.18.2-1.el9.next
> rust-rstest_reuse-0.6.0-1.el9.next
> rust-rtoolbox-0.0.1-1.el9.next
> rust-rust_decimal-1.32.0-1.el9.next
> rust-serde-1.0.189-1.el9.next
> rust-serde_derive-1.0.189-1.el9.next
> rust-serde_json-1.0.107-1.el9.next
> rust-shared_child-1.0.0-3.el9.next
> rust-smallvec-1.11.1-1.el9.next
> rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
> rust-strip-ansi-escapes-0.2.0-1.el9.next
> rust-syn-2.0.38-1.el9.next
> rust-system-deps-6.1.2-1.el9.next
> rust-tempfile-3.8.0-1.el9.next
> rust-termcolor-1.3.0-1.el9.next
> rust-terminal_size0.2-0.2.6-1.el9.next
> rust-terminal_size-0.3.0-1.el9.next
> rust-textwrap0.15-0.15.2-1.el9.next
> rust-textwrap-0.16.0-1.el9.next
> rust-thread-id-4.2.1-1.el9.next
> rust-timeago-0.4.2-1.el9.next
> rust-time-core-0.1.1-1.el9.next
> rust-toml0.5-0.5.11-1.el9.next
> rust-toml0.7-0.7.8-1.el9.next
> rust-toml-0.8.2-1.el9.next
> rust-toml_edit0.19-0.19.15-1.el9.next
> rust-toml_edit-0.20.2-1.el9.next
> rust-ucd-parse-0.1.10-1.el9.next
> rust-winnow0.4-0.4.11-1.el9.next
> rust-winnow-0.5.16-1.el9.next
> rust-xml-rs-0.8.19-1.el9.next
>
>
> 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

[EPEL-devel] Re: qbittorrent in EPEL9

[Troy Dawson]

It looks like Jonathan Wright was the person who first requested it, I
don't know if he wants it or not..
I find it interesting that the person who has been maintaining the package
in Fedora for the past couple years isn't listed on the owners list.

Doing some quick scratch builds, it looks like the latest version in
Rawhide (qbittorrent-4.6.0-1.fc40) doesn't build on epel9
_

/usr/include/libtorrent/storage.hpp:5:2: error: #error "the disk I/O
subsystem has been overhauled in libtorrent 2.0. storage_interface is no
longer a customization point, customize disk_interface instead"
5 | #error "the disk I/O subsystem has been overhauled in libtorrent
2.0. storage_interface is no longer a customization point, customize
disk_interface instead"
_

But, it looks like an older version (qbittorrent-4.4.1-1.fc34) builds fine.

Just something to think about for whoever decides to take it.

Troy

On Thu, Nov 16, 2023 at 4:06 PM Palla Dium via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Hello,
>
> as per the EPEL package request documentation, I am kindly asking if there
> are any packagers who would like to package and maintain qbittorrent on
> EPEL. The request has been stalled since February 2023.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2172281
> https://src.fedoraproject.org/rpms/qbittorrent
>
> This would also require updating rb_libtorrent-devel to the latest
> version: https://src.fedoraproject.org/rpms/rb_libtorrent
>
> Thank you very much.
> --
> ___
> epel-devel 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] Packages to be untagged from epel-next

[Troy Dawson]

The following packages have the same version in epel-next as in epel.
I plan on untagging them from epel-next unless people tell me otherwise.

epel8-next:
boinc-client-7.20.2-1.el8.next
darktable-3.8.1-2.el8.next
kimageannotator-0.6.1-1.el8.next
ksnip-1.10.1-1.el8.next
python3.11-dns-epel-2.2.1-2.el8.next
python3.11-jmespath-epel-1.0.1-1.el8.next

epel9-next:
cargo2rpm-0.1.13-1.el9.next
keepassxc-2.7.6-1.el9.next
python3.11-dns-epel-2.2.1-2.el9.next
python3.11-jmespath-epel-1.0.1-1.el9.next
python3.11-netaddr-epel-0.8.0-1.el9.next
python3.11-ntlm-auth-epel-1.5.0-1.el9.next
rust-addr2line-0.19.0-1.el9.next
rust-aho-corasick-1.1.2-1.el9.next
rust-ansiterm-0.12.2-1.el9.next
rust-arbitrary-1.3.0-1.el9.next
rust-automod-1.0.13-1.el9.next
rust-backtrace-0.3.67-2.el9.next
rust-bitflags-2.4.1-1.el9.next
rust-bstr0.2-0.2.17-1.el9.next
rust-bstr-1.7.0-1.el9.next
rust-bumpalo-3.14.0-1.el9.next
rust-bytesize-1.3.0-1.el9.next
rust-byte-unit-4.0.19-1.el9.next
rust-cargo-0.64.0-3.el9.next
rust-clap3-3.2.25-1.el9.next
rust-clap_complete3-3.2.5-1.el9.next
rust-clap_derive3-3.2.25-1.el9.next
rust-crossbeam-epoch-0.9.15-2.el9.next
rust-csv-1.3.0-1.el9.next
rust-csv-core-0.1.11-1.el9.next
rust-ctor-0.2.5-1.el9.next
rust-deranged-0.3.8-1.el9.next
rust-directories4-4.0.1-1.el9.next
rust-directories-5.0.1-1.el9.next
rust-env_logger-0.10.0-1.el9.next
rust-env_logger0.9-0.9.3-1.el9.next
rust-grep-cli-0.1.7-1.el9.next
rust-grep-printer-0.1.7-1.el9.next
rust-grep-regex-0.1.11-1.el9.next
rust-grep-searcher-0.1.11-1.el9.next
rust-half1-1.8.2-1.el9.next
rust-hashbrown-0.14.2-1.el9.next
rust-ignore-0.4.20-1.el9.next
rust-indexmap-2.0.2-1.el9.next
rust-is_executable-1.0.1-1.el9.next
rust-jobserver-0.1.27-1.el9.next
rust-lexopt-0.3.0-1.el9.next
rust-libc-0.2.149-1.el9.next
rust-libm-0.2.8-1.el9.next
rust-lock_api-0.4.11-1.el9.next
rust-memchr-2.6.4-1.el9.next
rust-miniz_oxide0.5-0.5.4-1.el9.next
rust-miniz_oxide-0.7.1-3.el9.next
rust-num_enum-0.5.11-1.el9.next
rust-num_enum_derive-0.5.11-1.el9.next
rust-num-traits-0.2.17-1.el9.next
rust-object-0.30.3-1.el9.next
rust-os_pipe0.9-0.9.2-3.el9.next
rust-os_str_bytes-6.6.1-1.el9.next
rust-packaging-25.2-1.el9.next
rust-parking_lot_core-0.9.9-1.el9.next
rust-predicates-core-1.0.6-1.el9.next
rust-print_bytes-1.2.0-1.el9.next
rust-proc-macro2-1.0.69-1.el9.next
rust-rayon-1.8.0-1.el9.next
rust-rayon-core-1.12.0-1.el9.next
rust-regex-1.10.2-1.el9.next
rust-regex-automata-0.4.3-1.el9.next
rust-regex-syntax0.7-0.7.5-1.el9.next
rust-regex-syntax-0.8.2-1.el9.next
rust-relative-path-1.9.0-1.el9.next
rust-roff0.1-0.1.0-1.el9.next
rust-roff-0.2.1-1.el9.next
rust-rpassword5-5.0.1-1.el9.next
rust-rpassword-7.2.0-1.el9.next
rust-rstest-0.18.2-1.el9.next
rust-rstest_macros-0.18.2-1.el9.next
rust-rstest_reuse-0.6.0-1.el9.next
rust-rtoolbox-0.0.1-1.el9.next
rust-rust_decimal-1.32.0-1.el9.next
rust-serde-1.0.189-1.el9.next
rust-serde_derive-1.0.189-1.el9.next
rust-serde_json-1.0.107-1.el9.next
rust-shared_child-1.0.0-3.el9.next
rust-smallvec-1.11.1-1.el9.next
rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
rust-strip-ansi-escapes-0.2.0-1.el9.next
rust-syn-2.0.38-1.el9.next
rust-system-deps-6.1.2-1.el9.next
rust-tempfile-3.8.0-1.el9.next
rust-termcolor-1.3.0-1.el9.next
rust-terminal_size0.2-0.2.6-1.el9.next
rust-terminal_size-0.3.0-1.el9.next
rust-textwrap0.15-0.15.2-1.el9.next
rust-textwrap-0.16.0-1.el9.next
rust-thread-id-4.2.1-1.el9.next
rust-timeago-0.4.2-1.el9.next
rust-time-core-0.1.1-1.el9.next
rust-toml0.5-0.5.11-1.el9.next
rust-toml0.7-0.7.8-1.el9.next
rust-toml-0.8.2-1.el9.next
rust-toml_edit0.19-0.19.15-1.el9.next
rust-toml_edit-0.20.2-1.el9.next
rust-ucd-parse-0.1.10-1.el9.next
rust-winnow0.4-0.4.11-1.el9.next
rust-winnow-0.5.16-1.el9.next
rust-xml-rs-0.8.19-1.el9.next


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

[EPEL-devel] EPEL Steering Committee meeting moving to matrix

[Troy Dawson]

At last weeks EPEL Steering Committee meeting it was decided to move from
Libera IRC #fedora-meeting to Fedora Matrix #meeting.[1]

This week (November 15, 2023) will be our first meeting on the new Matrix
channel.

This is the link:
https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

Documentation changes are still being worked on.

Thank You
EPEL Steering Committee

[1] - This channel was originally called #fedora-meeting, but the 'fedora'
was considered redundant and dropped.
___
epel-devel 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: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

Sorry, I didn't get this updated before the email went out.

We will now be meeting on the Fedora Meeting room on Fedora Matrix

https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

On Tue, Nov 14, 2023 at 8:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2023-11-15 from 16:00:00 to 17:00:00
> US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #topic aloha
>
> #topic EPEL Issues https://pagure.io/epel/issues
> * https://pagure.io/epel/issues?tags=meeting=Open
>
> #topic Old Business (if needed)
>
> #topic General Issues / Open Floor
>
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> ___
> epel-devel 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] KDE Updated in EPEL9

[Troy Dawson]

KDE has been updated in EPEL9.
Versions:
Plasma: 5.27.6
KF5: 5.108
Apps: 23.04.3

Known Issues:
- kdepim-addons - Was not updated due to kf5-kitinerary not being updated
due to older poplar in RHEL 9.
-- The older version of kdepim-addons is not liking the newer libraries.
-- Should be fixed this week.
- lokalize - Does not install, has never installed.  I kept thinking I
could get it's dependencies in, but never have.
-- I will be removing this package from epel9.  Since it was
un-installable, this shouldn't affect anyone.

Deprecation:
We are marking the following packages deprecated.  They will not be in
epel10.  They will continue to be in epel9.
- plasma-workspace-x11
- sddm-x11

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

[EPEL-devel] Re: Upgrade of mlpack in epel-7

[Troy Dawson]

On Mon, Oct 30, 2023 at 11:10 PM Benson Muite 
wrote:

> On 10/30/23 16:37, Troy Dawson wrote:
> > On Sun, Oct 29, 2023 at 10:35 AM Benson Muite
> > mailto:benson_mu...@emailplus.org>> wrote:
> >
> > Would like to upgrade mlpack from 3.4.2 to 4.2.1
> > Version 3 is no longer maintained, and there do not seem to be
> > dependencies on mlpack, at least in Fedora. This is prompted by
> > CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
> > https://src.fedoraproject.org/rpms/mlpack/pull-request/12
> > <https://src.fedoraproject.org/rpms/mlpack/pull-request/12>
> >
> >
> > Since this is for a CVE, that is good.
> > Also, it looks like nothing depends on it, so that also makes things
> easier.
> >
> > Do you know of any features that were removed between version 3.x and
> 4.x?
> > In short, if someone were actively using version 3.x of mlpack, do you
> > know what they would need to change (if anything) to use the version 4.x?
> >
> The biggest change is that for development it became a header only
> library that requires C++14.  Had not realized non breaking changes
> should not be made, so the spec file is for version 4, but it does not
> build and so version 3.4.2 is still shipped.  Can revert changes in git
> history so that 3.4.2 is used, and update requirements on included stb
> header files if that is allowed.
>

If that is possible, and it fixes the CVE's, that would be best.

If you find that it isn't possible, or it doesn't fix the CVE's, then an
exception can be made.
Part of the exception process is to say what changes between the versions,
so people are prepared.
Having the list of things that change is also good when bugs get opened, we
can point them to that list.

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

[EPEL-devel] Re: Upgrade of mlpack in epel-7

[Troy Dawson]

On Sun, Oct 29, 2023 at 10:35 AM Benson Muite 
wrote:

> Would like to upgrade mlpack from 3.4.2 to 4.2.1
> Version 3 is no longer maintained, and there do not seem to be
> dependencies on mlpack, at least in Fedora. This is prompted by
> CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
> https://src.fedoraproject.org/rpms/mlpack/pull-request/12
>

Since this is for a CVE, that is good.
Also, it looks like nothing depends on it, so that also makes things easier.

Do you know of any features that were removed between version 3.x and 4.x?
In short, if someone were actively using version 3.x of mlpack, do you know
what they would need to change (if anything) to use the version 4.x?

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

[EPEL-devel] Re: retirement of klee from EPEL 9

[Troy Dawson]

On Thu, Sep 28, 2023 at 8:37 PM 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.
>
> [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/
>

Since it hasn't been able to be installed since RHEL 9.2 came out, I'm not
opposed to doing it ASAP.
Especially since they not only orphaned it, but they retired it back in
January.  And nobody came forward to "unorphan" it back then.

But, since it's not installable, so nobody is going to accidentally install
it, there is no rush either.
Either way is fine by me.

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

[EPEL-devel] gpsd status in epel9

[Troy Dawson]

gpsd-minimal has been added to RHEL 9.2 and CentOS Stream 9.
Although it has a different name than gpsd that is in Fedora and EPEL, the
binary packages inside have the same name.
Thus gpsd-minimal and gps-minimal-clients conflict with gpsd and
gpsd-clients from EPEL.  The RHEL packages have a Conflict setting in them,
so you cannot install both.

The binaries in gpsd-minimal and gps-minimal-clients are stand alone, and
thus there is no -libs, -devel or python packages.
Because of this, I have created a gpsd-epel package that only provides the
-libs, -devel and python3 packages, in the same version that was in epel9.
I used the epel9 version because there is a incompatible upgrade between
the epel version and the RHEL version.

* What does this mean to you as an EPEL9 user?
If you used the gpsd clients, you will need to install the gpsd-minimal and
gps-minimal-clients.
If you have epel or 3rd party packages that built using the gpsd from EPEL,
they will continue to work with no change needed on your end.

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

[EPEL-devel] Re: Proposed incompatible security update for llhttp in EPEL9

[Troy Dawson]

The voting at the EPEL Steering Committee meeting was unanimous, with no
negative votes.
Please proceed.


On Wed, Aug 9, 2023 at 1:20 PM Carl George  wrote:

> 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

[EPEL-devel] Re: Proposed incompatible security update for llhttp in EPEL9

[Troy Dawson]

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

[EPEL-devel] Re: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

The EPEL Steering Committee meeting has been canceled this week.
If you need your EPEL fix, you can watch the "State of EPEL" presentation
at Flock
https://flock2023.sched.com/event/1Or5D/state-of-epel
or any of the other great presentations at Flock.

On Tue, Aug 1, 2023 at 9:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2023-08-02 from 16:00:00 to 17:00:00
> US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #topic aloha
>
> #topic EPEL Issues https://pagure.io/epel/issues
> * https://pagure.io/epel/issues?tags=meeting=Open
>
> #topic Old Business (if needed)
>
> #topic General Issues / Open Floor
>
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> ___
> epel-devel 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] Re: Retiring Zim from EPEL

[Troy Dawson]

On Thu, Jul 20, 2023 at 2:41 AM Otto Liljalaakso 
wrote:

> Recently, I adopted the orphaned Zim package for Fedora. The previous
> maintainer had added the package to EPEL, while I am not involved with
> EPEL at all. Consequently, I will not maintain the EPEL branches anymore.
>
>  From going through the EPEC documentation, it looks like the Retirement
> Process: No Time or Desire [1] is the procedure I should follow. So,
> unless somebody steps up to maintain the EPEL branches for Zim, I will
> retire the package from EPEL.
>
> To my knowledge, there are no issues with Zim and EPEL. I am simply not
> involved with EPEL. The fact that there is no epel9 branch, only epel8
> and epel7, seems strange, but then, I do not know much about EPEL
> package maintenance.
>
> In case I am following the wrong process, please let me know and point
> me to the correct one.
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire
>

That is the right process.  Thank you for following it.

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

Re: Fedora ELN Plans for Summer 2023

[Troy Dawson]

On Fri, Jun 16, 2023 at 6:42 AM Stephen Gallagher 
wrote:

> == Open Questions ==
> 1) For the "canary" Fedora ELN rebuild, we have two choices on how to
> select the git hash to be built for each package in the ELN list:
>
> Approach 1 (Rawhide-style):
> 1. Clone each package
> 2. Check for the existence of the `eln` branch.
>   a. If the `eln` branch exists, build from the HEAD of that branch
> into the side-tag.
>   b. Otherwise, build from the HEAD of the `rawhide` branch into the
> side-tag.
>
> Approach 2 (Conservative-style):
> 1. Query Koji for the latest-tagged build of each package in Fedora ELN
> 2. Interrogate the build task of that build for the git hash
> 3. Build that git hash into the side-tag.
>
> Approach 2 is more heavyweight, relying on a lot of Koji queries
> back-and-forth, whereas Approach 1 will pick up changes that have
> appeared in Rawhide since the last build (which is more in line with
> how Fedora's mass-rebuilds work). I'm personally leaning towards
> Approach 2, but I'm open to good arguments either way.
>

Sorry for being late with this, but I thought I'd already sent this.

I'd like to go with Approach 2 (Conservative-style)
I've got a python script that grabs the githash for various builds.
Although the initial run takes a couple of hours, after that it's fairly
quick.
It would make it possible to build using the ELN build source githash.

In the long run, I believe it takes less time to get the githash rather
than pulling down the git repos.
It's also something the can be pre-staged, then just run the script right
before you run the mass rebuild, to get the latest.

Troy
___
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: KDE broken on CentOS Stream 9

[Troy Dawson]

Thank you to everyone who tested and gave karma.
This update has been pushed to regular epel9-next, and is available for all
CentOS Stream.

There is still one package that does not update and/or install.  That is
qt-creator.
That is being worked on for both epel9 and epel9-next.


On Fri, May 19, 2023 at 2:57 PM Troy Dawson  wrote:

> I have a new update set.  This is just the packages failing to install
> with the updated qt5.  The qt5 packages are updated to match the versions
> that are now in RHEL.  All other packages are still the same versions and
> patches as before, just with their release bumped and then rebuilt.
> These are now working on all of my tests.  And willit is showing that
> everything is installing correctly.  So I think this time I got it right.
>
> To test:
>   dnf --enablerepo=epel-next-testing clean all
>   dnf --enablerepo=epel-next-testing update
>
> To give karma:
>   https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-22498da84c
>
>
> On Wed, May 17, 2023 at 8:58 AM Troy Dawson  wrote:
>
>> KDE is still not able to be upgraded in CentOS Stream 9.
>> This is my fault.
>> I tried to combine the rebuilds needed for the new qt5, with updating the
>> rest of the KDE Plasma Desktop.  This didn't go well.
>> I will be removing the updates from epel-next-testing and starting again
>> with just the packages that need a rebuild due to the qt5 update.
>>
>> I'm sorry for the inconvenience, and appreciate the patience you have
>> shown.
>>
>> Troy
>>
>> On Fri, May 5, 2023 at 7:11 AM Troy Dawson  wrote:
>>
>>> There is a new qt5 update in CentOS Stream 9.  This update will be going
>>> out when RHEL 9.3 is released six months from now.  Again, that is RHEL
>>> 9.3, NOT 9.2.
>>>
>>> I am currently rebuilding KDE for CentOS Stream 9.  This will take some
>>> time to rebuild and make it through testing.  I am suspecting it will not
>>> be in stable until May 18.
>>>
>>> It is a known issue that is being resolved.  No need for further bugs.
>>> If you have already created a bug, please cc me (tdaw...@redhat.com) on
>>> it, because most of the bugs do not get assigned to me.
>>>
>>> Thank You
>>> 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

[EPEL-devel] Re: KDE broken on CentOS Stream 9

[Troy Dawson]

I have a new update set.  This is just the packages failing to install with
the updated qt5.  The qt5 packages are updated to match the versions that
are now in RHEL.  All other packages are still the same versions and
patches as before, just with their release bumped and then rebuilt.
These are now working on all of my tests.  And willit is showing that
everything is installing correctly.  So I think this time I got it right.

To test:
  dnf --enablerepo=epel-next-testing clean all
  dnf --enablerepo=epel-next-testing update

To give karma:
  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-22498da84c


On Wed, May 17, 2023 at 8:58 AM Troy Dawson  wrote:

> KDE is still not able to be upgraded in CentOS Stream 9.
> This is my fault.
> I tried to combine the rebuilds needed for the new qt5, with updating the
> rest of the KDE Plasma Desktop.  This didn't go well.
> I will be removing the updates from epel-next-testing and starting again
> with just the packages that need a rebuild due to the qt5 update.
>
> I'm sorry for the inconvenience, and appreciate the patience you have
> shown.
>
> Troy
>
> On Fri, May 5, 2023 at 7:11 AM Troy Dawson  wrote:
>
>> There is a new qt5 update in CentOS Stream 9.  This update will be going
>> out when RHEL 9.3 is released six months from now.  Again, that is RHEL
>> 9.3, NOT 9.2.
>>
>> I am currently rebuilding KDE for CentOS Stream 9.  This will take some
>> time to rebuild and make it through testing.  I am suspecting it will not
>> be in stable until May 18.
>>
>> It is a known issue that is being resolved.  No need for further bugs.
>> If you have already created a bug, please cc me (tdaw...@redhat.com) on
>> it, because most of the bugs do not get assigned to me.
>>
>> Thank You
>> 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

[EPEL-devel] Re: KDE broken on CentOS Stream 9

[Troy Dawson]

KDE is still not able to be upgraded in CentOS Stream 9.
This is my fault.
I tried to combine the rebuilds needed for the new qt5, with updating the
rest of the KDE Plasma Desktop.  This didn't go well.
I will be removing the updates from epel-next-testing and starting again
with just the packages that need a rebuild due to the qt5 update.

I'm sorry for the inconvenience, and appreciate the patience you have shown.

Troy

On Fri, May 5, 2023 at 7:11 AM Troy Dawson  wrote:

> There is a new qt5 update in CentOS Stream 9.  This update will be going
> out when RHEL 9.3 is released six months from now.  Again, that is RHEL
> 9.3, NOT 9.2.
>
> I am currently rebuilding KDE for CentOS Stream 9.  This will take some
> time to rebuild and make it through testing.  I am suspecting it will not
> be in stable until May 18.
>
> It is a known issue that is being resolved.  No need for further bugs.  If
> you have already created a bug, please cc me (tdaw...@redhat.com) on it,
> because most of the bugs do not get assigned to me.
>
> Thank You
> 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

[EPEL-devel] Re: kdenlive is ready for epel9

[Troy Dawson]

Hi Sérgio,
Thank you for the update and reminder.
I've put kdenlive on my KDE list of packages that I check and update.
It will automatically get updated in step with the other KDE packages in
epel.

That means that for epel9, it will be the F37 version of kdenlive - 22.12.3.
For epel9-next it will be the F38 version of kdenlive - 23.04.0 (or
possibly 23.04.1)

Then it will continue to get updates along with the other KDE packages in
epel9 / epel9-next

Troy

On Mon, May 15, 2023 at 5:02 AM Sérgio Basto  wrote:

> Hi Troy,
>
> Yesterday , after telling Neal that we already can build kdenlive on
> EPEL 9, since rttr package was pushed to stable repo.
>
> Neal wrote to you (in KDE channel) :
> "I was reminded by sergiomb that kdenlive should be upgraded along with
> other KDE apps when you're doing the Plasma upgrade for EPEL 9
>
> since kdenlive was added to Fedora and EPEL only a few months ago, it
> might not be in on your register to track that too, hence the reminder"
>
>
> With --enablerepo=epel-next-testing and --enablerepo=epel-testing
> kdenlive builds on epel-next-9 with rawhide sources without any
> modification.
>
> In resume what to you prefer or think ? you add kdenlive to kde track
> or we build it as an epel package ?
>
> Thank you.
>
> Best regards,
> --
> 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: python3.11-rpm to EPEL 9

[Troy Dawson]

On Mon, May 15, 2023 at 3:15 AM Miro Hrončok  wrote:

> Hello,
>
> I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
>
> See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
>
> I decided to reuse the python3-rpm component (currently epel7 only). Let
> me
> know if I should not.
>
> If there is a significant demand, I can try add this (and python39-rpm) to
> EPEL
> 8 as well.
>

That sounds great.  Thank you Miro.

I don't know of any reason you shouldn't reuse the epel7 component.

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Troy Dawson]

We discussed this in the weekly EPEL Steering Committee meeting. We broke
this into two separate votes.

*Allow the epel 7 update : Passed*
Votes: All who voted, voted in favor of this.
Notes: No notes.

*Allow the epel 8 and 9 update - with a stern warning : Passed*
Votes: 4 for, 2 against, 1 abstaining -
Notes: Although your argument was that these needed the same breaking
configurations to prevent future security issues, that wasn't what swayed
the votes. The first reason was that having older versions in epel 8 and 9
causes more problems. The second reason was that we felt we didn't give you
a stern enough warning last time.

*WARNING / ADVISEMENT / ATTENTION*
This is the second time that apptainer has had breaking updates. The EPEL
Steering Committee feels that if this happens again, then apptainer isn't a
good fit for EPEL. We will pull apptainer from EPEL and recommend that you
release it in COPR <https://copr.fedorainfracloud.org/> instead of EPEL.
Please inform the upstream maintainers of this.


Troy

On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  wrote:

> Hi Troy,
>
> If required, the epel8 & epel9 builds could have a patch added that
> changes the default of the new "allow setuid-mount extfs" to be "yes"
> instead of "no". That's all that would be required to disable the
> incompatible change.
>
> But as I said, I think it's a bad idea to make this behavior different
> on different OS versions.  Epel8 & 9 are still vulnerable to the same
> general issue; even though they're likely to get patches for future low
> or moderate level severity vulnerabilities, they don't get patches
> quickly and so admins will have to turn this off for the period of time
> between announcement and patch upstream.  Also the incompatibility is
> going to only affect a small percentage of epel8 & 9 users, and they
> should be able to quickly workaround it by adding the --userns option.
>
> The --userns option is already available everywhere.  Are you
> suggesting that it default to --userns option behavior on epel8 & 9, at
> least for ext3, when "allow setuid-mount extfs = no"?  I have thought
> of that but I believe that we cannot mix the setuid mode and the
> fuse2fs mount, at least not without a lot of major rework and careful
> investigation of the security implications.  I don't think it would be
> good to automatically switch fully to the --userns mode with a setuid
> installation and "allow setuid-mount extfs = no", because then users
> will get subtle differences with other behavior depending on whether or
> not they are requesting something that is using an ext3 filesystem.
>
> Dave
>
> On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote:
> > That makes it more clear for epel7.
> > But it will be strange for epel7 to have a higher version than epel8 and
> 9.
> > Would the apptainer maintainers be willing to create an update that has
> the
> > --userns option, as well as the original option?
> > 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 "Privilege

[EPEL-devel] Re: Bug 2188992 - Please branch and build sscep in epel8

[Troy Dawson]

I just noticed this went to the the wrong mailling list.
Not many people are going to see this on epel-devel-owners.

On Wed, May 10, 2023 at 7:02 AM Stephen Smoogen  wrote:

>
>
> On Wed, 10 May 2023 at 09:46, Troy Dawson  wrote:
>
>> For those EPEL maintainers deciding on whether to take this or not.
>> sscep looks like it is still maintained and active upstream.[1]
>> Although the request bug listed here looks new, there is a much older
>> duplicate bug requesting it. [2]
>> sscep has been orphaned and retired in Fedora, around F31.  The problem
>> with orphaning is that it doesn't tell you why it was orphaned.
>>
>
> Going from the emails I could find, it was the reason you outlined. At
> that time it was needing a version of openssl we were no longer going to
> support for security reasons.
>
>
>> But if we try to build the latest Fedora version on epel8, it's easy to
>> see that it requires compat-openssl10-devel.  In other words, at the time,
>> it wasn't compatible with the latest openssl.
>> That has been fixed upstream.
>> So whoever takes it will need to update the rpm to the latest upstream.
>>
>> I'm not trying to discourage anyone from taking this package.  It's
>> maintained upstream, so that's good.  I'm just letting ya'll know what will
>> be involved.
>>
>>
> Troy
>>
>> [1] - https://github.com/certnanny/sscep
>> [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1741770
>>
>>
>>
>> On Wed, May 10, 2023 at 5:00 AM Kiran Suresh 
>> wrote:
>>
>>> Dear EPEL Community,
>>>
>>>
>>>
>>> Hope this email finds you well. I am writing to request your assistance
>>> with SSCEP package for EL8, looking for a packagers who would like to
>>> package and maintain SSCEP package on epel..
>>>
>>>
>>>
>>> We would like to request your help in addressing this issue so that we
>>> can proceed to utilize the package. If there are any packagers who would be
>>> willing to take over the maintenance of SSCEP package, we would be grateful
>>> for your support.
>>>
>>>
>>>
>>> We have submitted a bug for this request, and have not received any
>>> response on this.
>>>
>>>
>>>
>>> Here are some additional details about package request:
>>>
>>>
>>>
>>> Bug ID: 2188992
>>> Link to Bug: 2188992 – Please branch and build sscep in epel8
>>> (redhat.com) <https://bugzilla.redhat.com/show_bug.cgi?id=2188992>
>>>
>>> Package name: sscep-0.6.1-5.20160525
>>>
>>> Purpose: Simple SCEP client
>>>
>>> Package for EL7: sscep-0.6.1-5.20160525git2052ee1.el7.src.rpm
>>>
>>>
>>>
>>> If someone from the community could pick up this bug and work on it, we
>>> would be more than happy to provide any additional information or
>>> assistance needed to resolve the issue. We believe that this package would
>>> be a valuable addition to the EPEL repository and would appreciate your
>>> help in making it available to others.
>>>
>>>
>>>
>>> Thank you for your time and consideration, and we look forward to
>>> hearing from you soon.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Thanks
>>>
>>> Kiran
>>>
>>> *Kiran Kumar Suresh*
>>>
>>> *TSS Infrastructure | *ksur...@vexcelco.com *| Mobile: (203) 822 3689*
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> 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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Troy Dawson]

That makes it more clear for epel7.
But it will be strange for epel7 to have a higher version than epel8 and 9.
Would the apptainer maintainers be willing to create an update that has the
--userns option, as well as the original option?
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.
> > > > >
> > > > > 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.
> > > >
> > > > As DT pointed out, perhaps Red Hat was thinking that low privileges
> could
> > > > have been used by automounts of a USB device, but since that requires
> > > > physical access and there are much easier ways to get privilege
> escalation
> > > > with physical access, the only additional capability that would give
> to
> > > > a user is a crash, a denial of service.
> > >
> > > Impact scoring for a CVE doesn't depend on how it is triggered,
> though. If CVE-2022-1184 can provably give privilege escalation then it
> should be scored high on the impact
> (confidentiality/integrity/availability) metrics. It is not relevant to the
> impact whether I need physical access. The ease of the exploit is covered
> by the exploitability metrics, not the impact metrics.
> > >
> > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
> > >
> > > My comment about automounts etc. was only related to why Red Hat might
> hve set the 'Privileges Required' property to low, even though `mount` is
> usually a root-only operation. Here you are arguing that CVE-2022-1184 was
> mis-scored on impact (confidentiality/integrity/availability). This is not
> related to my point about privileges required.
> > >
> > > > > There is no reason to believe that CVE-2022-1184
> > > > > should have been marked as higher impact than it was, and thus I
> see
> > > > 

[EPEL-devel] KDE on CentOS Stream 9

[Troy Dawson]

There is a new qt5 update in CentOS Stream 9.  This update will be going
out when RHEL 9.3 is released six months from now.  Again, that is RHEL
9.3, NOT 9.2.

I am currently rebuilding KDE for CentOS Stream 9.  This will take some
time to rebuild and make it through testing.  I am suspecting it will not
be in stable until May 18.

It is a known issue that is being resolved.  No need for further bugs.  If
you have already created a bug, please cc me (tdaw...@redhat.com) on it,
because most of the bugs do not get assigned to me.

Thank You
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

[EPEL-devel] Re: A CenOS Stream package missing during EPEL9 build: unresponsive CentOS Stream @redhat maintainers

[Troy Dawson]

On Thu, May 4, 2023 at 12:57 PM Marcin Dulak  wrote:

> Hi,
>
> I have a bugzilla opened about a CenOS Stream package missing during EPEL9
> builds
> https://bugzilla.redhat.com/show_bug.cgi?id=2182460, for over a month
> with no response.
>
> Can something be done about this, apart from trying to reach the
> maintainers on their corporate emails?
>

Please do not try to contact the maintainers on their corporate emails.

If you are in a rush, then consider creating an -epel package.  Details are
here.
https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/

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

[EPEL-devel] Fixed crb, testing on RHEL requested

[Troy Dawson]

A bug was found in /usr/bin/crb [1] dealing with how crb determines if you
are on a RHEL system or not.  A fix was made and tested on every RHEL
compatible distro I could find.  So I'm very confident about those.
But for real RHEL systems that use subscription-manager, I only have access
to a few different types of installs and containers.

Could some people who have access to some of the more exotic RHEL installs
(SAP etc...) check and see if the new /usr/bin/crb works correctly for them.

The new update is in
epel-release-9-5.el9 [2]
epel-release-8-19.el8 [3]

Thank You
Troy

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=2186721
[2] -
https://kojipkgs.fedoraproject.org//packages/epel-release/9/5.el9/noarch/epel-release-9-5.el9.noarch.rpm
[3] -
https://kojipkgs.fedoraproject.org//packages/epel-release/8/19.el8/noarch/epel-release-8-19.el8.noarch.rpm
___
epel-devel 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: Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons

[Troy Dawson]

On Mon, Apr 10, 2023 at 10:40 AM Ben Beasley 
wrote:

> When I took over maintenance of the flintqs package[1]—which contains
> William Hart’s quadratic sieve implementation, as modified for
> sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why
> not? Someone might find it useful.”
>
> It was recently pointed out[2][3] that the flintqs command-line tool
> uses temporary files in unsafe ways[4], which could potentially
> represent an exploitable security vulnerability; this has been assigned
> CVE-2023-29465[5].
>
> There is no immediate patch available; while one could surely be
> constructed, the sagemath project plans to incorporate the factorization
> algorithm directly in sagemath and discontinue support of the vulnerable
> command-line tool rather than fixing it[6].
>
> Since sagemath is not packaged in any of the EPEL releases, and flintqs
> is therefore a leaf package, I plan to handle this security report by
> retiring flintqs in all three EPELs. This email is the beginning of that
> process as prescribed in the EPEL Retirement Policy: Process: Security
> Reasons[7]. I doubt there will be any objections, but the process
> requires a one-week discussion period, so I will follow up on the
> epel-announce list and do the retirements no earlier than 2023-03-17.
>
> [1] https://src.fedoraproject.org/rpms/flintqs
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2185301
>
> [3] https://github.com/sagemath/FlintQS/issues/3
>
> [4]
> https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File
>
> [5] https://nvd.nist.gov/vuln/detail/CVE-2023-29465
>
> [6] https://github.com/sagemath/sage/pull/35419
>
> [7]
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons
>

Thank you for following the retirement policy.

I'm assuming that's a typo and you really meant
"no earlier than 2023-04-17"

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

[EPEL-devel] epel8 plasma being updated to 5.24.7

[Troy Dawson]

Due to several ongoing bugs, we are updating plasma in epel8 to the latest
5.24 version, 5.24.7.
The previous version in epel8 was 5.24.6

It is currently in epel8-testing.  You can update to it now with
  dnf --enablerepo=epel-testing update

If you would like to leave karma, the bodhi link is here
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-76af76fe5b

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

The change has now been implemented.
We'll have to wait for a package to be affected before we see it, but I
*think* it should look like what we have there.

Note: It is still doing everything as separate steps.  So package
maintainers will still get several emails.
I got to see the code, and I think we can trim a couple of the steps off,
which will trim a couple of the emails off.
But I wanted to get this change through first, because it's a
straightforward wording change and shouldn't break anything.

Troy


On Fri, Mar 31, 2023 at 8:00 AM Carl George  wrote:

> 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 ep

[EPEL-devel] Re: Creating an epelrelease dnf variable

[Troy Dawson]

On Fri, Mar 31, 2023 at 11:19 AM Miroslav Suchý  wrote:

> Dne 31. 03. 23 v 16:42 Troy Dawson napsal(a):
> > How to set it, I suggest triggers.  But that needs a bit more
> investigation and testing.
>
> May I suggest file trigger?
>
> https://rpm-software-management.github.io/rpm/manual/file_triggers.html
>
> Miroslav
>

I've learned something new today.
Yes, that is exactly what we need.

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

[EPEL-devel] Creating an epelrelease dnf variable

[Troy Dawson]

This is mainly for EPEL10 planning, but others might find it useful, so I'm
sending it to the email vs the epel10 discussion on discourse.

I was talking with Carl about creating a dnf variable for the epel 10
repos.  He had been talking about using $releasever and $releaseminor.  But
we also talked about creating our own epel variable.
This is about creating our own epel variable.  I'm calling it epelrelease
but that it up for debate.

There is an often overlooked file called /etc/os-release
It's full of lots of good stuff, including a variable called "VERSION_ID"
In every Red Hat compatible release (Fedora, Stream, RHEL, Alma, Rocky)
this should give us what we need/want.
Fedora 39
Stream 8 / 9
RHEL 8.7 / 9.1
Alma 8.7 / 9.1
Rocky 8.7 / 9.1

The format of /etc/os-release makes it very easy to use.  The following
would give us a dnf variable called epelrelease

source /etc/os-release ; echo $VERSION_ID >> /etc/dnf/vars/epelrelease

We could then use epelrelease in our dnf configs.

How to set it, I suggest triggers.  But that needs a bit more investigation
and testing.

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

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] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

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

[EPEL-devel] Re: Backported som rpm from fedora to epel

[Troy Dawson]

On Tue, Mar 21, 2023, 4:05 AM Quinn Comendant  wrote:

> On 9 Sep 2022, Troy Dawson wrote:
>
> webalizer - nobody has asked for it. And maybe someone needs to port
> webalizer to use libmaxminddb
>
> I came here specifically to ask for Webalizer and found this thread.
>
> What is the process for requesting a package to be added to EPEL 9? I
> noticed someone posted a bugzilla ticket
> <https://bugzilla.redhat.com/show_bug.cgi?id=1892290#> to request
> Webalizer for EPEL 8; should I do the same for EPEL 9?
>

Yes
https://docs.fedoraproject.org/en-US/epel/epel-package-request/

> --
> Quinn Comendant
> Strangecode, LLC
> www.strangecode.com
> ___
> epel-devel 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] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky  wrote:

> On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
> > On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel
> >  wrote:
> > > On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
> > > >
> > > >
> > > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi 
> > > > wrote:
> > > > > On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
> > > > > >
> > > > > > This is what I have on my ticket.  Respond soon (by tomorrow
> > > > > > end
> > > > > > of day) if
> > > > > > you think I need changes.
> > > > > >
> > > > > > Subject:
> > > > > > Notice:  will be automatically retired from
> > > > > > epel
> > > > > > when RHEL
> > > > > > . is released
> > > > > >
> > > > > > Comment:
> > > > > > Thank you for your work maintaining  in
> > > > > > epel.
> > > > > > This package
> > > > > > has been considered important enough to Red Hat's customers
> > > > > > that
> > > > > > Red Hat
> > > > > > has decided to promote it to be an official part of RHEL.  It
> > > > > > will be part
> > > > > > of RHEL ..  When that is released, EPEL
> > > > > > automation
> > > > > > will
> > > > > > remove  from epel.
> > > > >
> > > > > That looks pretty good, but I might suggest adding something
> > > > > more
> > > > > explicit at the end:
> > > > >
> > > > > Note that this issue is purely informational, you do not need
> > > > > to
> > > > > take any
> > > > > actions at this time.
> > > > >
> > > > > But perhaps thats overkill. ;)
> > > > >
> > > > > kevin
> > > > >
> > > >
> > > >
> > > > It's slight overkill, but you are correct, they might think they
> > > > have
> > > > to do something.
> > > > I have changed the last sentence to be
> > > >
> > > > When that is released, EPEL automation will remove  from
> > > > EPEL  and close this bug.
> > > >
> > > > Troy
> > >
> > > I'd consider something in a final paragraph that says "something
> > > like":
> > >
> > > No action is required from you at this time.
> > >
> > >
> > > Having an explicit "non-call to action" int its own paragraph may
> > > help
> > > folks feel more comfortable that they know what to expect and what
> > > they
> > > do/do not need to do.
> > >
> > > Pat
> > >
> >
> >
> > Although I do agree having something in a separate paragraph would be
> > best, my concern is that I don't  know how they are creating these
> > bugs.
> > Doing a single paragraph, everything can fit between a pair of
> > quotes, and you don't have to worry about special characters.  That
> > always works for any scripting or automation you are working with.
> > Doing a separate paragraph might be easy, it might be a pain in the
> > rear.
> >
> > Troy
>
>
> h, perhaps as sentence #1 then?
>
> Pat
>

Good idea.  I think if we put a modified version of Kevin's as the first
sentance, we get.


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 .  This
package has been considered important enough to Red Hat's customers that
Red Hat has decided to promote it to be an official part of RHEL.  It will
be part of RHEL ..  When that is released, EPEL automation
will remove  from EPEL  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

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

On Fri, Mar 17, 2023 at 3:17 AM Carl George  wrote:

> 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.
>

Ah, thanks.  I had forgotten about that.


> >>
> >> 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.
> >>
>

I still have the subscription problem for any true automation.
Maybe since Alma and Rocky are getting so quick at new releases, it won't
matter if we just keep checking them both and once one has the package we
do the remove.

Either way, this time (RHEL 9.2 / 8.8) will be manual.
I'm hoping it will be "manually run the scripts", but depending on how much
time I have, it still might be "manual manual"

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
> >
> >
> > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi  wrote:
> > > On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
> > > >
> > > > This is what I have on my ticket.  Respond soon (by tomorrow end
> > > > of day) if
> > > > you think I need changes.
> > > >
> > > > Subject:
> > > > Notice:  will be automatically retired from epel
> > > > when RHEL
> > > > . is released
> > > >
> > > > Comment:
> > > > Thank you for your work maintaining  in epel.
> > > > This package
> > > > has been considered important enough to Red Hat's customers that
> > > > Red Hat
> > > > has decided to promote it to be an official part of RHEL.  It
> > > > will be part
> > > > of RHEL ..  When that is released, EPEL automation
> > > > will
> > > > remove  from epel.
> > >
> > > That looks pretty good, but I might suggest adding something more
> > > explicit at the end:
> > >
> > > Note that this issue is purely informational, you do not need to
> > > take any
> > > actions at this time.
> > >
> > > But perhaps thats overkill. ;)
> > >
> > > kevin
> > >
> >
> >
> > It's slight overkill, but you are correct, they might think they have
> > to do something.
> > I have changed the last sentence to be
> >
> > When that is released, EPEL automation will remove  from
> > EPEL  and close this bug.
> >
> > Troy
>
> I'd consider something in a final paragraph that says "something like":
>
> No action is required from you at this time.
>
>
> Having an explicit "non-call to action" int its own paragraph may help
> folks feel more comfortable that they know what to expect and what they
> do/do not need to do.
>
> Pat
>

Although I do agree having something in a separate paragraph would be best,
my concern is that I don't  know how they are creating these bugs.
Doing a single paragraph, everything can fit between a pair of quotes, and
you don't have to worry about special characters.  That always works for
any scripting or automation you are working with.  Doing a separate
paragraph might be easy, it might be a pain in the rear.

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa  wrote:

> On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson  wrote:
> >
> > On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson  wrote:
> >>
> >>
> >>
> >> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster <
> gary.buhrmas...@gmail.com> wrote:
> >>>
> >>> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
> >>>  wrote:
> >>>
> >>> > It would be really nice if the wording of the bug could contain some
> >>> > kind of a "thank you" note to the EPEL maintainers of the package in
> >>> > question. Not everyone will understand this process as "great, I
> don't
> >>> > have to maintain package X anymore, Red Hat will be doing that for me
> >>> > from now on". Some folks may take it as "Oh no! Red Hat is taking
> away
> >>> > my toy! Why?!" Ideally, there should still be a way for EPEL
> >>> > maintainer(s) to continue contributing to the RHEL package.
> >>>
> >>> Perhaps add something like (wordsmithed by someone
> >>> competent in such things):
> >>>
> >>> "The package you have been maintaining in EPEL is now
> >>> considered important enough to a large enough part of our
> >>> customers that Red Hat has decided to promote it to being
> >>> an officially supported part of the product"
> >>
> >>
> >> I like that idea.  It's much more positive.  A nice "Thank you for
> doing this in EPEL" type of feel.
> >>
> >> Troy
> >
> >
> > This is what I have on my ticket.  Respond soon (by tomorrow end of day)
> if you think I need changes.
> >
> > Subject:
> > Notice:  will be automatically retired from epel when
> RHEL . is released
> >
> > Comment:
> > Thank you for your work maintaining  in epel.  This
> package has been considered important enough to Red Hat's customers that
> Red Hat has decided to promote it to be an official part of RHEL.  It will
> be part of RHEL ..  When that is released, EPEL automation
> will remove  from epel.
> >
>
> That is pretty well worded, though you can just use "EPEL "
> instead of "epel".
>
>
I was debating whether to use capital letters or not.  I agree with you, I
think it does look better, and I have capital RHEL.
With the bit I added for Kevin, here is what I currently have

Subject:
Notice:  will be automatically retired from EPEL  when RHEL
. is released

Comment:

Thank you for your work maintaining  in EPEL .  This
package has been considered important enough to Red Hat's customers that
Red Hat has decided to promote it to be an official part of RHEL.  It will
be part of RHEL ..  When that is released, EPEL automation
will remove  from EPEL  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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi  wrote:

> On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
> >
> > This is what I have on my ticket.  Respond soon (by tomorrow end of day)
> if
> > you think I need changes.
> >
> > Subject:
> > Notice:  will be automatically retired from epel when
> RHEL
> > . is released
> >
> > Comment:
> > Thank you for your work maintaining  in epel.  This
> package
> > has been considered important enough to Red Hat's customers that Red Hat
> > has decided to promote it to be an official part of RHEL.  It will be
> part
> > of RHEL ..  When that is released, EPEL automation will
> > remove  from epel.
>
> That looks pretty good, but I might suggest adding something more
> explicit at the end:
>
> Note that this issue is purely informational, you do not need to take any
> actions at this time.
>
> But perhaps thats overkill. ;)
>
> kevin
>

It's slight overkill, but you are correct, they might think they have to do
something.
I have changed the last sentence to be

When that is released, EPEL automation will remove  from EPEL
 and close this bug.

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson  wrote:

>
>
> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster 
> wrote:
>
>> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
>>  wrote:
>>
>> > It would be really nice if the wording of the bug could contain some
>> > kind of a "thank you" note to the EPEL maintainers of the package in
>> > question. Not everyone will understand this process as "great, I don't
>> > have to maintain package X anymore, Red Hat will be doing that for me
>> > from now on". Some folks may take it as "Oh no! Red Hat is taking away
>> > my toy! Why?!" Ideally, there should still be a way for EPEL
>> > maintainer(s) to continue contributing to the RHEL package.
>>
>> Perhaps add something like (wordsmithed by someone
>> competent in such things):
>>
>> "The package you have been maintaining in EPEL is now
>> considered important enough to a large enough part of our
>> customers that Red Hat has decided to promote it to being
>> an officially supported part of the product"
>>
>
> I like that idea.  It's much more positive.  A nice "Thank you for doing
> this in EPEL" type of feel.
>
> Troy
>

This is what I have on my ticket.  Respond soon (by tomorrow end of day) if
you think I need changes.

Subject:
Notice:  will be automatically retired from epel when RHEL
. is released

Comment:
Thank you for your work maintaining  in epel.  This package
has been considered important enough to Red Hat's customers that Red Hat
has decided to promote it to be an official part of RHEL.  It will be part
of RHEL ..  When that is released, EPEL automation will
remove  from epel.

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

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

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)
>

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.
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

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

On Tue, Mar 7, 2023 at 7:16 PM Carl George  wrote:

> 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é <
> berra...@redhat.com> 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 over

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

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.



> 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.
I don't see the need for a rush.
You seem like you are going for the letter of the principle instead of the
spirit of the principle.
We know that the majority of our users are not RHEL users, they are clone
users.
I see no reason to irritate the majority of our users just because we want
to "minimize delay".

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

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

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.

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

[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases

[Troy Dawson]

On Fri, Mar 3, 2023 at 3:42 AM Daniel P. Berrangé 
wrote:

> A few weeks back there was a little snafu (since resolved) with the
> capstone package in EPEL.
>
> This package is being introduced to RHEL 9.2, and thus has been added
> to CentOS 9 Stream repos. A bug was filed against capstone in EPEL
> to notify that capstone should be retired when RHEL 9.2 is released:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=2124181
>
> Unfortunately the package was accidentally retired immediately rather
> than waiting until 9.2 release. This is an easy mistake for a maintainer
> to make when they see a bug whose title is "Remove capstone from epel9",
> so I don't want anyone to blame the maintainer for this accident.
>
> Yes the comments make it clear that removal should wait until 9.2
> release date, but I can totally understand how actions will be guided
> by the initial bug subject if you're just skimming. It was pointed out
> that this risk has been identified before:
>
>
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/LUWUIN5BRPJZGVB5PIH625PFV6IBD6YO/
>
> and now we have a real world example of it going wrong exactly as
> was predicted.
>
>
> My bigger concern though is what happens when RHEL-9.2 is actually
> released for real. The bug remains open and targets (immediate)
> retirement of capstone from EPEL on / near 9.2 release date.
>
>
> This doesn't feel like it takes into account the real world usage of
> enterprise distributions. The kind of people/organizations who deploy
> RHEL are rarely going to rush into upgrading their deployment processes
> to use 9.2 immediately. They may have all sorts of review and testing
> processes to go through, integration of 3rd party apps and services,
> validating against hardware, before they consider starting deployment
> of RHEL 9.2.
>
> All this time they will continue deploying machines with 9.1, despite
> 9.2 being available, so won't get access to new 9.2 packages.
>
> If we immediately retire capstone when 9.2 is released, aren't we
> going to break any ability to keep deploying capstone from EPEL on
> existing/new 9.1 installs ?
>
> 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.
>
> Unless I'm mistaken in some way, it feels like we should *NOT* sync
> the removal of packages from EPEL with their release in RHEL 9.2. It
> needs to be synced with user deployment of 9.2, which might be somewhat
> later.
>
>
>
> 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 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.
>
>
> 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.
>
> With regards,
> Daniel
>

Hi Daniel,
 Thank you for your insight as an end user.  Sometimes repo and package
maintainers are always trying to get to the latest and greatest and rush
things.

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.

The first step is re-working the bug that get's opened.
It will still be against the package that is to be retired, and linked to
the tracker.
The subject and initial comments will tell the maintainer that they do not
need to do anything, that it will be taken care of for them.
An automation of some type (currently it is manual) will add another
comment assuring them that it will be done automatically and there is
nothing for them to do.
The automation will then assign the bug to the appropriate person/group.

But then comes the part that you talk about, and it's a good thing to have
a discussion about.
When do you actually remove the packages from the EPEL 

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa  wrote:

> On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson  wrote:
> >
> > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:
> >>
> >> Hi Troy,
> >>
> >> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
> >> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
> >> > epel-devel@lists.fedoraproject.org> wrote:
> >> >
> >> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
> >> > > > I think this whole process should be automated. File bugs that say
> >> > > > "Heads up:
> >> > > > your package will be automatically retired after the release of
> RHEL
> >> > > > X.X" and
> >> > > > provide some explanation.
> >> > >
> >> > > Agreed. This is a pretty mechanical process: all the maintainer
> would
> >> > > do is run "fedpkg retire" for the appropriate branches, and that
> looks
> >> > > reasonable to automate. If we're concerned about bugs in the
> automation
> >> > > retiring packages that shouldn't be impacted, we can have it file a
> >> > > ticket for signoff on the EPEL tracker (or have some other process
> to
> >> > > spot check, at least until we're confiden it'll do the right thing).
> >> > >
> >> >
> >> > Sorry for delaying this for so long. Things came up, but now I have
> some
> >> > time.
> >> >
> >> > I think step one in this automation workflow is to not assign the
> bugs to
> >> > the package at all.
> >> > Assign the bugs to EPEL / distribution, but keep them as blockers on
> the
> >> > EPEL2RHEL tracker[1].
> >> > This gets rid of the busy maintainer problem.  Where they just read
> the
> >> > subject and do what it says.
> >> > This also allows the automation to not have to deal with all the
> different
> >> > packages.
> >>
> >> I'm not sure filling against distribution is a good idea. I'd just file
> >> bugs against the affected component, set the bug assignee to yourself,
> >> and close it once you preform the automatic retirement. This way, you
> >> won't have to worry about CCing the proper maintainer on the
> >> distribution bug and the bugs will be more organized. The subject is a
> >> separate problem.
> >>
> >> > I think for the automation to happen, we also have to get the subject
> line
> >> > updated.
> >> > If we can get it to have what release is in it, parsing the subject
> line is
> >> > much easier than going through all the bugzilla comments trying to
> find
> >> > what release this is supposed to come out in.
> >> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
> >>
> >> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
> >> will be automatically retired in RHEL X.X" so it's clear that
> >> maintainers don't need to take manual action.
> >
> >
> > That is a good point.
> >
> > On a related note.
> > For the past month or so, as new packages get added to the tracker I've
> been manually adding a comment that the package shouldn't be retired until
> (date) which is when (release) will come out.  That has usually been May
> 2023 when RHEL 8.8 / 9.2 comes out.
> > Several of the maintainers have thanked me for the clarification.
> > I've been doing this mainly so I can get a feel for what the script
> should be doing.  But one thing came up that I don't have an answer to.
> >
> > I haven't said "We will automatically retire this for you" because I
> don't know who "we" is/are.
> > Is it the committee?  (could be, that seems the most likely)
> > Is it the epel-packagers-sig? (I don't think that's right.)
> > Is it a different "retirement group"?
> >
> > Thoughts?
>
> It should probably be done by automation, not a person.
>

That scares me more than anything.
There are so many things that can go wrong when checking if a package is in
the repo.
The script I was planning on writing would send a list of packages to be
removed somewhere and then someone would manually remove them.

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

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:

> Hi Troy,
>
> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
> > epel-devel@lists.fedoraproject.org> wrote:
> >
> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
> > > > I think this whole process should be automated. File bugs that say
> > > > "Heads up:
> > > > your package will be automatically retired after the release of RHEL
> > > > X.X" and
> > > > provide some explanation.
> > >
> > > Agreed. This is a pretty mechanical process: all the maintainer would
> > > do is run "fedpkg retire" for the appropriate branches, and that looks
> > > reasonable to automate. If we're concerned about bugs in the automation
> > > retiring packages that shouldn't be impacted, we can have it file a
> > > ticket for signoff on the EPEL tracker (or have some other process to
> > > spot check, at least until we're confiden it'll do the right thing).
> > >
> >
> > Sorry for delaying this for so long. Things came up, but now I have some
> > time.
> >
> > I think step one in this automation workflow is to not assign the bugs to
> > the package at all.
> > Assign the bugs to EPEL / distribution, but keep them as blockers on the
> > EPEL2RHEL tracker[1].
> > This gets rid of the busy maintainer problem.  Where they just read the
> > subject and do what it says.
> > This also allows the automation to not have to deal with all the
> different
> > packages.
>
> I'm not sure filling against distribution is a good idea. I'd just file
> bugs against the affected component, set the bug assignee to yourself,
> and close it once you preform the automatic retirement. This way, you
> won't have to worry about CCing the proper maintainer on the
> distribution bug and the bugs will be more organized. The subject is a
> separate problem.
>
> > I think for the automation to happen, we also have to get the subject
> line
> > updated.
> > If we can get it to have what release is in it, parsing the subject line
> is
> > much easier than going through all the bugzilla comments trying to find
> > what release this is supposed to come out in.
> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
>
> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
> will be automatically retired in RHEL X.X" so it's clear that
> maintainers don't need to take manual action.
>

That is a good point.

On a related note.
For the past month or so, as new packages get added to the tracker I've
been manually adding a comment that the package shouldn't be retired until
(date) which is when (release) will come out.  That has usually been May
2023 when RHEL 8.8 / 9.2 comes out.
Several of the maintainers have thanked me for the clarification.
I've been doing this mainly so I can get a feel for what the script should
be doing.  But one thing came up that I don't have an answer to.

I haven't said "We will automatically retire this for you" because I don't
know who "we" is/are.
Is it the committee?  (could be, that seems the most likely)
Is it the epel-packagers-sig? (I don't think that's right.)
Is it a different "retirement group"?

Thoughts?
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster 
wrote:

> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
>  wrote:
>
> > It would be really nice if the wording of the bug could contain some
> > kind of a "thank you" note to the EPEL maintainers of the package in
> > question. Not everyone will understand this process as "great, I don't
> > have to maintain package X anymore, Red Hat will be doing that for me
> > from now on". Some folks may take it as "Oh no! Red Hat is taking away
> > my toy! Why?!" Ideally, there should still be a way for EPEL
> > maintainer(s) to continue contributing to the RHEL package.
>
> Perhaps add something like (wordsmithed by someone
> competent in such things):
>
> "The package you have been maintaining in EPEL is now
> considered important enough to a large enough part of our
> customers that Red Hat has decided to promote it to being
> an officially supported part of the product"
>

I like that idea.  It's much more positive.  A nice "Thank you for doing
this in EPEL" type of feel.

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

[EPEL-devel] EPEL 8 Modules officially retired

[Troy Dawson]

EPEL 8 Modules are now officially retired.

- The EPEL 8 modules are being archived.
- The mirror manager is being pointed to the archive
- Tags, targets and configurations are being removed so new builds cannot
happen.
- The dnf epel-modular.repo will remain, but will still default to disabled
- The dnf epel-modular.repo name will change DEPRECATED to RETIRED

Some of these steps take longer than others.
If you do not see the change right now, know that it is coming.

Questions and Answers:

Question: Will I still be able to access the modules?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes.  They will be in the Fedora archives,
and the mirror managers will point at them.
___
epel-devel 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: Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)

[Troy Dawson]

On Wed, Feb 8, 2023 at 1:19 PM Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

> On Wed, 2023-02-08 at 14:09 -0500, Neal Gompa wrote:
> > On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson 
> > wrote:
> > >
> > > On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim
> > >  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Per the incompatible upgrade policy[1] I'm proposing upgrading
> > > > libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
> > > >
> > > > Bugzilla issues:
> > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1
> > > > in
> > > > general)
> > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
> > > >
> > > > Up to 0.4.1, libkdumpfile was packaged without the test suite
> > > > being
> > > > run, and when I started work on packaging it in Debian I noticed
> > > > a lot
> > > > of test failures on non-x86_64 architectures:
> > > > https://github.com/ptesarik/libkdumpfile/issues/40
> > > >
> > > > This is now fixed (0.5.0 is the first version to pass tests
> > > > cleanly
> > > > without additional patches on Fedora), but prior to its release
> > > > we were
> > > > basically building in Fedora from a post-0.4.1 snapshot
> > > > (
> > > > https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af83
> > > > 26562a155581d77f04f2ae84197/f/libkdumpfile.spec)
> > > > that is likely not ABI compatible with the original 0.4.1 anyway,
> > > > so
> > > > there's no reasonable way to backport the architecture fixes to
> > > > 0.4.1.
> > > >
> > > > Change in sonames:
> > > >
> > > > [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora
> > > > rawhide --
> > > > provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-
> > > > stream
> > > > 9 --provides libkdumpfile 2>/dev/null)
> > > > libaddrxlat.so.2()(64bit)
> > > > libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
> > > > libaddrxlat.so.3
> > > > libaddrxlat.so.3()(64bit)
> > > > libaddrxlat.so.3(LIBADDRXLAT_0)
> > > > libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
> > > > libkdumpfile = 0.4.1-5.el9
> > > > libkdumpfile = 0.5.0-3.fc38
> > > > libkdumpfile(x86-32) = 0.5.0-3.fc38
> > > > libkdumpfile(x86-64) = 0.4.1-5.el9
> > > > libkdumpfile(x86-64) = 0.5.0-3.fc38
> > > > libkdumpfile.so.10
> > > > libkdumpfile.so.10()(64bit)
> > > > libkdumpfile.so.10(LIBKDUMPFILE_0)
> > > > libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
> > > > libkdumpfile.so.9()(64bit)
> > > > libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
> > > >
> > > > Only drgn currently depends on libkdumpfile, and I plan to
> > > > rebuild it
> > > > in the same updates:
> > > >
> > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> > > > whatrequires "libaddrxlat.so.2()(64bit)"
> > > > Last metadata expiration check: 0:12:30 ago on Wed Feb  8
> > > > 11:02:35
> > > > 2023.
> > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
> > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
> > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> > > > whatrequires "libkdumpfile.so.9()(64bit)"
> > > > Last metadata expiration check: 0:12:40 ago on Wed Feb  8
> > > > 11:02:35
> > > > 2023.
> > > > drgn-0:0.0.22-1.el9.x86_64
> > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64
> > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64
> > > >
> > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-
> > > > legacy 8 --
> > > > whatrequires "libaddrxlat.so.2()(64bit)"
> > > > Last metadata expiration check: 0:00:08 ago on Wed Feb  8
> > > > 11:15:35
> > > > 2023.
> > > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64
> > > > libkdumpfile-util-0:0.4.1-5.el8.x86_64
> > > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64
> > > > [michel@f37-packaging ~]$ rpmdistro-repoquer

[EPEL-devel] Re: Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)

[Troy Dawson]

On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

> Hi all,
>
> Per the incompatible upgrade policy[1] I'm proposing upgrading
> libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
>
> Bugzilla issues:
> - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in
> general)
> - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
>
> Up to 0.4.1, libkdumpfile was packaged without the test suite being
> run, and when I started work on packaging it in Debian I noticed a lot
> of test failures on non-x86_64 architectures:
> https://github.com/ptesarik/libkdumpfile/issues/40
>
> This is now fixed (0.5.0 is the first version to pass tests cleanly
> without additional patches on Fedora), but prior to its release we were
> basically building in Fedora from a post-0.4.1 snapshot
> (
> https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a155581d77f04f2ae84197/f/libkdumpfile.spec
> )
> that is likely not ABI compatible with the original 0.4.1 anyway, so
> there's no reasonable way to backport the architecture fixes to 0.4.1.
>
> Change in sonames:
>
> [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide --
> provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream
> 9 --provides libkdumpfile 2>/dev/null)
> libaddrxlat.so.2()(64bit)
> libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
> libaddrxlat.so.3
> libaddrxlat.so.3()(64bit)
> libaddrxlat.so.3(LIBADDRXLAT_0)
> libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
> libkdumpfile = 0.4.1-5.el9
> libkdumpfile = 0.5.0-3.fc38
> libkdumpfile(x86-32) = 0.5.0-3.fc38
> libkdumpfile(x86-64) = 0.4.1-5.el9
> libkdumpfile(x86-64) = 0.5.0-3.fc38
> libkdumpfile.so.10
> libkdumpfile.so.10()(64bit)
> libkdumpfile.so.10(LIBKDUMPFILE_0)
> libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
> libkdumpfile.so.9()(64bit)
> libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
>
> Only drgn currently depends on libkdumpfile, and I plan to rebuild it
> in the same updates:
>
> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> whatrequires "libaddrxlat.so.2()(64bit)"
> Last metadata expiration check: 0:12:30 ago on Wed Feb  8 11:02:35
> 2023.
> libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> libkdumpfile-util-0:0.4.1-5.el9.x86_64
> python3-libkdumpfile-0:0.4.1-5.el9.x86_64
> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
> whatrequires "libkdumpfile.so.9()(64bit)"
> Last metadata expiration check: 0:12:40 ago on Wed Feb  8 11:02:35
> 2023.
> drgn-0:0.0.22-1.el9.x86_64
> libkdumpfile-devel-0:0.4.1-5.el9.x86_64
> libkdumpfile-util-0:0.4.1-5.el9.x86_64
> python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>
> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
> whatrequires "libaddrxlat.so.2()(64bit)"
> Last metadata expiration check: 0:00:08 ago on Wed Feb  8 11:15:35
> 2023.
> libkdumpfile-devel-0:0.4.1-5.el8.x86_64
> libkdumpfile-util-0:0.4.1-5.el8.x86_64
> python3-libkdumpfile-0:0.4.1-5.el8.x86_64
> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
> whatrequires "libkdumpfile.so.9()(64bit)"
> Last metadata expiration check: 0:00:16 ago on Wed Feb  8 11:15:35
> 2023.
> drgn-0:0.0.22-1.el8.x86_64
> libkdumpfile-devel-0:0.4.1-5.el8.x86_64
> libkdumpfile-util-0:0.4.1-5.el8.x86_64
> python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> Thanks,
>

If I am reading this correctly, the only package affected would be drgn
(from python-drgn).
It should hopefully just need a rebuild.
Is that correct?
Were you planning on rebuilding python-drgn, or contacting the package
maintainer and having them do it?

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

[EPEL-devel] Re: python3-qt5-webkit for EPEL 8

[Troy Dawson]

It looks good to me.
Thanks for doing that.


On Sun, Jan 29, 2023 at 9:26 AM Orion Poplawski  wrote:

> The python-qt5 package in RHEL 8 does not ship the webkit package.  I'm
> assuming that this is unlikely to be changed since qt5-qtwebkit isn't in
> RHEL but is in EPEL.
>
> I think I'm close to producing a python-qt5-epel package here [1] that
> produces python3-qt5-webkit and would love to hear from people more
> familiar with the package if this seems like it's reasonable/workable.
>
> I think we're depending on the fact that the RHEL python3-qt5-devel
> package does ship the WebKit sip files and that these would match up
> with what this package ships.
>
> It also just seems like webengine isn't in there, or I'm missing what's
> needed to build it.  I also don't need it for my purposes.
>
> [1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
>
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> epel-devel 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] Re: [Fedocal] Reminder meeting : EPEL Steering Committee

[Troy Dawson]

I am officially canceling this weeks meeting.

Reasons:
We have postponed the epel10 discussion until next week.
I, and several other members will not be able to be there.

Talk to you next week, February 8

Troy

On Tue, Jan 31, 2023 at 8:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2023-02-01 from 16:00:00 to 17:00:00
> US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
> This is the weekly EPEL Steering Committee Meeting.
>
> A general agenda is the following:
>
> #topic aloha
>
> #topic EPEL Issues https://pagure.io/epel/issues
> * https://pagure.io/epel/issues?tags=meeting=Open
>
> #topic Old Business (if needed)
>
> #topic General Issues / Open Floor
>
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/9854/
>
> ___
> epel-devel 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] Re: gcc ee this bug on RHEL9 , How we reach RHEL team ?

[Troy Dawson]

Just so people don't need to go to the bug.
This has already been reported for RHEL 9.
https://bugzilla.redhat.com/show_bug.cgi?id=2140266

If I understand "Approved Release" correctly, the fix will come out in RHEL
9.2

On Tue, Jan 24, 2023 at 3:57 AM Sérgio Basto  wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1996330#c14
> --
> 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, 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] New EPEL KDE Proposal

[Troy Dawson]

I plan on making two changes to the current EPEL KDE Update Schedule.[1]

** First:  EPEL 8 KDE Plasma Desktop is going to stay at the releases that
they currently are at.  We will backport major security fixes.  Bugs and
bugfixes will be best effort.  But we will not do any across the board
updates.
This is due to the older libraries in RHEL 8.  We've hit the limit that the
newer KDE versions can run on the older libraries.
EPEL 8 will have these versions (with a few exceptions)
plasma - 5.24
kf5 - 5.96
kde apps - 22.04 / 21.12 / 21.08 and some 21.04
qt5 - 5.15

**Second: We will do the across the board updates to the main epel branches
[2] every six months instead of once a year.  They will coincide with each
RHEL minor release, instead of every other RHEL minor release.
With the last release, we found that KDE packages like to build on
themselves.  Meaning that some 22.04 packages needed a previous version of
at least 21.08 to build.  That was fine on epel-next where we had updated
each six months.  But when we tried to build on plain epel8 or epel9,
things got complicated.
Doing a release every six months will allow users to get the newer updates
faster.  And although it sounds counter-intuitive, it will save the
maintainers time.

We haven't officially made this change yet.  So if anyone sees any issues
and/or problems.  Please let us know.

Thank You
Troy Dawson
Fedora KDE SIG

[1] - https://fedoraproject.org/wiki/SIGs/KDE/EPEL#Update_Schedule
[2] - Currently epel9, but epel10 when it comes out
___
epel-devel 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: 'perl-Net-Domain-TLD' pkg maintainer needed for EPEL9 build

[Troy Dawson]

I'll probably take it.
I generally avoid perl due to dependencies, but this looks fairly
straightforward.
What is this ultimately for?

On Mon, Dec 19, 2022 at 7:16 AM Vladimir Pachnik <
vladimir.pach...@gooddata.com> wrote:

> Any takers?
>
>
> > On 13. 12. 2022, at 15:23, Troy Dawson  wrote:
> >
> > On Mon, Dec 12, 2022 at 7:35 AM Vladimir Pachnik <
> vladimir.pach...@gooddata.com> wrote:
> > > would anyone be able to take over the build of 'perl-Net-Domain-TLD'
> package for  EPEL9 as per
> https://bugzilla.redhat.com/show_bug.cgi?id=2144550 ?
> >
> > For those who are wondering, The fedora package builds and installs
> without any modifications.
> > No extra dependencies to take care of.
> >
> >
>
> Best regards
> Vladimir
> ___
> epel-devel 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] Re: claws-mail for EPEL-9

[Troy Dawson]

Packages do not automatically get transferred over from epel7 to a newer
epel.  People have to request them.
Nobody has requested it for epel9.
https://docs.fedoraproject.org/en-US/epel/epel-package-request/


On Tue, Dec 13, 2022 at 9:15 AM Dan Horák  wrote:

> Hi,
>
> isn't anybody already working on getting claws-mail to EPEL-9? My
> initial assessment shows that it shouldn't be difficult
> - add libetpan and ytnef, they are the missing BRs, both build OK from
> fedora spec, neither is in RHEL
> - add claws-mail, with some little tweaks it can use its fedora spec
>
>
> Dan
> ___
> epel-devel 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] Re: 'perl-Net-Domain-TLD' pkg maintainer needed for EPEL9 build

[Troy Dawson]

On Mon, Dec 12, 2022 at 7:35 AM Vladimir Pachnik <
vladimir.pach...@gooddata.com> wrote:
> would anyone be able to take over the build of 'perl-Net-Domain-TLD'
package for  EPEL9 as per
https://bugzilla.redhat.com/show_bug.cgi?id=2144550 ?

For those who are wondering, The fedora package builds and installs without
any modifications.
No extra dependencies to take care of.
___
epel-devel 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: ELN Extras responsibility

[Troy Dawson]

I'm sorry, I clicked, "Send" too quickly.
If the document doesn't have that Note in it yet, please wait an hour an
check again.

On Tue, Dec 6, 2022 at 9:57 AM Troy Dawson  wrote:

> The ELN Extras page[1] was updated with one note.  I thought I'd share
> that note with the epel-devel mailing list.
>
> NOTE: **You** are responsible when your package fails to build on ELN
> Extras.  Remember to check your packages on the ELN Status Page.[2]
> ELN Extras packages get rebuilt much more frequently than in EPEL.
>
> I guess that's a little out of context.
> "You" means the person putting a package into ELN Extras.
>
> We just wanted to emphasize that when you put a package ELN Extras
> you are committing to make sure that package builds in ELN for the
> next three years, or whenever you remove it.
> ELN Extra packages get rebuilt a minimum of once every six month, usually
> more often.  It's whenever that package get's rebuilt in rawhide.
> Don't expect magic to happen.
> Check in on your packages frequently and make sure they are healthy.
>
> Troy
>
> [1] - https://docs.fedoraproject.org/en-US/eln/extras/
> [2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
>
___
epel-devel 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] ELN Extras responsibility

[Troy Dawson]

The ELN Extras page[1] was updated with one note.  I thought I'd share that
note with the epel-devel mailing list.

NOTE: **You** are responsible when your package fails to build on ELN
Extras.  Remember to check your packages on the ELN Status Page.[2]
ELN Extras packages get rebuilt much more frequently than in EPEL.

I guess that's a little out of context.
"You" means the person putting a package into ELN Extras.

We just wanted to emphasize that when you put a package ELN Extras
you are committing to make sure that package builds in ELN for the
next three years, or whenever you remove it.
ELN Extra packages get rebuilt a minimum of once every six month, usually
more often.  It's whenever that package get's rebuilt in rawhide.
Don't expect magic to happen.
Check in on your packages frequently and make sure they are healthy.

Troy

[1] - https://docs.fedoraproject.org/en-US/eln/extras/
[2] - http://distrobuildsync-eln-ops.apps.stream.rdu2.redhat.com/status
___
epel-devel 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 7 retirement of findbugs-bcel

[Troy Dawson]

Yes, and if you can, tag it with "meeting"
If it doesn't let you tag it with meeting, let me know and I'll do it.

On Fri, Dec 2, 2022 at 11:49 AM Richard Fearn 
wrote:

> It looks like the next step is to get this on the agenda for the EPEL
> Steering Committee meeting.
>
> Should I create a ticket here? https://pagure.io/epel/issues
>
> Regards,
>
> Richard
>
> --
> Richard Fearn
> richardfe...@gmail.com
> ___
> epel-devel 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] epel-next repo cleanup (both 8 and 9)

[Troy Dawson]

I have cleaned up the epel-next (both 8 and 9) repo's.

If a package was newer in regular epel than in epel-next, the epel-next
package was untagged from epel{8,9}-next.

If a package was the same version-release in both epel and epel-next, I
made sure the epel version was installable on CentOS Stream {8,9}, I also
checked that the epel-next branches were the same as the epel branch, I
also checked to see your building style.  If everything pointed to "remove
it from epel-next", I untagged the epel-next package from epel{8,9}-next.

If the epel-next package was newer than what's in epel, I left them alone.

The vast majority of the cleanup happened yesterday, so you should be able
to see a smaller epel-next repo now.

If I untagged a package that you feel should be in epel-next, let me know
in the next week or two and I can tag them back.
If I missed your package and you want me to untag it, also let me know.

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

[EPEL-devel] Updated KDE for RHEL 8 available in epel-testing

[Troy Dawson]

RHEL 8.7 was released earlier this week.  Among other things, it has an
updated qt5 that needed many KDE packages to be rebuilt.  In addition, it
is time for the yearly major update of KDE Plasma Desktop for epel8.

If you would like to test the KDE update, or if you are having troubles
updating to RHEL 8.7 due to qt5 dependency issues, simply enable the
epel-testing repo to get the update.

  dnf --enablerepo=epel-testing update

This will get you:
qt5 5.15.3
plasma 5.24.6
kf5 5.96
apps 22.04 / 21.12 (Mostly)

Note1: There are seven packages still giving me trouble.  They are not
critical and should be in epel-testing by Monday.
Note2: This is the last major update of KDE Plasma Desktop for epel8.
There are many older libraries in RHEL 8 that are preventing us from
updating it to the next version of plasma.  This is not Red Hat's fault,
but simply the nature of an Enterprise release.
We will continue to provide security and critical bug fixes, but no major
updates.

Troy Dawson
___
epel-devel 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: qt5-qtbase dep problem?

[Troy Dawson]

On Thu, Nov 10, 2022 at 12:24 PM Neal Gompa  wrote:

> On Thu, Nov 10, 2022 at 3:11 PM  wrote:
> >
> > Hi,
> >
> > I have 2 systems running el8. When I run yum update qt5-qtbase I get the
> > following error on both systems:
> >
> > (tom-lp-21 pts7) # yum update qt5-qtbase
> > Updating Subscription Management repositories.
> > Last metadata expiration check: 0:01:52 ago on Thu 10 Nov 2022 03:02:34
> PM EST.
> > Error:
> >   Problem: problem with installed package kf5-kxmlgui-5.88.0-1.el8.x86_64
> >- package kf5-kxmlgui-5.88.0-1.el8.x86_64 requires
> libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers
> can be installed
> >- package kf5-kxmlgui-5.88.0-1.el8.x86_64 requires qt5-qtbase(x86-64)
> = 5.15.2, but none of the providers can be installed
> >- cannot install both qt5-qtbase-5.15.3-1.el8.x86_64 and
> qt5-qtbase-5.15.2-4.el8.x86_64
> >- cannot install both qt5-qtbase-5.15.3-1.el8.x86_64 and
> qt5-qtbase-5.15.2-3.el8.x86_64
> >- cannot install the best update candidate for package
> qt5-qtbase-5.15.2-4.el8.x86_64
> > (try to add '--allowerasing' to command line to replace conflicting
> packages or '--skip-broken' to skip uninstallable packages or '--nobest' to
> use not only best candidate packages)
> > (tom-lp-21 pts7) #
> >
> > Does anyone know how to resolve this?
> >
>
> The KDE stack needs to be rebuilt against the new Qt 5.15.3 shipped
> with RHEL 8.7. I'm pretty sure Troy is on the case for that. But if
> you need to work around it, you can install epel-next-release and use
> its repos to upgrade properly for now.
>

Please don't use the epel-next release repo.
Will it work? yes.  Will it confuse things?  yes
Please do the following for a week.

  dnf --exclude=qt5* update

RHEL 8.7 came out this week.  It has an updated qt5-qtbase.
As Neal said, this means that KDE had to be rebuilt.
I am also taking this opportunity to update KDE, not to the latest, but to
the latest that RHEL 8 libraries will allow me to.

I expect the update to be in epel-testing tomorrow.
I currently have about 350 packages rebuilt, 10 to go.

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

[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives

[Troy Dawson]

On Tue, Nov 8, 2022 at 5:06 AM Miro Hrončok  wrote:

> Hello EPEL folks,
>
> In EL 8, it is possible to change the "meaning" of /usr/bin/python3
> because it
> is managed by alternatives:
>
>$ ls -l /usr/bin/python3
>lrwxrwxrwx. ... /usr/bin/python3 -> /etc/alternatives/python3
>
> And since %__python3 on EPEL 8 is set to /usr/bin/python3 by
> epel-rpm-macros:
>
>$ rpm --eval '%__python3'
>/usr/bin/python3
>
> When packages have %py3_shebang_fix on EPEL 8:
>
>%py3_shebang_fix %{buildroot}%{_bindir}/*
>
> The shebengs have #!/usr/bin/python3 in them.
>
> (This is done by %__brp_mangle_shebangs automatically, so even packages
> without
> %py3_shebang_fix might be affected.)
>
> But when the package has importable modules in %{python3_sitelib} or
> %{python3_sitearch} or simply depends on other Python 3.6 modules, and the
> user
> uses alternatives to change /usr/bin/python3 to e.g. python3.9, the script
> no
> longer works.
>
> I suppose the default value of %__python3 needs to be /usr/bin/python3.6
> to
> prevent this way of shooting the users to their legs.
>
> (I apologize for letting the alternatives happen, but that ship has sailed
> a
> long time ago. Fortunately, EL 9 no longer have this.)
>
> --
> Miro Hrončok
> --
>


Hi Miro,
You have explained the problem very well, and a possible solution.
But I'm a bit confused as to what you want to happen.

Is this a heads up, that you are going to change something?
Do you want us to discuss what is the best thing to do?
Are you letting us know about the problem, and want someone else to
implement a solution?

Troy Dawson
___
epel-devel 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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 10:05 AM Sergey Mende  wrote:

> > On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  wrote:
> > What package(s) are you having problems with?
> Troy,
>
> the package in question is libClipper2 [0] that undergoes the review
> presently. It is not go-related. It requires the Google Test that is
> unavailable in ELN. It is not really a goal to make it included into ELN:
> initially the ELN builds were enabled in COPR and then started to fail
> after unbundling Google Test. So, the question arose if there is a need or
> a way to mark a package as presently incompatible with a distribution apart
> from putting a plain comment into the spec.
>
> Thank you,
> Sergey
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=2130903
>

Lets take a step back.
Packages are only built for ELN if
1 - They are specifically requested by the RHEL teams to be in the next
RHEL release
or
2 - They are a direct runtime or build dependency of anything in (1)

If you are not expecting a new package to be in ELN, then it most likely
won't be.
Having a package build on ELN should not be part of a Fedora package review.
If it has become part of it, then we need to review the process.

I'm not sure why copr was building for ELN.
I know copr *can* build for ELN, but it shouldn't be automatic.

In short, don't worry about the failed copr ELN builds.
Just make sure your package builds and is packaged correctly for Fedora
Rawhide.

Troy
___
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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson  wrote:

> On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher 
> wrote:
>
>>
>>
>> On Wed, Nov 2, 2022 at 12:26 AM Benson Muite 
>> wrote:
>>
>>> If there is a build failure for a package on ELN, does anything need to
>>> be added to a package spec file?  Currently
>>
>>
>> It varies wildly from package to package. Sometimes things can be handled
>> with a spec file conditional, other times it may be more complicated (like
>> the compiler flags for RHEL are revealing a coding bug that the Fedora
>> flags happen to miss or optimize out).
>>
>>
>>
>> reviewing a package where
>>> there is a missing dependency, but helpful to also
>>
>>
>> A new package review shouldn’t be expected to build on ELN, and failing
>> to do so shouldn’t block the review, in general. (Exception: a new package
>> that is Obsoleting a package currently in ELN might need special handling).
>>
>> know if anything
>>> should be done in general. The documentation at [0] is not clear on
>>> this.  Unclear also if ExcludeArch: ELN with a comment for the reason
>>> for build failures on ELN would be a useful thing to have in new spec
>>> files.
>>
>>
>> ELN is not an arch, so that would have no effect whatsoever. ELN already
>> only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
>> See https://tiny.distro.builders for the list.
>>
>
> Stephen is correct, ELN is not an arch, but there are some packages that
> do not build on all arches of ELN but do in rawhide.
> The biggest one is golang.
>
>
I should have put this in the email.
If your package needs any golang package to build you should put in

ExclusiveArch:  %{golang_arches}


What package(s) are you having problems with?
>
> Troy
>
>
___
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: ELN build failures

[Troy Dawson]

On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher 
wrote:

>
>
> On Wed, Nov 2, 2022 at 12:26 AM Benson Muite 
> wrote:
>
>> If there is a build failure for a package on ELN, does anything need to
>> be added to a package spec file?  Currently
>
>
> It varies wildly from package to package. Sometimes things can be handled
> with a spec file conditional, other times it may be more complicated (like
> the compiler flags for RHEL are revealing a coding bug that the Fedora
> flags happen to miss or optimize out).
>
>
>
> reviewing a package where
>> there is a missing dependency, but helpful to also
>
>
> A new package review shouldn’t be expected to build on ELN, and failing to
> do so shouldn’t block the review, in general. (Exception: a new package
> that is Obsoleting a package currently in ELN might need special handling).
>
> know if anything
>> should be done in general. The documentation at [0] is not clear on
>> this.  Unclear also if ExcludeArch: ELN with a comment for the reason
>> for build failures on ELN would be a useful thing to have in new spec
>> files.
>
>
> ELN is not an arch, so that would have no effect whatsoever. ELN already
> only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
> See https://tiny.distro.builders for the list.
>

Stephen is correct, ELN is not an arch, but there are some packages that do
not build on all arches of ELN but do in rawhide.
The biggest one is golang.

What package(s) are you having problems with?

Troy
___
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?

[Troy Dawson]

On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
> > I think this whole process should be automated. File bugs that say
> > "Heads up:
> > your package will be automatically retired after the release of RHEL
> > X.X" and
> > provide some explanation.
>
> Agreed. This is a pretty mechanical process: all the maintainer would
> do is run "fedpkg retire" for the appropriate branches, and that looks
> reasonable to automate. If we're concerned about bugs in the automation
> retiring packages that shouldn't be impacted, we can have it file a
> ticket for signoff on the EPEL tracker (or have some other process to
> spot check, at least until we're confiden it'll do the right thing).
>

Sorry for delaying this for so long. Things came up, but now I have some
time.

I think step one in this automation workflow is to not assign the bugs to
the package at all.
Assign the bugs to EPEL / distribution, but keep them as blockers on the
EPEL2RHEL tracker[1].
This gets rid of the busy maintainer problem.  Where they just read the
subject and do what it says.
This also allows the automation to not have to deal with all the different
packages.

I think for the automation to happen, we also have to get the subject line
updated.
If we can get it to have what release is in it, parsing the subject line is
much easier than going through all the bugzilla comments trying to find
what release this is supposed to come out in.
Something like "Remove yara from epel8 when RHEL 8.7 is released"

I think once we get to that point, I should be able to write a script that
can grab all the open tickets on the EPEL2RHEL tracker and check if they
are released, and do appropriate things.

Does this sound good to people?

Troy

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1998160
___
epel-devel 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: EPEL7 repo error for distribution-gpg-keys?

[Troy Dawson]

On Wed, Oct 19, 2022 at 2:44 AM Nick Howitt via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> On a server I don't use very often, I am trying to update
> mock-core-configs with yum and I am seeing:
>
> Resolving Dependencies
> --> Running transaction check
> ---> Package mock-core-configs.noarch 0:36.9-1.el7 will be updated
> ---> Package mock-core-configs.noarch 0:36.13-1.el7 will be an update
> --> Processing Dependency: distribution-gpg-keys >= 1.77 for package:
> mock-core-configs-36.13-1.el7.noarch
> --> Finished Dependency Resolution
> Error: Package: mock-core-configs-36.13-1.el7.noarch (epel-unverified)
>Requires: distribution-gpg-keys >= 1.77
>Installed: distribution-gpg-keys-1.75-1.el7.noarch
> (@epel-unverified)
>distribution-gpg-keys = 1.75-1.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
>
>
> On another server I regularly use and update I have
> distribution-gpg-keys-1.77-1.el7.noarch which I updated to a while back, so
> it appears that the updated package has been removed? Obviously this then
> breaks updating mock-core-configs. If
> distribution-gpg-keys-1.77-1.el7.noarch was a bad release, perhaps 1.75
> should be bumped to a later version so it gets installed over 1.77 rather
> than just removing the package?
>

Hi Nick,
Looking at the koji history, 1.77 never was untagged, but 1.75 was tagged
in on Oct. 10th.  Koji and the repo's only show what was the last tagged in.
I'm not sure why 1.75 was tagged in.

distribution-gpg-keys-1.78-1.el7 is currently in testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0

You can get things moving my using the epel-testing repo
  yum --enablerepo=epel-testing update mock-core-configs
If it works for you (it works for me) give the update some karma so it will
go out quicker.

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

[EPEL-devel] Re: Modularity transition plan

[Troy Dawson]

On Fri, Oct 21, 2022 at 9:59 AM Leon Fauster via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Am 21.10.22 um 17:11 schrieb Troy Dawson:
> ...
> > == Transition Steps
> > === 1 - Verify that you are using an EPEL 8 Module
> > dnf list installed | grep epel-modular
> > If nothing shows up, great, you are done.
>
> just wanted to add:
>
> dnf list installed | grep epel-testing-modular
>

Thanks Leon, I forgot that.
I guess to have it all in one

  dnf list installed | grep -e epel-modular -e epel-testing-modular
___
epel-devel 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] Modularity transition plan

[Troy Dawson]

We have been asked for a transition plan, for people using epel 8 modules.
Although we have talked about a transition plan, I realized we didn't write
anything outside of chats and talking to one another.  I believe this is
what we said, but if others can verify and/or correct me, that would be
great.

= EPEL 8 Modularity transition plan
There are users that use EPEL 8 Modules.  This is a transition plan to help
users through this process.

== Transition Steps
=== 1 - Verify that you are using an EPEL 8 Module
  dnf list installed | grep epel-modular
If nothing shows up, great, you are done.

=== 2 - Determine if there are alternatives
Several of the EPEL 8 modules are in RHEL's modules, or are non-modular
packages in epel.  In the list below, look for the modules with [a].  That
means there is an alternative to the epel module.  If your module version
has an [s], then the alternative is the same version.  If your module
version has a [d], then the alternative has a different version.
If you have an alternative, safely switch to the alternative packages.[1]
If you were able to move off of all your epel 8 modules, great, you are
done.

=== 3 - Request non-modular package for EPEL 8
If there were no alternative packages to move to, then request the package
be put in non-modular epel8.  Once it is in non-modular EPEL 8, got back to
step 2.
https://docs.fedoraproject.org/en-US/epel/epel-package-request/

=== 4 - Last Resort
If you have been unable to transition off the EPEL 8 Modules, then the
final option is to just keep using them.  Because the mirrors will be
pointing to the archives, there is nothing you need to change in your
epel-modularity configuration file.  It will just continue to work.  But
keep a backup somewhere because eventually, the epel-modularity
configuration will be completely removed from epel-release.
This is not recommended.  The modules will not receive any further security
or bug fixes.

== EPEL 8 Modules
Legend:
[a] - There is an alternative
[n] - There is no alternative
[s] - There is an alternative with the same version
[d] - There is an alternative with a different version
[x] - This module didn't install, or had some problems with it.

=== 389-directory-server [n]
=== avocado [a]
  * latest [d]
  * 8.2 [s]
=== avocado-vt [n]
=== cobbler [n]
=== cri-o [n]
=== dwm [n][x]
  Does not install on RHEL 8
=== ghc [a]
  * 8.2 [s]
  * 8.4 [d]
=== libuv [a]
=== nextcloud [n][x]
  None of the modules install on RHEL 8
=== nginx [a][d]
=== nodejs [a]
  * 13 [d]
  * 16-epel [s]
=== postgresql [a][d]
=== swig [a][x][s]
  The EPEL version conflicts with RHEL's, should have been removed earlier.
=== zabbix [a]
  * 5.0 [d]
  * 6.0 [s]


Does this sound correct to everyone?

Troy

[1] - Detailed instructions for moving to alternative packages are out of
the scope of this document.
___
epel-devel 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: What to do about an incompatible update I approved

[Troy Dawson]

Hi Dave,
I know I've seen emails about upgrades, so I guess people are sending it to
epel-devel instead of epel-announce.  We'll have to make that more
prominent in the documentation or something.

On Thu, Oct 20, 2022 at 1:44 PM Dave Dykstra  wrote:

> Thanks, Troy.  I will send a message to epel-announce.
>
> I looked through the last couple of years of epel-announce archives and
> don't see similar messages.  I have a hard time imagining that somewhat
> incompatible changes aren't happening to other packages too, so it seems
> that such announcements aren't usually sent.
>
> With regard to golang, they usually have some small incompatibilities
> every minor upgrade.  They do a new minor upgrade every 6 months, they
> only support security updates for 2 minor release lines at a time, and
> they have frequent CVEs, so the only viable option is to keep upgrading
> the minor version number once or twice a year.  There is a golang
> fedoraproject.org mailing list.  Maybe it's enough to announce minor
> release upgrades there instead of epel-announce.
>
>
I don't think very many epel users are going to see the fedora golang
mailing list.
It would be best if it was one of the epel ones, or even both.

Troy

> Dave
>
> On Thu, Oct 20, 2022 at 01:18:30PM -0700, Troy Dawson wrote:
> > On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel <
> > epel-devel@lists.fedoraproject.org> wrote:
> >
> > > Hello all,
> > >
> > > It is been pointed out to me that I pushed out an update of a package
> to
> > > EPEL that did not follow the incompatible upgrades policy:
> > >
> > >
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> > > That's because I wasn't aware of the policy until it was pointed out to
> > > me (or possibly I had seen it once and had forgotten).
> > >
> > > The incompatible change to the "apptainer" package that was pushed to
> > > stable 3 weeks ago moved the setuid-root portion to another package
> > > called "apptainer-suid", which does not get installed by default.  The
> > > remaining package can run non-setuid for most important operations, but
> > > only if unprivileged user namespaces are enabled.  This most effects
> > > EPEL7 because unprivileged user namespaces are not enabled by default.
> > > So the upgrade forces admins who haven't enabled them to either enable
> > > them or install the extra package.  This was done intentionally because
> > > of the inherent risks associated with setuid programs, especially the
> > > fact that the things that this program does with setuid (mounting
> > > filesystems implemented in the kernel although the raw files are
> > > writable by users) is something that kernel developers say should never
> > > be allowed for unprivileged users (https://lwn.net/Articles/652468/
> ). On
> > > the other hand there aren't any known published exploits (anybody know
> a
> > > good squashfs or ext3/4 filesystem developer who could find one?).
> > >
> > > So the question is, what should be done about it since I didn't follow
> > > the procedure before the release 3 weeks ago?
> > >
> > >
> > Better late than never.  Please send an email to epel-announce saying
> what
> > changed and why.
> > I'm not seeing any installation problems because of it, so I don't think
> > you have to worry about other packages.
> >
> > Having an email explaining what was updated and why allows us to point
> > people to the explanation when they have questions.
> >
> >
> > > On a related note, I maintain golang in EPEL7 too, and every time that
> > > RHEL8 upgrades to a new minor golang version number 1.X I do the same
> > > for EPEL7.  I expect that could be considered an incompatible update
> > > too, although every time that's done there's a ton of CVEs that go
> along
> > > with them so it's much easier to argue that the exceptions in the
> > > incompatible upgrade policy apply. The question is, am I supposed to go
> > > through the whole process every time?
> > >
> >
> > If this is a recurring thing, then I believe the answer is "sortof".
> > You don't have to come to the council meeting each time, but you should
> > send out an email to epel-announce saying that it is happening and why.
> >
> > I'm not seeing any epel7 golang dependency problems.
> > I would check to see if it really is an incompatible upgrade.  Usually
> RHEL
> > tries to keep things compatible, so if you are following their lead,
> often
> > things are good.
> >
> > 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

[EPEL-devel] Re: What to do about an incompatible update I approved

[Troy Dawson]

On Wed, Oct 19, 2022 at 5:42 PM Dave Dykstra via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Hello all,
>
> It is been pointed out to me that I pushed out an update of a package to
> EPEL that did not follow the incompatible upgrades policy:
>
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
> That's because I wasn't aware of the policy until it was pointed out to
> me (or possibly I had seen it once and had forgotten).
>
> The incompatible change to the "apptainer" package that was pushed to
> stable 3 weeks ago moved the setuid-root portion to another package
> called "apptainer-suid", which does not get installed by default.  The
> remaining package can run non-setuid for most important operations, but
> only if unprivileged user namespaces are enabled.  This most effects
> EPEL7 because unprivileged user namespaces are not enabled by default.
> So the upgrade forces admins who haven't enabled them to either enable
> them or install the extra package.  This was done intentionally because
> of the inherent risks associated with setuid programs, especially the
> fact that the things that this program does with setuid (mounting
> filesystems implemented in the kernel although the raw files are
> writable by users) is something that kernel developers say should never
> be allowed for unprivileged users (https://lwn.net/Articles/652468/). On
> the other hand there aren't any known published exploits (anybody know a
> good squashfs or ext3/4 filesystem developer who could find one?).
>
> So the question is, what should be done about it since I didn't follow
> the procedure before the release 3 weeks ago?
>
>
Better late than never.  Please send an email to epel-announce saying what
changed and why.
I'm not seeing any installation problems because of it, so I don't think
you have to worry about other packages.

Having an email explaining what was updated and why allows us to point
people to the explanation when they have questions.


> On a related note, I maintain golang in EPEL7 too, and every time that
> RHEL8 upgrades to a new minor golang version number 1.X I do the same
> for EPEL7.  I expect that could be considered an incompatible update
> too, although every time that's done there's a ton of CVEs that go along
> with them so it's much easier to argue that the exceptions in the
> incompatible upgrade policy apply. The question is, am I supposed to go
> through the whole process every time?
>

If this is a recurring thing, then I believe the answer is "sortof".
You don't have to come to the council meeting each time, but you should
send out an email to epel-announce saying that it is happening and why.

I'm not seeing any epel7 golang dependency problems.
I would check to see if it really is an incompatible upgrade.  Usually RHEL
tries to keep things compatible, so if you are following their lead, often
things are good.

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

[EPEL-devel] Re: EPEL 8 Modules get the axe on Halloween 2022

[Troy Dawson]

There has been a schedule update to the epel8 modularity removal.

October 31, 2022
- The updated epel-release will be pushed to epel8 stable
-- This sets "enabled = 0" for epel-modular, if you haven't already changed
your config.

February 15, 2023
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.

* Question:Why was the final archive moved to February 15th.
* Answer1: EPEL is made to help Enterprise users.
Many Enterprise users are already in an end of the year freeze.
This will give them time to plan, test, and implement any changes they
might face.
* Answer2: Because February 14th was voted down by our significant others.

EPEL Steering Committee

On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson  wrote:

> When EPEL-8 was launched, it came with some support for modules with the
> hope that a module ecosystem could be built from Fedora packages using RHEL
> modules as an underlying tool. This has never happened and we have ended up
> with a muddle of modular packages which will 'build' but may not install or
> even run on an EL-8 system. Attempts to fix this and work within how EPEL
> is normally built have been tried for several years by different people but
> have not worked.
>
> At this point we are saying that this experiment with modules in EPEL has
> not worked and we will focus our resources on what does work.
>
> Schedule of EPEL 8 Module Retirement:
> Next Week:
> - epel-release will be updated.
> -- epel-modular will set enabled = 0
> -- epel-modular full name will have "Deprecated" in it
>
> October 31 2022:
> - The EPEL 8 modules will be archived and removed.
> -- The mirror manager will be pointed to the archive.
> - Packagers will no longer be able to build EPEL 8 modules.
>
> After October 31st (Actual date to be determined):
> - epel-release will be updated again.
> -- epel-modular repo configs will be removed.
>
> Questions and Answers:
>
> Question: Will I still be able to access the modules after October 31st?
> Answer: It is not recommended, because the modules will not get any
> security or bug fixes, but yes.  They will be in the Fedora archives,
> and the mirror managers will point at them.
>
> Question: What will you be dressed as on Halloween?
> Answer (Troy): A Penguin
>
> EPEL Steering Committee
>
> [1] - https://pagure.io/epel/issue/198
>
___
epel-devel 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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9

[Troy Dawson]

On Thu, Oct 6, 2022 at 8:50 AM Stephen Smoogen  wrote:

>
>
> On Wed, 31 Aug 2022 at 17:08, Stephen Smoogen  wrote:
>
>>
>> When EPEL-8 was launched, it came with some support for modules with the
>> hope that a module ecosystem could be built from Fedora packages using RHEL
>> modules as an underlying tool. This has never happened and we have ended up
>> with a muddle of modular packages which will 'build' but may not install or
>> even run on an EL-8 system. Attempts to fix this and work within how EPEL
>> is normally built have been tried for several years by different people but
>> have not worked.
>>
>> At this point it is time to say this experiment with modules in EPEL has
>> not worked and focus resources on what does work. I would like to propose
>> that modular support is removed from EPEL by January 2023.
>>
>> Steps:
>> 1. Approval of this proposal by the EPEL Steering committee and any other
>> ones required.
>> 2. Announcement of end of life to various lists.
>> 3. Archiving of the modules on XYZ date to
>> /pub/archive/epel/8.-MM/Modular and pointing mirrormanager to that for
>> that
>> 4. Make changes in bodhi to turn off reporting about modules for EL8.
>> 5. Make changes in MBS configs to turn off building modules for EL8.
>> 6. Make changes in PDC for EL8 modules
>> 7. Make changes in compose scripts and tools to no longer cover EPEL-8
>> modules
>> 8. Remove epel-8 modules from /pub/epel/8
>> 9. Announce closure of this proposal and any lessons learned.
>>
>>
> Due to the year end freezes that many Enterprise consumers are starting, I
> would like to propose the change to the timeline
>
> 2b. Make changes to epel-release so that EPEL modular is no longer turned
> on by default with README.
> 2c. Document configuration changes that would be needed for sites
> mirroring using Enterprise patch management systems.
> 3a. Start regular Archiving of the modules on XYZ date to
> /pub/archive/epel/8
> 3b. and pointing mirrormanager to that for that
>
> We can do steps up to 3a. and then start on 3b and other items after
> February 1st 2023.
>

Just letting people know, adjusting the timeline of the modularity will be
first thing on the agenda in this weeks EPEL Steering Committee meeting.
If we are going to extend the cut off date, we need to decide that fast.
If we are not, I need to get the word out broader than I have.

I personally think we should extend it to sometime in February.  Maybe
February 15th.  Middle of a month on a wednesday.

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

[EPEL-devel] Re: EPEL 8 Modules get the axe on Halloween 2022

[Troy Dawson]

On Fri, Oct 7, 2022 at 5:54 AM Stephen Smoogen  wrote:

>
>
> On Fri, 7 Oct 2022 at 05:59, Miro Hrončok  wrote:
>
>> On 07. 10. 22 9:33, Petr Pisar wrote:
>> > Does EPEL have any communication channel to EPEL users besides this
>> mailing
>> > list? If it does, do you plan to announce this change there? Preferably
>> ahead
>> > of time.
>> >
>> > I worry that users do not follow a list called epel-devel because they
>> think
>> > it's only for EPEL developers. As such this change will come to them as
>> > a surprise.
>>
>>
>> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/
>>
>> I agree this should be said there.
>>
>>
> mailman3 ate the emails announcing the change. I have hopefully fixed that
> the email announcing it was accepted.
>

The email finally went through.
It looks like mailman3 told me it was on hold, but a filter caught that
message so I didn't see it.

I am also writing an article for Fedora Magazine and Fedora Community Blog.
I put those on hold when the shut off date came up for discussion
https://pagure.io/epel/issue/198#comment-820252

I didn't want to write an article with the wrong dates in it.

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

[EPEL-devel] EPEL 8 Modules get the axe on Halloween 2022

[Troy Dawson]

When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.

At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.

Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it

October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.

After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.


Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes.  They will be in the Fedora archives,
and the mirror managers will point at them.

EPEL Steering Committee

[1] - https://pagure.io/epel/issue/198
___
epel-devel 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

[Troy Dawson]

On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson  wrote:

> When EPEL-8 was launched, it came with some support for modules with the
> hope that a module ecosystem could be built from Fedora packages using RHEL
> modules as an underlying tool. This has never happened and we have ended up
> with a muddle of modular packages which will 'build' but may not install or
> even run on an EL-8 system. Attempts to fix this and work within how EPEL
> is normally built have been tried for several years by different people but
> have not worked.
>
> At this point we are saying that this experiment with modules in EPEL has
> not worked and we will focus our resources on what does work.
>
> Schedule of EPEL 8 Module Retirement:
> Next Week:
> - epel-release will be updated.
> -- epel-modular will set enabled = 0
> -- epel-modular full name will have "Deprecated" in it
>
> October 31 2022:
> - The EPEL 8 modules will be archived and removed.
> -- The mirror manager will be pointed to the archive.
> - Packagers will no longer be able to build EPEL 8 modules.
>
> After October 31st (Actual date to be determined):
> - epel-release will be updated again.
> -- epel-modular repo configs will be removed.
>
> Questions and Answers:
>
> Question: Will I still be able to access the modules after October 31st?
> Answer: It is not recommended, because the modules will not get any
> security or bug fixes, but yes.  They will be in the Fedora archives,
> and the mirror managers will point at them.
>
> Question: What will you be dressed as on Halloween?
> Answer (Troy): A Penguin
>
> EPEL Steering Committee
>
> [1] - https://pagure.io/epel/issue/198
>

Question: Many Enterprise customers need time for a transition like this.
Can the transition date be pushed back?
Answer:  This will have to be voted on by the EPEL Steering Committee.  The
answer is likely yes, but I won't give a firm answer until it's been
discussed and voted on.
___
epel-devel 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: Qt update and packages rebuild

[Troy Dawson]

There hasn't been a qt update in CentOS Stream 8 or 9 since May 2022, so
you'll have to give more information.
___
epel-devel 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 8 Modules get the axe on Halloween 2022

[Troy Dawson]

When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install or
even run on an EL-8 system. Attempts to fix this and work within how EPEL
is normally built have been tried for several years by different people but
have not worked.

At this point we are saying that this experiment with modules in EPEL has
not worked and we will focus our resources on what does work.

Schedule of EPEL 8 Module Retirement:
Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0
-- epel-modular full name will have "Deprecated" in it

October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.

After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.

Questions and Answers:

Question: Will I still be able to access the modules after October 31st?
Answer: It is not recommended, because the modules will not get any
security or bug fixes, but yes.  They will be in the Fedora archives,
and the mirror managers will point at them.

Question: What will you be dressed as on Halloween?
Answer (Troy): A Penguin

EPEL Steering Committee

[1] - https://pagure.io/epel/issue/198
___
epel-devel 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 RHEL 9 mirror error

[Troy Dawson]

That is a very good point.
I think the following are better steps
  rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-9
  dnf install
https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Troy
On Mon, Sep 26, 2022 at 10:28 AM Nick Jahn  wrote:

> Wouldn't it be a better option to show in the documentation how to
> download and install the GPG key first, so you don't have to use the
> nogpgcheck option? Security people like secure options better. 
>
> Nicholas Jahn
> IT professional
> A.S. Network Specialist (www.madisoncollege.edu)
> ------
> *From:* Troy Dawson 
> *Sent:* Monday, September 26, 2022 11:46 AM
> *To:* EPEL Development List 
> *Subject:* [EPEL-devel] Re: EPEL RHEL 9 mirror error
>
> I was able to reproduce the error.
> If you do a RHEL install, and select a security profile, it will
> automatically turn on gpg checking for everything.[1]
> You then get the error you were showing.
>
> To get around this you need to add the --nogpgcheck option
>
>   dnf install --nogpgcheck
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.fedoraproject.org%2Fpub%2Fepel%2Fepel-release-latest-9.noarch.rpm=05%7C01%7C%7C1fa3525287c241393aee08da9fdeb15c%7C84df9e7fe9f640afb435%7C1%7C0%7C637998076116157808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=C8yD7Qkt%2FE0aJboL0l1g1kUZXvxDEB3011f9UJgCDSk%3D=0>
>
> Thank you for letting us know.  We'll be sure to update the documentation.
>
> Troy
>
> [1] -
> https://www.mankier.com/5/dnf.conf#Options_for_Both_%5BMain%5D_and_Repo-localpkg_gpgcheck
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mankier.com%2F5%2Fdnf.conf%23Options_for_Both_%255BMain%255D_and_Repo-localpkg_gpgcheck=05%7C01%7C%7C1fa3525287c241393aee08da9fdeb15c%7C84df9e7fe9f640afb435%7C1%7C0%7C637998076116157808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=b%2FtrDDAy8c3Iwp%2FC35%2BoYhdCMgCdaHiP%2B72w7vpo5%2Bs%3D=0>
>
>
> On Mon, Sep 26, 2022 at 7:25 AM Nick Jahn  wrote:
>
> I will wipe out this VM, and re-install RHEL 9 and see if it happens
> again. I already know it isn't security based issues, as none of my systems
> caught anything (I'm a Security Architect), and I was able to download the
> GPG key using WGET, and install it using RPM --import.
>
> I'm fairly certain the issue was that the GPG key was not getting
> deployed.
>
> Nicholas Jahn
> IT professional
> A.S. Network Specialist (www.madisoncollege.edu
> <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.madisoncollege.edu%2F=05%7C01%7C%7C1fa3525287c241393aee08da9fdeb15c%7C84df9e7fe9f640afb435%7C1%7C0%7C637998076116157808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8LvzqKw%2B8jI3asDNIbOwK%2B0btNGn%2Fo3Wl%2B2CQdOCqaM%3D=0>
> )
> --
> *From:* Stephen Smoogen 
> *Sent:* Monday, September 26, 2022 8:59 AM
> *To:* EPEL Development List 
> *Subject:* [EPEL-devel] Re: EPEL RHEL 9 mirror error
>
>
>
> On Mon, 26 Sept 2022 at 09:31, Nick Jahn  wrote:
>
> Tried that, still getting GPG check FAILED. It seems that the security key
> is not getting deployed correctly.
>
> I manually went to the EPEL repo path
> https://dl.fedoraproject.org/pub/epel/
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.fedoraproject.org%2Fpub%2Fepel%2F=05%7C01%7C%7C1fa3525287c241393aee08da9fdeb15c%7C84df9e7fe9f640afb435%7C1%7C0%7C637998076116157808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8tTjjlYs%2FdS0hjcQysjjPjKok1t1KQYJ5vluGqlStOY%3D=0>
>  and
> found the EPEL 9 Key, downloaded it and installed the key, and now the
> connection is working. The reason I reached out in the first place was to
> let you know that the deployment was not working as designed, as I know the
> EPEL Key is supposed to download and install when you perform the
> installation of the REPO (which was not happening). This needs to be fixed
> or you need to update the documentation to let others know that they need
> to download and install the RPM GPG KEY for EPEL 9 before using the rest of
> the guide..
>
>
> OK I am doing a retest of the instructions with a fresh Alma 9 install.
> I have installed it with minimal functionality and done a `dnf update` to
> get it up to the latest packages.
> Then I have rebooted it and done the following commands:
> ```
> [root@localhost ~]# sudo dnf config-manager --s

[EPEL-devel] Re: EPEL RHEL 9 mirror error

[Troy Dawson]

I was able to reproduce the error.
If you do a RHEL install, and select a security profile, it will
automatically turn on gpg checking for everything.[1]
You then get the error you were showing.

To get around this you need to add the --nogpgcheck option

  dnf install --nogpgcheck
https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Thank you for letting us know.  We'll be sure to update the documentation.

Troy

[1] -
https://www.mankier.com/5/dnf.conf#Options_for_Both_%5BMain%5D_and_Repo-localpkg_gpgcheck


On Mon, Sep 26, 2022 at 7:25 AM Nick Jahn  wrote:

> I will wipe out this VM, and re-install RHEL 9 and see if it happens
> again. I already know it isn't security based issues, as none of my systems
> caught anything (I'm a Security Architect), and I was able to download the
> GPG key using WGET, and install it using RPM --import.
>
> I'm fairly certain the issue was that the GPG key was not getting
> deployed.
>
> Nicholas Jahn
> IT professional
> A.S. Network Specialist (www.madisoncollege.edu)
> --
> *From:* Stephen Smoogen 
> *Sent:* Monday, September 26, 2022 8:59 AM
> *To:* EPEL Development List 
> *Subject:* [EPEL-devel] Re: EPEL RHEL 9 mirror error
>
>
>
> On Mon, 26 Sept 2022 at 09:31, Nick Jahn  wrote:
>
> Tried that, still getting GPG check FAILED. It seems that the security key
> is not getting deployed correctly.
>
> I manually went to the EPEL repo path
> https://dl.fedoraproject.org/pub/epel/ and found the EPEL 9 Key,
> downloaded it and installed the key, and now the connection is working. The
> reason I reached out in the first place was to let you know that the
> deployment was not working as designed, as I know the EPEL Key is supposed
> to download and install when you perform the installation of the REPO
> (which was not happening). This needs to be fixed or you need to update the
> documentation to let others know that they need to download and install the
> RPM GPG KEY for EPEL 9 before using the rest of the guide..
>
>
> OK I am doing a retest of the instructions with a fresh Alma 9 install.
> I have installed it with minimal functionality and done a `dnf update` to
> get it up to the latest packages.
> Then I have rebooted it and done the following commands:
> ```
> [root@localhost ~]# sudo dnf config-manager --set-enabled crb
> [root@localhost ~]# dnf install
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
> AlmaLinux 9 - CRB
>
> 3.3 MB/s | 2.5 MB 00:00
> Last metadata expiration check: 0:00:01 ago on Mon 26 Sep 2022 09:52:47 AM
> EDT.
> epel-release-latest-9.noarch.rpm
>
>124 kB/s |  18 kB 00:00
> Dependencies resolved.
>
> ==
>  Package Architecture
>  Version  Repository
> Size
>
> ==
> Installing:
>  epel-releasenoarch
>  9-4.el9  @commandline
> 18 k
>
> Transaction Summary
>
> ==
> Install  1 Package
>
> Total size: 18 k
> Installed size: 25 k
> Is this ok [y/N]: y
> Downloading Packages:
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Transaction test succeeded.
> Running transaction
>   Preparing:
>
>1/1
>   Installing   : epel-release-9-4.el9.noarch
>
>1/1
>   Running scriptlet: epel-release-9-4.el9.noarch
>
>1/1
> Many EPEL packages require the CodeReady Builder (CRB) repository.
> It is recommended that you run /usr/bin/crb enable to enable the CRB
> repository.
>
>   Verifying: epel-release-9-4.el9.noarch
>
>1/1
>
> Installed:
>   epel-release-9-4.el9.noarch
>
>
>
> Complete!
> [root@localhost ~]# dnf install screen
> Last metadata expiration check: 0:00:21 ago on Mon 26 Sep 2022 09:53:52 AM
> EDT.
> Dependencies resolved.
>
> =
>  Package  Architecture
> Version
> Repository  Size
>
> 

[EPEL-devel] Re: EPEL RHEL 9 mirror error

[Troy Dawson]

On Fri, Sep 23, 2022 at 10:37 AM Nick Jahn  wrote:

> Errors during downloading metadata for repository
> 'dl.fedoraproject.org_pub_epel_9_x86_64_':
>   - Status code: 404 for
> https://dl.fedoraproject.org/pub/epel/9/x86_64/repodata/repomd.xml (IP:
> 38.145.60.24)
> Error: Failed to download metadata for repo
> 'dl.fedoraproject.org_pub_epel_9_x86_64_': Cannot download repomd.xml:
> Cannot download repodata/repomd.xml: All mirrors were tried
>
>
> That URL is wrong, it should be
> https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/repodata/repomd.xml
>

Looking at the name, and the URL, that is from a custom repo config file.

The easiest way to spot that is the name
'dl.fedoraproject.org_pub_epel_9_x86_64_'
It should be "Extra Packages for Enterprise Linux 9 - x86_64"
You should contact the machine's administrator.
If you are the machine's administrator, then I would search for
dl.fedoraproject.org in a file in /etc/yum.repos.d/ and fix the repo file.

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

[EPEL-devel] Re: Fwd: xscreensaver package for epel9 (Bugzilla 2120163)

[Troy Dawson]

For those that are wondering, the latest version in rawhide build on epel9
without any changes needed.
So it should be fairly straightforward.

Troy


On Mon, Sep 19, 2022 at 4:20 AM Stephen Smoogen  wrote:

>
> This went to the mailing list admins versus the list. I don't think this
> person is on the list so you will need to cc them an answer.
>
> -- Forwarded message -
> From: metatron...@yahoo.com 
> Date: Sun, 18 Sept 2022 at 20:01
> Subject: xscreensaver package for epel9 (Bugzilla 2120163)
> To: epel-devel-ow...@lists.fedoraproject.org <
> epel-devel-ow...@lists.fedoraproject.org>
>
>
> Hello EPEL Development Team,
>
> I was wondering if there are any packagers who would be willing to package
> and maintain xscreensaver in EPEL9. I previously created a Bugzilla ticket
> at https://bugzilla.redhat.com/show_bug.cgi?id=2120163. The current
> package maintainer for Fedora is not able to maintain an EPEL package (as
> noted in the comments of the ticket). Is there a packager who would be
> willing to make xscreensaver available in EPEL9? Thank you so much for your
> consideration!
>
> Regards,
> metatron320
>
>
>
>
> --
> 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
>
___
epel-devel 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] qt6 being updated in epel9

[Troy Dawson]

qt6 is being updated from 6.2.3 to 6.3.1 in epel9.[1]
There is no soname bump, and everything should be backward compatible.

Why announce it?
Our KDE Plasma Desktop policy is to do a major update only once a year in
the main epel repositories.
qt6 is currently NOT part of the KDE Plasma Desktop.  Nothing in the
current KDE Plasma Desktop depends on it.  But, since it is a qt library, I
figured some people might think I'm updating the qt library out from under
them.

Again:
qt5, part of the KDE Plasma Desktop, is not changing.
qt6, NOT part of the KDE Plasma Desktop, is being updated.

Thank You
Troy
[1] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ac12e0b1de
___
epel-devel 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: Backported som rpm from fedora to epel

[Troy Dawson]

lsyncd and autossh - already in epel9

geoip - https://bugzilla.redhat.com/show_bug.cgi?id=2066787
"Please do NOT branch GeoIP for EPEL 9, because MaxMind, the GeoIP
upstream, has clearly declared the end of life for GeoIP"

webalizer - nobody has asked for it.  And maybe someone needs to port
webalizer to use libmaxminddb

On Fri, Sep 9, 2022 at 6:29 AM Serge Sterck via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> I have backported from fedora to almalinux 9/centos 9/rocky 9 some rpms
>
>
> lsyncd
> autossh
> geoip needed for webalizer
> webalier
>
>
> i provide the binary and the source rpm at this url
>
>
> alma9-rpm
> 
>
___
epel-devel 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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9

[Troy Dawson]

On Thu, Sep 1, 2022 at 12:19 AM Miro Hrončok  wrote:

> On 31. 08. 22 23:08, Stephen Smoogen wrote:
> >
> > When EPEL-8 was launched, it came with some support for modules with the
> hope
> > that a module ecosystem could be built from Fedora packages using RHEL
> modules
> > as an underlying tool. This has never happened and we have ended up with
> a
> > muddle of modular packages which will 'build' but may not install or
> even run
> > on an EL-8 system. Attempts to fix this and work within how EPEL is
> normally
> > built have been tried for several years by different people but have not
> worked.
> >
> > At this point it is time to say this experiment with modules in EPEL has
> not
> > worked and focus resources on what does work. I would like to propose
> that
> > modular support is removed from EPEL by January 2023.
> >
> > Steps:
> > 1. Approval of this proposal by the EPEL Steering committee and any
> other ones
> > required.
> > 2. Announcement of end of life to various lists.
>

2.5 - move epel-modular.repo and epel-testing-modular.repo to it's own
sub-package of epel-repos-modular


> > 3. Archiving of the modules on XYZ date to
> /pub/archive/epel/8.-MM/Modular
> > and pointing mirrormanager to that for that
> > 4. Make changes in bodhi to turn off reporting about modules for EL8.
> > 5. Make changes in MBS configs to turn off building modules for EL8.
> > 6. Make changes in PDC for EL8 modules
> > 7. Make changes in compose scripts and tools to no longer cover EPEL-8
> modules
> > 8. Remove epel-8 modules from /pub/epel/8
> > 9. Announce closure of this proposal and any lessons learned.


 10. Drop
https://src.fedoraproject.org/rpms/epel-release/blob/epel8/f/epel-testing-modular.repo
from epel-repos-modular

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