[EPEL-devel] Re: libmaxminddb removed from epel7

[Dan Horák]

On Tue, 03 Jan 2023 11:12:02 -
"Sebastian Albrecht"  wrote:

> Hi friends
> i am using the epel(7) repo in Amazon Linux 2 and since two weeks ago the 
> package libmaxminddb disappeared. Is this the right place to ask for why it 
> was removed from the repository. Is there some kind of a removal announcement 
> / change history list?

I believe it was removed from EPEL-7, because it's available in RHEL-7,
added in 7.7 if I see right.


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] Re: claws-mail for EPEL-9

[Dan Horák]

On Tue, 13 Dec 2022 19:09:48 +0100
Dan Horák  wrote:

> On Tue, 13 Dec 2022 09:56:40 -0800
> Troy Dawson  wrote:
> 
> > 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/
> 
> yeah, I know the process :-) It is an attempt to avoid duplication of
> efforts in case someone else has been looking into it earlier or if I
> should start opening the bugs.

and for the record, here we go -
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-228fbb434d


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] Re: claws-mail for EPEL-9

[Dan Horák]

On Tue, 13 Dec 2022 09:56:40 -0800
Troy Dawson  wrote:

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

yeah, I know the process :-) It is an attempt to avoid duplication of
efforts in case someone else has been looking into it earlier or if I
should start opening the bugs.


Dan
 
> 
> 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] claws-mail for EPEL-9

[Dan Horák]

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] Re: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Dan Horák]

On Wed, 11 May 2022 08:16:10 -0700
Troy Dawson  wrote:

> EPEL8 on CentOS Stream 8 (epel8-next)
> We have rebuilt as many packages as we can.  We still cannot build
> qt5-qtwebengine, and thus any packages that depend on it.
> - qt5-qtwebengine
> -- The python27 module has been fixed, and you can now build packages that
> require python2 on epel8-next.
> -- qt5-qtwebengine builds fine on x86_64, but failed on aarch64
> --- Any help would be appreciated.
> --- https://kojipkgs.fedoraproject.org//work/tasks/6819/86886819/build.log
> --- We tried rebuilding the older qt5-qtwebengine, same errors.
> --- We tried the older gcc, again, same errors.
> --- Still working on it, but if you recognize the errors in the buildlog,
> let us (me) know.

it's an internal g++ error, it even creates preprocessed sources to be
included in the bug report. I think we should file bug against RHEL-8
gcc, if not done yet. Even if the guys won't fix it immediately, they
can provide some workaround on the source code level. If needed I can
grab the file from the builder.


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Z architecture support in Fedora Copr

[Dan Horák]

On Tue, 18 Jan 2022 15:22:02 +0100
Pavel Raiskup  wrote:

> Hello maintainers!
> 
> I'm glad to announce that the native s390x builders are now available in
> Fedora Copr production.
> 
> Seems everything works, so we also added the 'epel-8-s390x' and 'epel-9-s390x'
> chroots.
> 
> Note that the builders are hosted in IBM Cloud, Tokyo, so the connectivity
> between builder and the rest of the Copr stack (North Virginia) might be a
> bit slower (or behave differently).  Ditto for RPM repositories that are
> not mirrored.  Overall, this is an early attempt so please be patient and
> report issues: https://pagure.io/copr/copr/issues

thanks to everyone involved, it's a good news and big milestone


Dan
 
