/show_bug.cgi?id=1339379
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> So what is the point of modules then? If we want just multiple
> versions of a few applications, we can just have few repositories.
Add another repository for every alternate version (stream) doesn't scale.
___
devel mailing list --
> Or you think changing huge pieces of infrastructure, and working for
> 3+ years on a project (modularity) was done just to have 3 versions of
> Node.js available?
Of course not. Modularity is a great fit to provide multiple versions many
applications (in one repository), such as php, mariadb,
libgit2 help me
understand. Given the current issues, this seems like a reasonable solution.
If other agree, I'm happy to submit these compat packages for review.
Carl George
Rackspace
___
devel mailing list -- devel@lists.fedoraproject.org
://bugzilla.redhat.com/show_bug.cgi?id=1833855
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code
Pull request has been rebased and is ready to be merged. Thanks for
your help with this Richard.
On Thu, Sep 24, 2020 at 6:59 PM Richard Shaw wrote:
>
> On Thu, Sep 24, 2020 at 4:34 PM Carl George wrote:
>>
>> I read the policy [0] as "major (bug | security) fixes&q
://copr.fedorainfracloud.org/coprs/carlwgeorge/mumble-wayland/
On Tue, Sep 22, 2020 at 6:57 PM Richard Shaw wrote:
>
> On Tue, Sep 22, 2020 at 3:30 PM Carl George wrote:
>>
>> Howdy folks,
>>
>> This is a non-responsive maintainer check for fedpop, in accordance with
>
ld be patched in F31 as well - so since
> this update fixes it, the update would be suitable for F31.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1849735
>
> -Ian
>
> On Thu, Sep 24, 2020 at 5:01 PM Carl George wrote:
>>
>> F32 is fine by me. Based on the updates polic
://src.fedoraproject.org/rpms/mumble/c/490fc25a45b4816b73ac2ff5c0954668ae4b723a?branch=master
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https
at 2:54 PM Richard Shaw wrote:
>
> On Wed, Sep 23, 2020 at 2:42 PM Carl George wrote:
>>
>> Yes, the patch is from an upstream pull request [0] that has already
>> been merged to the master branch [1] and is planned to be included in
>> their next release [2]
g_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapro
I just orphaned the python-mitogen package. I packaged it for my last
job but I no longer use it and I'm not interested in maintaining it
anymore. As best I can tell, nothing else in the distribution
requires or build requires it. It's up for grabs if anyone is
interested.
--
Carl George
> Yep, migration needs work. Acknowledged. The same could be said of
> changing an init system, changing a default syslog implementation,
> changing the way a database server is configured, changing the defaults
> for a proxy server's configuration... and so many more.
>
> G'luck,
> Pe
he architectures that
EPEL does. As far as I can tell, the three most popular (Alma, Rocky,
Oracle) only offer x86_64 and aarch64 but are missing ppc64le and
s390x. That said CentOS Linux 8 doesn't offer s390x either, so we
already have this problem, but switch the EPEL mock chro
dora-infrastructure
Agreed, for quick local builds it's fine to use epel8-next (c8s) to
verify it builds and then submit the koji build to the epel8 (rhel8)
target. If the local build works but the koji build doesn't, you
likely have a candidate for an official epel8-next koji build.
--
Carl George
_
email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
pdate [1] to
version 5? It may already be EOL, but surely that's a better option
than the current version 3 or removing it entirely.
[0]
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#what_can_be_retired
[1] https://docs.fedoraproject.org/en-US/epel/epel-polic
f-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Carl George
ist Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Carl George
___
devel mailing list -- deve
oject/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
I've just orphaned python-pdir2 as I no longer use it. Feel free to
take ownership if you like. Fair warning, it's failing to build for
Python 3.11 in rawhide, and updating to the latest version will
require packaging pdm-pep517.
--
Carl George
On Fri, Aug 26, 2022 at 3:59 PM Fabio Valentini wrote:
>
> On Fri, Aug 26, 2022, 21:20 Demi Marie Obenour wrote:
>>
>> On 8/26/22 06:12, Fabio Valentini wrote:
>> > On Fri, Aug 26, 2022 at 3:12 AM Carl George wrote:
>> >>
>> >> sqlcipher has be
the exception flag because it would fall under the second bullet
point for exceptions.
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
If the package is intended to be EPEL-only, make sure to retire the
rawhide branch.
--
Carl George
not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Carl George
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https:/
side tag and then complete the rebuilds in the side
tag myself via proven packager permissions.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2120882
[1] https://src.fedoraproject.org/rpms/sqlcipher/pull-request/3
[2] https://copr.fedorainfracloud.org/coprs/jonathanspw/sqlcipher/builds/
--
Ca
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-infrastruct
e come up with) when I create the #change-proposal tag.
>
> Moving the packaging list is a Packaging Committee decision.
>
> Automated posts can be moved at any time. I can work with the people
> who own the generation of those reports to figure out a good answer for
docs.fedoraproject.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:
> ht
ibe 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.fedo
the package around.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2176050
[1]
https://src.fedoraproject.org/rpms/golang-github-deepmap-oapi-codegen/c/2792c7c77ff7815f82a942a944ccf48f0401c0a1?branch=rawhide
--
Carl George
___
devel mailing list -- devel
s://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Carl George
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send a
...@iuscommunity.org
ius-core...@lists.launchpad.net
Community members:
ius-commun...@lists.launchpad.net
Carl George
Rackspace GNU/Linux Engineer
From: Rahul Sundaram [methe...@gmail.com]
Sent: Friday, August 29, 2014 07:38 PM
To: EPEL Development List
Cc: core
(such as python34u). Currently our python3* packages
all conflict with each other. We have an open request to allow multiple
version of our python3* packages by using update-alternatives [0]. We may or
may not implement it, but it is another option that the EPEL might want to
consider.
- Carl
To facilitate packages that require a newer version of libsodium, I have
coordinated an update of libsodium in EPEL7 from version 1.0.5
(libsodium.so.13) to version 1.0.16 (libsodium.so.23). To avoid any ABI
breakage for existing packages, a new libsodium13 compatibility package has
been
Thanks for the feedback Neal. I have submitted the update.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-93f737b65e
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to
Red Hat added python3 to RHEL 7.7, but at least for now has declined to turn on
the python3 subpackage in the libselinux spec file.
https://bugzilla.redhat.com/show_bug.cgi?id=1719978
I have attempted to to extract the python3 subpackage into it's own spec file.
It seems to work as best I can
ubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list
>
> What day and time would people like?
> If you haven't been able to come to the meeting due to the time, what
> would be best for you?
>
> Troy
>
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedorapr
..@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fe
:~]# repoquery --quiet --disablerepo \*
--queryformat '%{name}' --archlist src --enablerepo
epel-source,epel-testing-source --whatrequires oniguruma-devel
jq
```
Let me know your thoughts and concerns about moving forward with this.
--
Carl George
___
epel
sewhere.
>
> Thanks,
>
> --
> Michel Alexandre Salim
> profile: https://keybase.io/michel_slm
> chat via email: https://delta.chat/
> GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
> ___
> CentOS-devel mailing list
> cento
list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Arch
>
> On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar wrote:
> >
> > On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > > To solve this problem, I am proposing that we create a new repository
> > > called
> > > EPEL 8 Next.
> > >
> >
getting
published without review would degrade the experience for CentOS Stream
users. We could do a lower karma/time threashold than regular EPEL if
desired.
On Wed, Sep 9, 2020 at 11:55 AM Kevin Fenzi wrote:
>
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > Howdy f
uot;Eee pee
> cee ess")
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> epel-devel mailing list -- epel
fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
--
Carl George
_
this idea at the last EPEL Steering Committee meeting, and
we plan to discuss it again during the next one. Please share your thoughts
on this proposal.
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send
, 2020 at 11:12:28PM -0500, Carl George wrote:
> > Here is my rough outline of the steps required to implement this proposal.
> > I imagine things would happen roughly in this order, but some things could
> > probably take place in parallel.
> >
> > 1. EPEL Steering C
:
>
> On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
> > At the EPEL Steering Committee last week, we had an extensive discussion of
> > this proposal, specifically focused on how to handle the dist macro. I
> > believe these are the possible choices.
>
in bodhi
9. document in the wiki
10. announcement email
Please let me know if I'm missing anything.
On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote:
>
> I agree, using .el8.next for the dist macro makes the most sense. This will
> enable maintainers to use a similar workflow
s
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedorapro
://meetbot.fedoraproject.org/teams/epel/epel.2020-05-22-21.04.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1777660
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1836692
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
This update has been submitted to stable.
On Thu, May 28, 2020 at 12:53 PM Carl George wrote:
>
> Greetings,
>
> Per the EPEL incompatible upgrades policy [0], this is an announcement of a
> backwards incompatible update [1] of oniguruma in EPEL 7. This change was
> ap
aproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
--
Carl
present this proposal and the
feedback to the EPEL Steering Committee.
--
Carl George
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct
Agreed. And if a maintainer decides to stick with the python36 name,
they MUST provide the equivalent python3 name. I've captured those
for what I'll add to the guidelines.
On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote:
>
> On 21. 01. 21 7:19, Carl George wrote:
> > I pro
Agreed. And if a maintainer decides to stick with the python36 name,
they MUST provide the equivalent python3 name. I've captured those
for what I'll add to the guidelines.
On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote:
>
> On 21. 01. 21 7:19, Carl George wrote:
> > I pro
this purpose.
On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison
wrote:
>
>
> On Thu, 21 Jan 2021, Carl George wrote:
>
> > RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> > EPEL7 contains Python 3.6 packages using both the python3 and python
this purpose.
On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison
wrote:
>
>
> On Thu, 21 Jan 2021, Carl George wrote:
>
> > RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> > EPEL7 contains Python 3.6 packages using both the python3 and python
the guideline in place for package reviews to reference, to
prevent any further packages using non-standard prefixes from being
added.
On Thu, Jan 21, 2021 at 11:28 AM Kevin Fenzi wrote:
>
> On Thu, Jan 21, 2021 at 12:19:39AM -0600, Carl George wrote:
> > Howdy folks,
> >
> >
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Carl George
_
-2021-c0fcb78eb0
[5] https://fedoraproject.org/wiki/EPEL_Next#FAQ
[6] https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow
On Tue, Sep 8, 2020 at 11:00 PM Carl George wrote:
>
> Howdy folks,
>
> A large part of my day job is working on CentOS Stream. Naturally I would
> like it t
://fedoraproject.org/wiki/EPEL_Next
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code
t Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Carl George
___
Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply t
project.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
, and would be happy to see them go away when
python34 is retired (which can happen independently of python3.9).
On Wed, Apr 7, 2021 at 2:36 AM Miro Hrončok wrote:
>
> On 07. 04. 21 4:50, Carl George wrote:
> > What do you mean by support? The only thing EPEL supports (using the
>
/wiki/EPEL_incompatible_upgrades_policy
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email
On Fri, Sep 24, 2021 at 3:05 PM Josh Boyer wrote:
>
> On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa wrote:
> >
> > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote:
> > >
> > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > The RHEL 9 composes do not
go with Plan B or C we will need to make the decision
> > fairly quickly.
>
> I like A. ;)
>
> I think B is risky because of the possible changes between beta and ga,
> and I think C is breaking the 'we build against rhel' implied promise as
> well as leaving
t.org/archives/list/epel-devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send
rastructure
Thanks everyone for the feedback so far. I would still like to talk
with the Fedora Infra folks in a bit more depth about the difficulty
level of each plan, but at this point in time I feel like plan C is
the best option because of the benefits.
- simple instructions to maintainers
-
il to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/e
epel9 branches before building.
Plans B and C are more like the status quo, where packagers target
epel9, and do individual package rebuilds as needed after a RHEL minor
release.
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.
he architectures that
EPEL does. As far as I can tell, the three most popular (Alma, Rocky,
Oracle) only offer x86_64 and aarch64 but are missing ppc64le and
s390x. That said CentOS Linux 8 doesn't offer s390x either, so we
already have this problem, but switch the EPEL mock chro
dora-infrastructure
Agreed, for quick local builds it's fine to use epel8-next (c8s) to
verify it builds and then submit the koji build to the epel8 (rhel8)
target. If the local build works but the koji build doesn't, you
likely have a candidate for an official epel8-next koji build.
--
Carl George
email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to ep
a-infrastructure
Closing the loop here, at the 2021-11-24 EPEL Steering Committee
meeting we voted and selected plan C.
https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
We are in the process of finishing up the EPEL9 implementation and
plan to launch EPEL9 and EPEL9 Next together
/epel with all your EPEL questions.
https://discussion.fedoraproject.org/t/join-us-for-the-epel-office-hours-every-month/37235
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote:
>
> On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson wrote:
> >
> >
> >
> > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera wrote:
> >>
> >> I've been checking the packages that won't install on EPEL
n-US/fesco/Policy_for_nonresponsive_package_maintainers/
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/pr
fedoraproject.org/archives/list/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
This update changes a library soname, which makes it an incompatible
upgrade. It must follow the EPEL incompatible upgrades policy [0
On Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi wrote:
>
> On Wed, Mar 23, 2022 at 09:18:08PM -0500, Carl George wrote:
> > On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote:
> > >
> > > Typically EPEL inherits policy from Fedora, diverging when necessary.
> >
uld strictly forbid any dependency on HA or RS packages, because
that would require unnecessary duplication of HA/RS packages in EPEL
(which is allowed, but shouldn't be required IMO). I suggest a
compromise that we can make the policy:
"All EPEL package dependencies (build-time or run
On Fri, Apr 8, 2022 at 2:23 AM Nick Howitt via epel-devel
wrote:
>
>
>
> On 08/04/2022 04:38, Carl George wrote:
> > On Thu, Apr 7, 2022 at 7:33 PM Gemneye via epel-devel
> > wrote:
> >>
> >>>>
> >>>> Error: Package: hwinfo-21.68-
Obviously that's not what happened
here. The quickest fix is to rebuild hwinfo against the new soname.
I did that for EPEL8 a few days ago, and just submitted the EPEL7 one
now. Follow along in the bugzilla for future updates.
[0] https://bugzilla.redhat.
-centos
[3] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
[4] https://caddyserver.com/docs/v2-upgrade
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
/caddyserver/caddy/releases/tag/v2.5.0
[4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0
[5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
On Thu, Aug 24, 2023 at 1:44 AM Carl George wrote:
>
> I am performing an incompatible upgrade of the caddy package in EPEL
> 9. In accordance with the incompatible upgrade policy [0], I proposed
> this upgrade just over a week ago on the epel-devel mailing list [1].
> For r
.
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire
Here is a general guide for requesting packages in EPEL (tldr; file a bugzilla).
https://docs.fedoraproject.org/en-US/epel/epel-package-request/
--
Carl George
___
epel-devel mai
but please centralize your
feedback on the Discussion thread.
https://discussion.fedoraproject.org/t/revisting-conflicts-policy-for-epel-compat-packages/90605
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubs
[4] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject
Closing the loop here, I've retired klee in EPEL 9.
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/SP2624QZPY33N3NZNX5QLSMO2HZBHNNQ/
On Fri, Sep 29, 2023 at 12:01 PM Kevin Fenzi wrote:
>
> On Thu, Sep 28, 2023 at 10:37:28PM -0500, Carl George
/VIP6GZFVNFRC2MZUB6OUEDF2SSW4BBVI/
[2] https://github.com/klee/klee/blob/v3.0/.github/workflows/build.yaml#L39
[3] https://github.com/klee/klee/pull/1648
[4] https://github.com/klee/klee.github.io/pull/347
[5]
https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8
--
Carl George
ves/list/python-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
I like this plan overall. The only part I would adjust is the
guidelines having a MUST requirement to use one flag or the other.
Fewer required
/caddy/
[7] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code
-0b57e19163
--
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct
chroot as an explicit argument. Instead of making the majority of
users do `dnf copr enable epel-9-`, why can't we have a
tiny number of users do `dnf copr enable
centos-stream-9-` and have the plugin guess the correct thing
for the majority of users?
[0] https://bugzilla.redha
ps://bugzilla.redhat.com/show_bug.cgi?id=2098360
>
> On 2022-06-17 16:28, Carl George wrote:
> > On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
> >>
> >> would anyone be willing to package this in epel or help get it in the
> >> existing package please?
&g
to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
I think it would be nice to be able to both enable and disable from
the same script. This would come in handy when you are looking for
things that don't install when crb is disabled. I don't see a
1 - 100 of 130 matches
Mail list logo
