Let's try to get this flushed out in time for our EPEL Steering
Committee meeting this Friday.
I think we've figured out most of the pitfalls that might happen. I
believe this is what the discussion ended up with.
The current guidelines [1] say:
EPEL packages should only enhance and never
/taskinfo?taskID=44213799
* plasma-nm - Cannot build until CentOS 8.2 is released, with it's Devel repo.
On Thu, Apr 30, 2020 at 9:00 AM Troy Dawson wrote:
>
> Now that RHEL 8.2 is out, those of you who are KDE users might notice
> that you cannot update certain things due to the chan
Short answer, no, there is currently no way for me to remove it from
playground. I wish I could.
Unless you have a specific need, you shouldn't have playground enabled
anymore. You don't need it for KDE anymore.
I've given instructions via email and web pages on how to install KDE
via regular
I'm not sure why this version (-3) wasn't put in bodhi.
But I've had to tag it into override to get a package built. And my
package built successfully, so I'm pretty sure it works.
Anyway, I've put it in bodhi, so giving it some karma would get it to
stable faster.
On Wed, Sep 9, 2020 at 2:44 PM Miro Hrončok wrote:
>
> On 08. 09. 20 17:52, Troy Dawson wrote:
> > Note1: Not everything has been implemented yet. package.cfg is still
> > in the epel repos. fedpkg has not been updated. This documentation
> > will go out when those
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.
> >
> > - built against CentOS 8 Stream
> > - opt-in for packagers (must request
Note1: Not everything has been implemented yet. package.cfg is still
in the epel repos. fedpkg has not been updated. This documentation
will go out when those changes are implemented.
Note2: This is a proposal. It can be changed. If there is something
in there you do not want or think should
On Sun, Sep 6, 2020 at 2:01 PM Kevin Fenzi wrote:
>
> On Fri, Sep 04, 2020 at 07:18:31AM -0700, Troy Dawson wrote:
> ...snipp
> > I think Step 5 is a very important step (if I'm understanding it
> > correctly). Because it will give us a good idea about how many peo
On Tue, Sep 8, 2020 at 8:49 AM Jason Oppel wrote:
>
> The kde-connect package is missing kf5-kirigami and kf5-kirigami2 as
> dependencies.
>
> Steps to reproduce:
> Without KDE installed (running XFCE), performing a "dnf install
> kdeconnect-app". Everything installs just fine. However, when
On Tue, Sep 15, 2020 at 1:53 AM Pavel Raiskup wrote:
>
> Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can
> reproduce builds locally with mock. Initially the configuration worked, but
> it
> has been failing for quite some time now. Dnf isn't able to
This is the second draft. It has added a section in the developer
section saying to clean your packages up when you are done playing and
testing them.
Edit's are still welcome, but I think it covers everything that has
been discussed and approved.
This will be published about the same time that
On Wed, Sep 2, 2020 at 2:08 PM Kevin Fenzi wrote:
> I think playground might be fixable/made of use without too much work...
> * adjust fedpkg to stop requesting playground branches always/only
> request them on explicit ask
> * change the inheritence in koji so it inherits from epel8
> * untag
On Fri, Sep 4, 2020 at 11:18 AM Paul Howarth wrote:
>
> On Fri, 4 Sep 2020 07:18:31 -0700
> Troy Dawson wrote:
> > Step 4 - Untag all the things that are "older" in playground
> > -- currently that is a releng process. There is no way for a
> > maintainer to
On Fri, Sep 4, 2020 at 7:18 AM Troy Dawson wrote:
> Step 1 - Approve plan via Steering Committee.
> Step 1a - Documents and communication
> -- No releng needed.
> -- Should be done along the whole way
> Step 2 - Update fedpkg and remove all package.cfg from epel8.
> -- Can b
EPEL 6 is End Of Life (EOL) on November 2020.
EPEL 6 will be moved to archives in December 2020.
Plan ahead now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen wrote:
>
>
>
> On Mon, 31 Aug 2020 at 09:43, Troy Dawson wrote:
>>
>> On Sun, Aug 30, 2020 at 11:44 AM kevin wrote:
>> >
>>
>> > > Thoughts?
>> >
>> > Well, I think it
On Sun, Aug 30, 2020 at 11:44 AM kevin wrote:
>
> On Fri, Aug 28, 2020 at 03:11:49PM -0700, Troy Dawson wrote:
> > > Pros for building against stream:
> > > - We would have a way to test EPEL packages that matter against the
> > > not yet released RHEL
Thank you.
Looks like the kirigami2 stuff isn't just an EPEL problem, same thing
happens in the latest Fedora Rawhide.
I'm filing a bug and getting the kirigami2 stuff fixed.
As for why your phone isn't seen, I don't know. I don't use
kdeconnect. You might get more help with that on the fedora
Due to many of the members of the EPEL Steering Committee not being
able to make the meeting,
this week's meeting has been canceled.
On Thu, Oct 15, 2020 at 2:00 PM wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2020-10-16 from 21:00:00 to
On Thu, Oct 1, 2020 at 9:13 PM Carl George wrote:
>
> Here is my rough outline of the steps required to implement this proposal.
> I imagine things would happen roughly in this order, but some things could
> probably take place in parallel.
>
> 1. EPEL Steering Committee approves the proposal
>
On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson wrote:
>
> On Sat, Aug 22, 2020 at 11:12 AM kevin wrote:
> >
> > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
> > >
> > > On 21/8/20 19:06, Troy Dawson wrote:
> >
> > &g
On Wed, Aug 19, 2020 at 4:52 PM Miro Hrončok wrote:
>
> On 01. 08. 20 0:13, Troy Dawson wrote:
> > We were having a good discussion about epel8-playground in the
> > Steering Committee meeting this week. Since we ran out of time I'd
> > like to continue it via email.
>
On Sat, Aug 22, 2020 at 11:12 AM kevin wrote:
>
> On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
> >
> > On 21/8/20 19:06, Troy Dawson wrote:
>
> > > C) Drop playground. Say it was an interesting experiment and we
> > > learned stuff
- fedpkg will be updated to not automatically request a
epel-playground branch each time an epel branch is requested.
https://pagure.io/fedpkg/issue/414
We appreciate all the input we've gotten from everyone.
Please pass this information on wherever you feel it is needed.
Troy Dawson
On Tue, Sep 22, 2020 at 5:28 AM Andrew C Aitchison
wrote:
>
> On Tue, 22 Sep 2020, Patrik Novotny wrote:
>
> > Hi,
> >
> > there's intend to retire the mongodb package from EPEL7 [1]. As for
> > the MongoDB license change[2], we are not able to backport patches,
> > which leaves us shipping
On Mon, Jun 1, 2020 at 1:11 AM Felix Schwarz wrote:
>
> Hi,
>
> I'm unable to submit updates to EPEL 7 stable:
>
> $ bodhi updates request FEDORA-EPEL-2020-d8b45f1e30 stable
>
> fedora.client.ServerError:
> ServerError(https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d8b45f1e30/request,
>
On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote:
>
> On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote:
> ...snip...
> >
> > When a maintainer is done with their package in playground, they must
> > untag all builds of it out of epel-playground. We do n
The correct procedure for getting a package into EPEL 8 is to open a
bugzilla[1] requesting it.
That way it will go to the package maintainer.
I did a quick look and it should be fairly easy for the maintainer to
create the package. It looks like they updated argbash across all
platforms,
We were having a good discussion about epel8-playground in the
Steering Committee meeting this week. Since we ran out of time I'd
like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and
it's hard to explain to end users what it is for, or when to use
Due to several people not being available, this week's meeting has
been canceled.
On Thu, Aug 13, 2020 at 2:01 PM wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2020-08-14 from 21:00:00 to 22:00:00 UTC
>At freenode@fedora-meeting
>
> The
On Tue, Aug 11, 2020 at 1:26 AM Dave Love wrote:
>
> I just tried to build an R package in copr, and it failed because an R
> dependency (which I maintain) needs rebuilding for R 4.
>
> Apart from the question of why R was updated to an incompatible version,
> what was supposed to happen about
Due to US holidays, and others on vacation, this weeks EPEL Steering
Committee Meeting has been canceled.
On Thu, Jul 2, 2020 at 2:00 PM wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Committee on 2020-07-03 from 21:00:00 to 22:00:00 UTC
>At
On Sat, Jul 4, 2020 at 2:33 AM david wrote:
>
> Hi, I am participating in https://github.com/codito/gnome-pomodoro/issues/456
> thread and it was mentioned by @mbooth101 to ask for advice here.
>
> Is it possible to build gnome-pomodoro on Centos 8.2?
>
I believe this is the fedora package
o not work in System Settings.
https://bugzilla.redhat.com/show_bug.cgi?id=1838801
Help resolving this bug would be appreciated.
It is irritating, but not critical.
Many thanks to all who helped with this.
Troy Dawson
[1] plasma-nm is currently at 5.15. This has been verified to work.
We will hopeful
Hi Miro,
I was hoping someone more python oriented would look at this, but I
guess that isn't happening.
I'll take a look at it later today.
On Thu, Jun 18, 2020 at 2:38 AM Miro Hrončok wrote:
>
> Hello, I've opened this PR some time ago:
>
>
On Thu, Jun 18, 2020 at 8:11 AM Sérgio Basto wrote:
>
> Hi,
>
> Guideline page needing clarification:
> https://fedoraproject.org/wiki/EPEL:Packaging
>
> Explanation
>
> in this wiki page is not clear that on EPEL8 we don't need anymore the
> scriptlets of Icon Cache, mimeinfo and Desktop
I agree with Jeff.
It looks good, go for it.
On Thu, Jun 25, 2020 at 8:49 AM Jeff Sheltren wrote:
>
> Hi Jos, seems fine to me; I'd say go for it!
>
> -Jeff
>
> On Wed, Jun 24, 2020 at 12:58 PM Jos de Kloe wrote:
>>
>> Hi,
>>
>> I received a user request to update eccodes, see:
>>
The EPEL Guidelines and Policy[1] was recently revised to allow EPEL
modules to have the same packages as those in RHEL as long as the
module wasn't enabled by default, and the user had to specifically
enable that module and stream.
The updated policies allowed the modules to have both the same
Policies don't mean mistakes won't happen.
A mistake happened and
A) We are trying to clean it up as soon as possible [1]
B) We are trying to work with mbs and infrastructure to make sure this
can't happen in the future.
I'm sorry this is so short on details, but I need to either write a
short
Hi Felix,
I wasn't offended by your tone. I felt the same way when I saw this on Friday.
Although dnf sees these as two different modules, since they have same
name and stream, dnf lumps them together. When that happens, dnf uses
the packages with the highest Name-Version-Release (NVR). In
On Mon, Jun 15, 2020 at 8:21 PM Sérgio Basto wrote:
>
> On Mon, 2020-06-15 at 10:04 -0700, Troy Dawson wrote:
> > RHEL 8.2 and CentOS 8.2 have an updated qt5. This updated qt5
> > allowed
> > us to update the KDE Plasma Desktop in EPEL8. We are not at the
> > f
On Fri, Jun 19, 2020 at 11:20 AM Miro Hrončok wrote:
>
> On 19. 06. 20 16:03, Troy Dawson wrote:
> > Hi Miro,
> > I was hoping someone more python oriented would look at this, but I
> > guess that isn't happening.
> > I'll take a look at it later today.
>
>
in System Settings.
https://bugzilla.redhat.com/show_bug.cgi?id=1838801
Help resolving this bug would be appreciated.
It is irritating, but not critical.
Many thanks to all who helped with this.
Troy Dawson
[1] plasma-nm is currently at 5.15. This has been verified to work.
We will hopefully be able
On Wed, Jun 3, 2020 at 10:08 PM Sérgio Basto wrote:
>
> On Wed, 2020-06-03 at 20:49 -0700, Kevin Fenzi wrote:
> > On Wed, Jun 03, 2020 at 07:13:06AM -0700, Troy Dawson wrote:
> > > On Tue, Jun 2, 2020 at 8:14 AM Felix Schwarz <
> > > fschw...@fedoraproject.org>
Often the answer is yes. It will not come out until the next point
release. In this case 8.3. Those come out every six months.
Depending on the bug, it's possible that it will come out in the .1
release. In this case 8.2.1. Those come out every three months.
If there is a new feature (blah
Hi Stephen,
Just want to say thank you to you, or whoever got this working again.
I am able to build on koji again for EPEL. At least EPEL8.
On Sun, Jun 7, 2020 at 7:23 AM Stephen John Smoogen wrote:
>
>
> We are in the middle of the datacentre move where various services are
> partially in
On Tue, Jun 2, 2020 at 8:14 AM Felix Schwarz wrote:
>
>
> Am 01.06.20 um 17:25 schrieb Troy Dawson:
> > I was having a similar problem last week, I opened a
> > fed-infrastructure ticket and they extended the time out time. But it
> > looks like things have gotten so
If you (or others) haven't already done so, a bugzilla requesting an
update might be best.
Many times packagers aren't on the epel-devel mailing list, and/or
have it filtered.
On Fri, Jun 5, 2020 at 2:22 AM Menanteau wrote:
>
> Hi there,
>
> is there a plan to update Mate in EPEL ?
>
> There was
and then
python3 will-it-install.py x86_64 centos
You can do any of the 4 RHEL arches.
Feedback is appreciated.
Troy Dawson
[1] -
https://github.com/tdawson/tdawson-misc-scripts/tree/master/will-it-install
[2] - git clone https://github.com/tdawson/tdawson-misc-scripts.git ;
cd tdawson-misc
This script will work on RHEL/CentOS 8 and any of the currently
supported Fedora releases.
I do not expect it to work on RHEL7
On Fri, Jul 24, 2020 at 4:13 PM Troy Dawson wrote:
>
> Hi,
> As discussed in the EPEL Steering Committee meeting, I made a python
> script, will-it-in
It is best to open a bugzilla bugs for questions like this.
Each EPEL package is maintained by it's own packager. (Although many
packagers have hundred of packages) And not all packagers are
subscribed to the EPEL mailing list.
In this case, this has already been requested / asked.
On Fri, Dec 4, 2020 at 8:08 AM Antonio T. sagitter
wrote:
>
> Hi all.
>
> Why openblas-0.3.5 is waiting for stable branch since 2 years? [1]
>
> Is it reasonable, taking into account the rebuilds of dependent
> packages, to rebuild openblas on epel7 by using a more recent GCC
> version like GCC-8
t I read earlier in the day. If someone else has a
better description, feel free to chime in.
Troy Dawson
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Co
On Wed, Dec 9, 2020 at 2:19 AM Miro Hrončok wrote:
>
> Hello,
>
> wrt https://blog.centos.org/2020/12/future-is-centos-stream/
>
> Since EPEL 8 is for RHEL 8 and EPEL Next 8 is for CentOS Stream 8, I assumed
> we
> will continue to use CentOS Linux 8 for local mock (and Copr) builds of EPEL 8
>
I just tested on my laptop running CentOS 8. Updated to 8.3 and both
X and KDE started up with no problems.
Do you have something special like an nvidia card with drivers?
On Wed, Dec 9, 2020 at 8:29 AM Orion Poplawski wrote:
>
> After updating to CentOS 8.3, my plasma (KDE) desktop is not
On Fri, Dec 11, 2020 at 1:44 PM Miro Hrončok wrote:
>
> On 12/11/20 7:42 PM, Troy Dawson wrote:
> > Our current solution for the missing RHEL8 devel packages is going away.
> > And let's be honest, it was only about 50% successful. We needed
> > something else anyway.
>
On Tue, Dec 15, 2020 at 5:06 AM Andrew C Aitchison
wrote:
>
> On Tue, 15 Dec 2020, Miro Hrončok wrote:
>
> > On 12/13/20 7:52 PM, Andrew C Aitchison wrote:
> >>
> >> On Sun, 13 Dec 2020, Miro Hrončok wrote:
> >>
> >>> Also, since you might want to bump the release independently in EPEL (e.g.
>
Our current solution for the missing RHEL8 devel packages is going away.
And let's be honest, it was only about 50% successful. We needed
something else anyway.
Here is my proposal for a new solution.
Be warned, this proposal has words like module, and grobisplitter.
But I think it will turn out
EPEL 6 is End Of Life (EOL) on November 30 2020.
That is two weeks away
EPEL 6 will be moved to archives in the first week of December 2020.
That is three weeks away
EPEL Steering Committee
___
epel-devel mailing list --
[root@centos7 ~]# g++ -dumpversion
4.8.5
[root@centos7 ~]# g++ -dumpfullversion
g++: fatal error: no input files
compilation terminated.
[root@centos7 ~]# rpm -qf /usr/bin/g++
gcc-c++-4.8.5-44.el7.x86_64
On Mon, Jan 4, 2021 at 7:20 AM José Abílio Matos wrote:
>
> Hi,
>
> last week I have
On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar wrote:
>
> On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
> > I think that could be workable, but I'll toss out another proposal:
> >
> > As soon as centos 9 stream exists, we create epel9-playground and allow
> > people to branch/add
As we are getting closer to the F34 branching, which means we are
getting closer to CentOS 9 Stream, which will eventually be turned
into RHEL9 Beta, and then RHEL9 release. Now seems like a good time
to get ideas flowing about EPEL9.
I'm just throwing ideas around. Nothing I'm saying here is
On Wed, Feb 3, 2021 at 3:16 AM john tatt wrote:
>
> Hi
> So if I understand well, an EPEL package could be have to be desinstalled
> just because an update in Stream make it not compatible any more ?
> Strange
>
Yes and no
Yes - If you are running CentOS Stream, and don't have the epel-next
Packages are not automatically branched for each EPEL version. Each package
must be branched by a packager for each particular release, and packagers
may or may not be interested in EPEL-8 while they were interested in
EPEL-7.[1]
The preferred method of asking a maintainer for an EPEL branch is
It isn't just EPEL, I see this on all the calendar reminders I get from
Fedora. I wonder if there are two instances of the app running.
Does anyone know the right place to file a bug for this?
On Tue, Jun 8, 2021 at 11:48 AM Andrew C Aitchison
wrote:
>
> I get two copies of the steering
On Mon, Jun 7, 2021 at 7:01 AM john tatt wrote:
> Hi everyone,
>
> I'm wondering about what will happen next about EPEL:
>
> I mean: will Epel follow Centos Stream and in this case not surely be
> compatible with RHEL 8 ?, or
>
> will Epel continue to be fully compatible with RHEL 8 and in this
On Tue, Jun 22, 2021 at 4:49 PM Miro Hrončok wrote:
> On 23. 06. 21 0:31, Kevin Fenzi wrote:
> > Outside of that on the technical side... if these are from stream they
> > might not always work for base epel would they?
>
> I think that if we don't download the latest version from Stream, but
I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the
updated qt5 that is there. I am using what is in F34 for the update.
I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the
buildroot.
For libksysguard I believe I have all other dependencies built and in the
On Tue, Jun 22, 2021 at 2:53 PM Troy Dawson wrote:
> Someone brought this proposal to me, I'd like to get others feedback.
>
> Proposal:
> EPEL would make its own "devel" repo, with the missing RHEL packages,
> grabbing the packages from the publicly available cento
On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz
wrote:
> On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote:
> > I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the
> > updated qt5 that is there. I am using what is in F34 for the update.
> > I've g
are the odds that the package will
make it into RHEL 8 CRB?
Thanks
Troy Dawson
[1] -
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
[2] - https
On Thu, Jun 24, 2021 at 8:31 PM Yaakov Selkowitz
wrote:
> On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote:
> > On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz
> > wrote:
> >
> > > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote:
> > > > I
On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen
wrote:
>
>
> On Mon, 17 May 2021 at 18:14, Kevin Fenzi wrote:
>
>> On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
>> >
>> >
>> > On 17/05/2021 19:32, Kevin Fenzi wrote:
>> > > roundcubemail in epel7 is very old at this point,
It's looking like the general answer is, nobody on this list knows.
It's quite possible that the package maintainer isn't on this list, or has
it filtered off.
If you haven't already found the answer, I suggest opening a bug.
Troy
On Fri, May 7, 2021 at 9:05 AM wrote:
> Hi,
>
> I have a fully
On Tue, May 18, 2021 at 10:08 PM Pavel Raiskup wrote:
> On Wednesday, May 19, 2021 1:57:17 AM CEST Leon Fauster wrote:
> > Dear all, the EPEL build target in COPR build packages based on
> > CentOS Linux 8. What happens at EOL of CentOS Linux 8? Any clues?
>
> Copr just uses `mock-core-configs`
On Tue, May 11, 2021 at 2:02 PM Kevin Fenzi wrote:
> On Tue, May 11, 2021 at 09:35:40PM +0200, Leon Fauster wrote:
> > On 11.05.21 14:02, Christoph Karl wrote:
> > > Hi!
> > >
> > > On 11.05.21 at 12:30 Leon Fauster wrote:
> > > > While reading this I noticed that the recent fluidsynth-libs
Just so people know, you are running CentOS Stream 8, not regular CentOS 8.
CentOS Stream 8 has updated qt5 to qt5-5.15. It was originally 5.12.
Thus, when RHEL 8.5 comes out, it will also have qt5-5.15.
I wrote about this a couple weeks ago.[1]
But to summarize, this is a known problem with
- The last KDE Plasma Desktop update in EPEL8 was a year ago, when RHEL 8.2
was released and they bumped qt5 to qt5-5.12.
- If you look at CentOS Stream 8, you will notice that it now has
qt5-5.15. I have verified that qt5-5.15 is supposed to come out with RHEL
8.5. That is six months from now.
On Tue, Jun 1, 2021 at 10:11 AM Matthew Miller
wrote:
> On Tue, Jun 01, 2021 at 08:29:17AM -0400, Trey Dockendorf wrote:
> > I have opened a bugzilla to get an EPEL8 branch for pdsh [1], and I've
> also
> > reached out to the current maintainers directly and have not heard
> anything
> > back.
Looks like the seamonkey you want is still in epel7-testing.
There was an aom update, and it made it through testing, so it's currently
in epel7.
There was also a seamonkey update, to pull in the updated aom. But it's
still in epel7-testing.
For now, the easiest thing to do is enable
On Thu, Jul 8, 2021 at 1:20 AM Petr Pisar wrote:
> V Wed, Jul 07, 2021 at 06:33:51PM -0700, Michel Alexandre Salim napsal(a):
> > I'm working on a tool to make it easier to create EPEL branch requests
> > in the case where there are transitive dependencies that also need to
> > be branched.
> >
On Thu, Jul 8, 2021 at 7:51 AM Mohan Boddu wrote:
> On Thu, Jul 8, 2021 at 9:58 AM Neal Gompa wrote:
> >
> > On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi wrote:
> > >
> > > On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> > > >
> > > > This is very exciting!
> > > >
> > > > However,
On Fri, Jun 25, 2021 at 2:02 PM Josh Boyer wrote:
> On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson wrote:
> >
> > During our last round of proposals for solutions to missing devel
> packages, it was noted that EPEL and CentOS has very different
> documentation for reques
I believe this is a recommendation, versus a policy.
I wanted to get people's thoughts on it, and if ya'll like it, put it in
the documentation.
In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
packages that are built from RHEL spec files. This will also be true of
RHEL
You would need to make an "openldap-servers" package.
It could be the exact same everything as openldap from RHEL, just a
different name, and without the openldap and openldap-clients binary
packages.
Or, if you want, you could use the Fedora version. As far as I know, the
server and client don't
On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi wrote:
>
> On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > There is a little nuance here. In order to get the repository going, we had
> > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > require quite
(currently EDT)
Location: IRC - #fedora-meeting
To find out that time for you:
date -d "Wed 1600 EDT"
I'll talk to you all tomorrow.
Troy Dawson
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epe
Hi Felix,
First off, thank you for maintaining the EPEL7 nginx, especially when you
no longer use it on EPEL7.
To me, it looks like you have addressed everything you should in the email,
and there shouldn't be anything else you need to do.
That being said, I've missed things before so maybe give
a epel9-next package
on epel9, or possibly maintaining a package when the Fedora packager
does not want to do EPEL.
- More details will be coming, but we hope the SIG will help get alot
of the most used EPEL packages into EPEL9 as soon as possible.
Troy Dawson
__
I thought I'd already taken those out of comps. So yes, I'm ok with this.
Most of those are either qt4 based, or based on a RHEL8 missing devel,
so cannot be built at this time.
Maybe this just needs to be rebased, but there are alot of other
changes in this, dealing with xfce.
Can those be
On Fri, Feb 19, 2021 at 5:18 AM Gerard Braad wrote:
>
> Hello Sven Lankes,
>
>
> I am using CentOS8 and am using various packages in the EPEL
> repository. I am interested in seeing 'daemonize' [0] added to EPEL.
>
> Would it be possible for you to maintain the package in EPEL? If not
> do you
It's almost a year to the day when we last started the search for a
new time for the EPEL Steering Committee meeting.
I have created a new framadate poll with times extreme for both U.S.
and Europe. All the times are in UTC. To see what they are in your
timezone do
date -d "1300 UTC"
date -d
On Sat, Feb 20, 2021 at 9:30 AM Neal Gompa wrote:
>
> On Sat, Feb 20, 2021 at 6:27 AM Pablo Sebastián Greco
> wrote:
> >
> > Last time we did the voting in UTC, and ended up adapting it to DST in the
> > US. Do you think we'll repeat it this time?
> >
>
> Yeah, we will. Most of us attending the
the help.
>
> Kind regards.
>
> Enrico
>
> On Fri, Aug 20, 2021 at 5:11 PM Leon Fauster
> wrote:
>
>> On 20.08.21 16:42, Troy Dawson wrote:
>>
>> > epel has epel-next that is compatible with CentOS Stream.
>> > https://fedoraproject.org/wiki/EPEL_
stallable in CentOS Stream,
that is currently lower in priority to getting epel9-next out. Since EPEL
is 100% volunteer driven, some things take more time to implement.
Again, thank you for the bug, it helps.
Troy Dawson
___
epel-devel
On Fri, Aug 20, 2021 at 8:12 AM Leon Fauster
wrote:
> On 20.08.21 16:42, Troy Dawson wrote:
>
> > epel has epel-next that is compatible with CentOS Stream.
> > https://fedoraproject.org/wiki/EPEL_Next
> > <https://fedoraproject.org/wiki/EPEL_Next>
>
>
I have ported the EPEL wiki pages that I know about to my fork of EPEL in
pagure[1]. Except for a few FAQ questions that were horribly out of date,
I didn't change anything other than formatting.
Can people look at the pages and let me know
A) Am I missing any wiki pages?
B) Do I have any wiki
On Mon, Aug 23, 2021 at 6:41 PM Orion Poplawski wrote:
> The "zabbix" package exists in EPEL8 in two forms:
>
> zabbix40 - non-module 4.0 package.
> zabbix - module with 5.0 stream.
>
> Because the "zabbix" dist-git does not have a epel8 branch, there is no
> "zabbix" component in bugzilla for
We are pleased to announce that Red Hat is establishing a small team
directly responsible for participating in EPEL activities. Their job
isn't to displace the EPEL community, but rather to support it
full-time. We expect many beneficial effects, among those better EPEL
readiness for a RHEL major
EPEL Next[1][2] is meant for machines running CentOS Stream.
We currently have epel8-next, and are working on getting epel9-next setup
so that maintainers can build on it.
Technically epel9-next will be a "Pre-Release" of epel9, but saying it is a
"pre-release" implies that it will go away.
201 - 300 of 518 matches
Mail list logo