> Happy building!
> Pavel
> 
> On Monday, January 17, 2022 2:18:04 PM CET Pavel Raiskup wrote:
> > Hello all!
> > 
> > Red Hat subscribed builders (for EPEL 8) have been deployed to production.
> > So any EPEL 8 build in Fedora Copr is now done against RHEL 8 + EPEL 8.  As
> > always, please report back any issues.
> > 
> > There's though some problem related to the s390x native builders.  Please
> > stay tuned on that part...  For now, s390x stays emulated (and as I noticed
> > later after the announcement, we haven't enabled the epel-8-s390x chroot,
> > yet - so there's no regression at least).  I hope these issues will be
> > resolved by the end of the week.
> > 
> > Happy building,
> > Pavel
> > 
> > On Monday, January 10, 2022 11:22:03 AM CET Pavel Raiskup wrote:
> > > Hello maintainers.
> > > 
> > > Currently, we build all EPEL variants against CentOS "base" in Fedora
> > > Copr, i.e.  epel-* configs means CentOS+EPEL.  By the end of January 2022
> > > CentOS 8 mirrors will start disappearing, pushing us to change the configs
> > > to avoid build failures.
> > > 
> > > We would like to start the migration to the RHEL base as soon as possible,
> > > so we are at least a bit "ahead" the change.  So we can start resolving
> > > the issues.
> > > 
> > > There doesn't seem to be a real blocker, or known issue.
> > > 
> > >   - We got enough subscriptions from Red Hat for Fedora Copr purposes to
> > > start building against official RHEL channels.
> > > 
> > >   - The Mock + configs is stuck in Bodhi for now, but it doesn't block
> > > Copr to apply for the change earlier.  This is mostly about community
> > > decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
> > > broken.
> > > 
> > >   - The remaining problem seemed to be the s390x architecture, as the
> > > emulation being _currently_ done wouldn't work with Red Hat
> > > subscriptions, see details in [1] discussion.  But thanks to IBM
> > > sponsoring us IBM Cloud access we should be OK to deploy the s390x
> > > arch support in Fedora Copr at the same time with the EPEL change
> > > (this will go in a separate announcement).
> > > 
> > > **So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.**  If
> > > everything works well at least.
> > > 
> > > Side note from me...  Note that EPEL 9 in Fedora Copr is still CentOS
> > > Stream 9 + EPEL 9 ATM.  This will change to "RHEL 9 + EPEL 9" once RHEL 9
> > > is generally available (subscribed content).  Might seem as a
> > > complication for users, but it's actually not - it is good thing we can
> > > start working on EPEL 9 now.  So I want to congratulate to EPEL community
> > > here, the fact we have stream in place allows us to bring EPEL 9 up before
> > > actually RHEL is available.  That's an awesome step (jump) forward
> > > compared to previous releases!
> > > 
> > > [1] 
> > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/
> > > 
> > > Pavel
> > > 
> > 
> > 
> 
> 
> 
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Getting conman into EPEL8

[Dan Horák]

On Tue, 13 Apr 2021 11:27:08 -0400
Trey Dockendorf  wrote:

> On Tue, Apr 13, 2021 at 10:41 AM Dan Horák  wrote:
> 
> > >
> > > I have Fedora accounts that I setup many years ago and honestly don't
> > > recall if I was ever setup to be a packager for Fedora. If there is a way
> > > to verify if I am setup as a packager I'd be happy to check, but most
> > > likely I am not a packager in Fedora.
> >
> > that's a problem we can fix :-) New maintainers are always welcome.
> >
> >
> > Dan
> >
> >
> Would the best place to start be here?
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers. Any
> pointers or additional information to get started on eventually becoming
> EPEL8 conman maintainer is appreciated.

please check also your spam folder, but the above link is generally a
good start. For co-maintainers there is a short-cut possible.


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Getting conman into EPEL8

[Dan Horák]

On Tue, 13 Apr 2021 10:31:42 -0400
Trey Dockendorf  wrote:

> On Tue, Apr 13, 2021 at 10:25 AM Dan Horák  wrote:
> 
> > Hi Trey,
> >
> > On Tue, 13 Apr 2021 14:15:08 -
> > treyd...@gmail.com wrote:
> >
> > > It appears like RHEL8 dropped conman RPMs but they do exist in Fedora
> > and appear to be receiving updates.  I found a wiki page that said to
> > contact the maintainers via email but I was unable to find the emails
> > associated with the maintainers so I opened a bugzilla but wasn't sure if I
> > did this bugzilla in appropriate place:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1947480
> > >
> > > I'd be happy to become the maintainer of conman for EPEL8 if that would
> > help get conman RPMs into EPEL8.  Any pointers on how to go about getting
> > conman into EPEL8 would be appreciated, in case the current approach I took
> > is incorrect.
> >
> > sorry for not replying earlier, but if you are willing to maintain
> > conman in EPEL, then the process should be fast. Are you already a
> > packager in Fedora?
> >
> >
> > Dan
> > ___
> >
> 
> I have Fedora accounts that I setup many years ago and honestly don't
> recall if I was ever setup to be a packager for Fedora. If there is a way
> to verify if I am setup as a packager I'd be happy to check, but most
> likely I am not a packager in Fedora.

that's a problem we can fix :-) New maintainers are always welcome.


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Getting conman into EPEL8

[Dan Horák]

Hi Trey,

On Tue, 13 Apr 2021 14:15:08 -
treyd...@gmail.com wrote:

> It appears like RHEL8 dropped conman RPMs but they do exist in Fedora and 
> appear to be receiving updates.  I found a wiki page that said to contact the 
> maintainers via email but I was unable to find the emails associated with the 
> maintainers so I opened a bugzilla but wasn't sure if I did this bugzilla in 
> appropriate place: https://bugzilla.redhat.com/show_bug.cgi?id=1947480
> 
> I'd be happy to become the maintainer of conman for EPEL8 if that would help 
> get conman RPMs into EPEL8.  Any pointers on how to go about getting conman 
> into EPEL8 would be appreciated, in case the current approach I took is 
> incorrect.

sorry for not replying earlier, but if you are willing to maintain
conman in EPEL, then the process should be fast. Are you already a
packager in Fedora?


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

[Dan Horák]

On Thu, 16 May 2019 10:31:48 -0400
Stephen John Smoogen  wrote:

> On Thu, 16 May 2019 at 09:48, Dan Horák  wrote:
> 
> > On Wed, 15 May 2019 18:06:21 -0400
> > Stephen John Smoogen  wrote:
> >
> > > In trying to get resources allocated, I have been working on the
> > > project plans for 8. The original one was at
> > > https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
> > >
> > > As of today an updated one is at
> > >
> > > https://smooge.fedorapeople.org/EPEL-8/
> >
> > is there a plan to start EPEL-8 with all arches supported by
> > RHEL-8? So s390x will be also included? We never bootstrapped
> > EPEL-7 for s390x, but it wasn't a blocker because there is a
> > rebuild available from the ClefOS people (they do a CentOS rebuild
> > for s390x). We are registering questions about availability of EPEL
> > for s390x quite regularly.
> >
> >
> It will depend on the resources available for s390x. Currently all
> s390x builds are done on a system shared with other builds which is
> severely overloaded. Adding more build targets needs to be weighed
> with 'can we do it without breaking our house of cards anymore'. If
> more resources are available or other changes, it will be seriously
> looked at. [I have downloaded RHEL-8 s390x just in case.]

BTW do we know how much load does EPEL generate in koji? 1% or 10 % or
30%? It should be just regular builds and composes for updates, but no
images or appliances, no modules.


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)

[Dan Horák]

On Wed, 15 May 2019 18:06:21 -0400
Stephen John Smoogen  wrote:

> In trying to get resources allocated, I have been working on the
> project plans for 8. The original one was at
> https://fedoraproject.org/wiki/Infrastructure_2020/EPEL-8
> 
> As of today an updated one is at
> 
> https://smooge.fedorapeople.org/EPEL-8/
 
is there a plan to start EPEL-8 with all arches supported by RHEL-8? So
s390x will be also included? We never bootstrapped EPEL-7 for s390x, but
it wasn't a blocker because there is a rebuild available from the ClefOS
people (they do a CentOS rebuild for s390x). We are registering
questions about availability of EPEL for s390x quite regularly.


Thanks

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel]Re: Boostrapping a new architecture for EPEL

[Dan Horák]

On Wed, 25 Nov 2015 15:25:21 +
Peter Robinson  wrote:

> Hi All,
> 
> So it's been discussed a little about doing a EPEL bootstrap for new
> architectures. We have a number of arches wanting to do this (ppc64le,
> aarch64, i686, s390x). So ppc64le will be our first and this is an
> overview of the process I'll be using to do it. Once it's complete
> I'll do a better write up as I suspect some things will evolve as we
> go on down the path.
> 
> So the general overview of the process is:
> 
> 1) add new builders to koji (ppc64le complete)
> 2) create separate inherited build target and tag
> (epel7-archbootstrap) with associated architecture
> 3) run scratch builds in that target using the git commit hashes from
> the latest builds in the epel7, epel7-testing and epel7-candidate tags
> 4) For each scratch build completed, run mergeScratch(task_id)
> 5) when all builds are complete enable the arch on the main epel7
> target
> 6) sign all new packages
> 7) update bodhi, pkgdb, mash configs
> 7) mirror out
> 
> I have some scripts to do the above which I'll publish for reference
> once I've cleaned them up a little.
> 
> This process isn't perfect. The new arch builds may not have the exact
> same build dependency NVRs because, at least in the case of ppc64le,
> the first EL7 release with .el7 distags is 7.2 and obviously most of
> epel7 is built against < 7.2. The mergeScratch koji API call imports
> all the build logs which helps mitigate this from a debug PoV. There's
> not really a good way to deal with this, and obviously once the new
> arch is enabled they'll be the same moving forward. I don't see it as
> an issue really, just making note of it here for reference.
> 
> Looking at the current stable epel7 builds, as of a couple of days
> ago, we have around 4763 source packages, of which 2686 are noarch
> (and hence don't need to be rebuilt) and a touch under 2077 (2077 at
> time of check) are arch dependent.
> 
> Let me know of any queries, questions, concerns etc

sounds sane :-) But how will be handled packages that require some
boostrapping procedure - is a new combo of boostrap and final build
required in existing EPEL (dist-git) or or will be the bootstrap build
taken from the original EPEL bootstrap (built eg. against RHEL-7 Beta)
and the current latest NVR will be then the final build?


Dan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Dealing with cyclic dependencies

[Dan Horák]

On Thu, 10 Sep 2015 03:00:17 -0400
"Bryan Chan" <bryan.c...@ca.ibm.com> wrote:

> 
> Dan Horák <d...@danny.cz> wrote on 2015-09-08 01:56:54 PM:
> 
> > Often those packages contain a "bootstrap" macro that can be set to
> > 1 for an initial build with limited dependencies and to 0 for
> > production build. And for building for EPEL there should be a older
> > build (source rpm) available (because it had to bootstrapped also
> > for regular EPEL), so first rebuild this, and then the latest, or
> > next or whatever is necessary. The changelog in the spec files
> > and/or history in dist-git will show the details about the versions.
> >
> > Do you have a list of those problematic builds?
> 
> Hi Dan, thanks for the suggestion. My team mate has found a similar
> bootstrap macro in the ghc packages and is trying it out now.

for ghc specifically I would recommend to contact Jens Petersen (juhp
on #fedora-devel IRC) directly, he is the ghc maintainer in Fedora and
knows best all the weirdness in ghc packaging.

> I asked the person who did the original runs back in June but he
> doesn't remember where the circular dependencies came from. He
> thought it might be some Python- or Perl-related dependencies in a %
> test section of a package but he isn't sure. We will watch out for
> the issue and report if we see it again.

yeah, tests in perl-* are possible candidate, let us know and I guess we
can help


Dan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL RHEL 7 Workstation optional channel in Fedora's Koji

[Dan Horák]

On Mon, 2 Jun 2014 10:59:48 +0200
Simone Caronni negativ...@gmail.com wrote:

 Hello,
 
 I was looking to build a package on epel7 that is relying on
 jansson-devel.
 
 The -devel subpackage is generated as normally from the main jansson
 package, but in case of epel7 the resulting rpm is included in the
 Workstation-optional channel:
 
 http://ftp.redhat.com/redhat/rhel/rc/7/Workstation-optional/x86_64/os/Packages/
 
 Have these packages being left out intentionally or not?
 Is there any chance to see these packages added in Koji? Otherwise
 building for epel7 can get really complicated.

EPEL builds against the Server + Server-optional variant of RHEL -
http://koji.fedoraproject.org/koji/taginfo?tagID=258


Dan
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel