[EPEL-devel] Re: Regarding clang support in epel7

[Dave Johansen]

This has been asked for several times but the existing version is the last
that will build without C++11 support. There are existing COPR repos with
newer versions of clang that are built against devtoolset, so I would
recommend using one of those.

On Fri, May 19, 2017 at 12:35 PM, Dhruv Paranjape 
wrote:

> I was looking around and I don't see clang on pkgdb for epel 7.
>
> The current version is way too outdated and was wondering if the current
> maintainers could maybe bump up the version ?
>
> Regards,
> Dhruv
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Wed, 24 Aug 2016 21:59:55 -0600
> Dave Johansen <davejohan...@gmail.com> wrote:
>
> > I agree that how to handle SCLs can get really mess really fast, but
> > a lot of projects are jumping on the "modern C++" bandwagon and
> > allows devtoolset is low risk, easy to do and enables a lot of
> > packages to be built with EPEL that otherwise wouldn't be.
>
> It would be low risk if that was the only SCL in the repo.
> My understanding is that they are all there in the one repo, so if we
> enable that, everyone could start using anything thats in there.
>

They're each in their own repo and I would propose adding devtoolset only
in repos used by mock during build time.

On Thu, Aug 25, 2016 at 2:40 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Thu, 25 Aug 2016 12:52:46 -0400
> Stephen John Smoogen <smo...@gmail.com> wrote:
>
> > On 25 August 2016 at 02:14, dani <d...@letai.org.il> wrote:
> > > When I proposed importing gcc-5 to EPEL6 back in 04/2016 (
> > > https://lists.fedoraproject.org/archives/list/epel-devel@
> lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/
> > > ) the response was an unequivocal no, EPEL does not install
> > > to /opt/ , so it dies right there.
> > >
> > > Now you are proposing the same ( devtoolset/scl installs to /opt
> > > except for the wrapper call) but using a scheme that is somewhat
> > > less convenient (In scl the binutils and gcc have to be coupled,
> > > and as noted the imported gcc suite is incomplete), much less
> > > frequent (the most updated version is gcc-5.2, while I maintain
> > > both gcc-5.x and gcc-6.1), and much less complete (I import
> > > everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ and
> > > gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs
> > > (cilk, gccjit, atomic, asan etc...).
> > >
> > > I'm still building and maintaining both gcc and bintutils for my own
> > > purposes, which are based off of fc24 srpms, and with optionally
> > > gcc-c++ specs file hardcoded to use binutils tools at the new
> > > prefix so use of env-modules is not required.
> > >
> > > I'm just wandering why the different treatment - the automatic
> > > knee-jerk reaction of dismissal to a newbie proposal vs. accepting
> > > the exact same proposal (although wrapped so it's less convenient
> > > to use) when it comes from someone else.
> > >
> >
> > You are misreading both responses. There is no knee-jerk acceptance
> > and there wasn't a knee jerk dismissal because you were a newbie.
> > Please don't find malice where none was intended.
>
> What smooge said. ;)
>
> The reason SCL's are under opt is that they got a namespace approved
> for that purpose:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#
> Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt
>
> "Currently, we have allocated /opt/fedora/scls, /etc/opt/fedora/scls,
> and /var/opt/fedora/scls for use by Software Collections. "
>
> Perhaps you could explain exactly what you want to propose here again?
> Just epel6? or 7 as well? Do you have co-maintainers in case you get
> busy, etc?
>
> I think we are all open to ideas how to do things better, but it's
> really not clear what is best or even exactly what is proposed. ;)


Here's one proposal:
1) Add version X of devtoolset only in repos used by mock
2) N months (maybe 6?) before version X is EOLed, make version X+1 (or
whatever the latest is) available in a buildroot override (or something
similar) for testing
3) Rebuild all packages that use devtoolset using version X+1 and make
available for testing
4) After testing period (maybe 1 month? or 3 months?), upgrade to version
X+1 and move all rebuilt packages from testing repos to main repos

Or here's another option:
1) Add all non-EOLed versions of devtoolset only in repos used by mock
2) N months (at least 6) before version X is EOLed require that it be
rebuilt with a newer version of devtoolset
3) If it's not rebuilt before the EOL happens, then retire the package

I like the second option better, because it's easier to setup/maintain from
a mock/koji perspective, provides flexibility and doesn't force a mass
rebuild/test every 12-18 months when a devtoolset is retired (their life
cycle is 2 years). However, it also means that the update is decentralized
and depends on maintainers rather an an automated system.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Wed, 24 Aug 2016 16:43:31 -0600
> Dave Johansen <davejohan...@gmail.com> wrote:
>
> > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> >
> > > On Tue, 23 Aug 2016 14:21:24 +0100
> > > Karanbir Singh <mail-li...@karan.org> wrote:
> > >
> > > > On 22/08/16 18:30, Jason L Tibbitts III wrote:
> > > > >>>>>> "DJ" == Dave Johansen <davejohan...@gmail.com> writes:
> > > > >
> > > > > DJ> devtoolset is designed to do all of this and is already
> > > > > DJ> done, so it seems that the only advantage to putting it in
> > > > > DJ> EPEL itself would be to reduce the number of repos during
> > > > > DJ> build time.
> > > > >
> > > > > So is devtoolset something I get access to as a CentOS user?
> > > > > How do I build these packages myself (i.e. in mock)?
> > > >
> > > > you should be able to 'yum install centos-release-scl' on a CentOS
> > > > Linux machine and get access to all the SCLs
> > >
> > > Yeah, but if we enable that for EPEL builds, we are going to get all
> > > SCLs right? So, people could start depending on them at runtime
> > > instead of just install time.
> > >
> > > I'm not opposed to devtoolset, but I don't think we want to allow
> > > runtime scls without actual scl guidelines.
> > >
> >
> > I seem to remember that Fedora didn't allow SCLs because there was
> > some compatibility problem or something of the sort. Do you know the
> > details or what the current state is?
>
> It's not a compatibility problem. It's lack of guidelines.
>
> > Also, RedHat has been pushing devtoolset pretty hard. The response to
> > a few bugzillas has even been "use devtoolset because the issue is
> > fixed there and we're not going to fix the system gcc/libc/etc". So
> > it seems like allowing SCLs in Fedora/EPEL makes sense and fits with
> > the direction of RHEL in general.
>
> As I noted, I'd probibly be for devtoolset because the guidelines would
> be pretty simple. Just do X Y and Z in your spec, build as normal and
> users wouldn't see any run time dep on it.
>
> It gets weird where other SCL's come in. Can your package require say
> postgresql from SCL instead of the rhel one? If so, would our users all
> be able to install that? What happens if two packages need different
> SCL versions? Can SCL's depend on each other? Can you make a package
> thats an SCL? we have no guidelines for that, and just saying "do
> whatever you want" is likely to cause mass confusion and make everyone
> miserable.
>

I agree that how to handle SCLs can get really mess really fast, but a lot
of projects are jumping on the "modern C++" bandwagon and allows devtoolset
is low risk, easy to do and enables a lot of packages to be built with EPEL
that otherwise wouldn't be.

Basically, I think that figuring out how to handle SCLs is a long term
issue that will take some serious work, but coming up with some simple
policies that allow it to be used in EPEL is something that should be well
within the realm of the possible.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On Tue, 23 Aug 2016 14:21:24 +0100
> Karanbir Singh <mail-li...@karan.org> wrote:
>
> > On 22/08/16 18:30, Jason L Tibbitts III wrote:
> > >>>>>> "DJ" == Dave Johansen <davejohan...@gmail.com> writes:
> > >
> > > DJ> devtoolset is designed to do all of this and is already done,
> > > DJ> so it seems that the only advantage to putting it in EPEL
> > > DJ> itself would be to reduce the number of repos during build
> > > DJ> time.
> > >
> > > So is devtoolset something I get access to as a CentOS user?  How
> > > do I build these packages myself (i.e. in mock)?
> >
> > you should be able to 'yum install centos-release-scl' on a CentOS
> > Linux machine and get access to all the SCLs
>
> Yeah, but if we enable that for EPEL builds, we are going to get all
> SCLs right? So, people could start depending on them at runtime instead
> of just install time.
>
> I'm not opposed to devtoolset, but I don't think we want to allow
> runtime scls without actual scl guidelines.
>

I seem to remember that Fedora didn't allow SCLs because there was some
compatibility problem or something of the sort. Do you know the details or
what the current state is?

Also, RedHat has been pushing devtoolset pretty hard. The response to a few
bugzillas has even been "use devtoolset because the issue is fixed there
and we're not going to fix the system gcc/libc/etc". So it seems like
allowing SCLs in Fedora/EPEL makes sense and fits with the direction of
RHEL in general.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: python34 for EPEL6

[Dave Johansen]

On Wed, Aug 24, 2016 at 3:38 PM, Orion Poplawski 
wrote:

> I have no idea if there is any interest in this or not.  I managed to get
> the
> EPEL7 python34 package to build on EL6 with a few modifications.  Is there
> any
> interest in supporting this?
>

How about using the Python SCLs?
https://www.softwarecollections.org/en/scls/?search=python3
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Mon, Aug 22, 2016 at 11:30 AM, Jason L Tibbitts III <ti...@math.uh.edu>
wrote:

> >>>>> "DJ" == Dave Johansen <davejohan...@gmail.com> writes:
>
> DJ> devtoolset is designed to do all of this and is already done, so it
> DJ> seems that the only advantage to putting it in EPEL itself would be
> DJ> to reduce the number of repos during build time.
>
> So is devtoolset something I get access to as a CentOS user?  How do I
> build these packages myself (i.e. in mock)?
>

The official version used to be behind a paywall, but there were builds by
CentOS and CERN. It's now been turned over to a SIG and is all open:
https://www.softwarecollections.org/en/scls/?search=devtoolset

Building just the compiler part isn't too bad, but building the IDE and
other parts of devtoolset takes some working out of the build order that I
never worked out because I only cared about the compiler:
https://www.redhat.com/archives/sclorg/2016-January/msg2.html

Here's a blog on building SCLs in mock:
http://developers.redhat.com/blog/2015/01/07/using-mock-to-build-python27-software-collections-packages-for-rhel6/

For building in COPR, I followed these instructions (but the main magic
point is editting each of the supported chroots to have "scl-utils-build
-build"):
https://www.redhat.com/archives/sclorg/2014-November/msg00015.html
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Tue, Aug 16, 2016 at 11:07 AM, Kevin Fenzi  wrote:

> On Mon, 15 Aug 2016 14:24:21 -0400
> Tom Callaway  wrote:
>
> > Recently, I've been participating in some discussion as to how to
> > enable C++11 support for EPEL builds. Specifically, R (and its large
> > universe of addons in CRAN) would benefit significantly from C++11
> > support.
> >
> > After much discussion, it seems like the only sane way to do this is
> > to use the Red Hat Developer Toolset (for el6 and el7). It is my
> > understanding that all RHEL customers (and CentOS users) should be
> > able to enable this repository without restrictions.
> >
> > I'd like to propose that we enable the Developer Toolset repo in EPEL
> > and allow packages to depend on it. Thoughts?
>
> So, this is a SCL of newer tools right?
>
> Does this result in a runtime dependency? Or just a build time one?
> ie, will everyone using packages built with this have to install it
> also, or it's just a buildrequires?
>

It's a BuildRequires only because any newer features from the compiler are
statically linked into the binary.
See other notes at the bottom of Section 2.3:
https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/2/html-single/2.1_Release_Notes/index.html#Known_Issues
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[Dave Johansen]

On Mon, Aug 15, 2016 at 12:24 PM, Tom Callaway  wrote:

> Recently, I've been participating in some discussion as to how to enable
> C++11 support for EPEL builds. Specifically, R (and its large universe
> of addons in CRAN) would benefit significantly from C++11 support.
>
> After much discussion, it seems like the only sane way to do this is to
> use the Red Hat Developer Toolset (for el6 and el7). It is my
> understanding that all RHEL customers (and CentOS users) should be able
> to enable this repository without restrictions.
>
> I'd like to propose that we enable the Developer Toolset repo in EPEL
> and allow packages to depend on it. Thoughts?
>

Previously, the big hold up was that it was at least partially behind a
paywall, but now that it's open and headed up by a SIG, I don't see any
reason why we shouldn't start benefit from using it. It might be nice to
have some rules or at least recommendations on which version to use and
there will need to be a policy when versions are EOLed, but maybe just an
automated set of rebuilds would be sufficient.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Import fedora gcc-5.3 in EPEL6

[Dave Johansen]

On Thu, Apr 21, 2016 at 3:50 AM,  wrote:

> Hello list,
>
> I've built an environment-modules based gcc-5.3.1 for RHEL6 that lives
> side-by-side with vendor packages - it installs to /opt/ and has a
> name{version} scheme to avoid conflicts, which I'd like to include in EPEL6.
>
> In accordance with the guidelines (
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Still_unsure_if_a_package_is_fine_for_EPEL.3F)
> I'm asking here if this is appropriate or, if not, how can I modify it so
> gcc-5 can make it into EPEL.
>
> I can provide a working srpm for both binutils2.26 and gcc5.3.1 (the
> binutils is required, and also builds to /opt and enabled via modules).
>

devtoolset 4 provides gcc 5.2 and is probably a more "standard" way to
accomplish what I believe you're aiming for.
https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/4/html-single/4.0_Release_Notes/index.html

Plus, it's already built and available for use:
http://mirror.centos.org/centos/6/sclo/x86_64/rh/devtoolset-4/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Upgrading QGIS to 2.14 in EL 7?

[Dave Johansen]

On Sat, Apr 9, 2016 at 3:17 PM, Dave Johansen <davejohan...@gmail.com>
wrote:

> On Thu, Apr 7, 2016 at 5:16 PM, ~Stack~ <i.am.st...@gmail.com> wrote:
>
>> On 04/07/2016 10:33 AM, Dave Johansen wrote:
>> > https://www.qgis.org/en/site/forusers/visualchangelog214/index.html
>> > QGIS has adopted a LTR model similar to Firefox and 2.14 is the new LTR.
>> > I've considered doing what RedHat does with Firefox and updating the
>> > version of QGIS in EPEL with LTR releases. What is everyone's thoughts
>> > on that?
>> > Thanks,
>> > Dave
>>
>> Yes please!! :-)
>>
>
> https://bodhi.fedoraproject.org/updates/qgis-2.14.1-1.el7
> Please test and report any issues.
>

https://bodhi.fedoraproject.org/updates/qgis-2.14.1-2.el7
A fix for the incorrect dependency in qgis-grass has been pushed to testing.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Simplifying use of Python 3 macros?

[Dave Johansen]

On Mon, Apr 11, 2016 at 1:09 PM, Jason L Tibbitts III <ti...@math.uh.edu>
wrote:

> >>>>> "DJ" == Dave Johansen <davejohan...@gmail.com> writes:
>
> DJ> Is there anything that could be done in EPEL to make the Python 3
> DJ> macros be usable without requiring %{python3_pkgversion}?
>
> Well, there has been some on and off work focused on making python
> packaging less hideous.  A spec would look sort of like this:
>
> https://pagure.io/python-macros/blob/master/f/test1.spec
>
> And I think that would work down into EPEL.
>

Good to hear that progress is being made.


> But otherwise, there's not much we can do about that _pkgversion macro,
> since EPEL may even get multiple python versions at some point.  The
> fancy macros actually handle that, but they aren't really a thing you
> could use right now.
>

For the time being, could the python34 package add a Provides for python3
so the _pkgversion macro isn't necessary?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Upgrading QGIS to 2.14 in EL 7?

[Dave Johansen]

On Thu, Apr 7, 2016 at 5:16 PM, ~Stack~ <i.am.st...@gmail.com> wrote:

> On 04/07/2016 10:33 AM, Dave Johansen wrote:
> > https://www.qgis.org/en/site/forusers/visualchangelog214/index.html
> > QGIS has adopted a LTR model similar to Firefox and 2.14 is the new LTR.
> > I've considered doing what RedHat does with Firefox and updating the
> > version of QGIS in EPEL with LTR releases. What is everyone's thoughts
> > on that?
> > Thanks,
> > Dave
>
> Yes please!! :-)
>

https://bodhi.fedoraproject.org/updates/qgis-2.14.1-1.el7
Please test and report any issues.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: python_provide macro in EPEL 7?

[Dave Johansen]

On Thu, Apr 7, 2016 at 7:58 AM, Orion Poplawski <or...@cora.nwra.com> wrote:

> On 04/06/2016 10:00 PM, Dave Johansen wrote:
>
>> On Wed, Apr 6, 2016 at 8:39 PM, Orion Poplawski <or...@cora.nwra.com
>> <mailto:or...@cora.nwra.com>> wrote:
>>
>> On 04/06/2016 09:31 PM, Dave Johansen wrote:
>>
>> I'm trying to build python-breathe in EPEL 7 (
>>
>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/
>> ).
>> What's the right way to use/replace the %python_provide macro
>> there?
>>
>> I get the following error:
>>
>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>> I've checked in the fix.
>>
>>
>> I tried doing a build and got this error:
>> $ fedpkg build
>> error: line 47: Unknown tag: ERROR:
>> python%{python3_pkgversion}-breathenot recognized.
>> error: query of specfile
>> /home/dlj/fedora-scm/python-breathe/python-breathe.spec failed, can't
>> parse
>>
>
> I'm guessing that you are on Fedora 23 and that you need this update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
>

That did resolve that issues, but the build fails:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13601877
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Upgrading QGIS to 2.14 in EL 7?

[Dave Johansen]

https://www.qgis.org/en/site/forusers/visualchangelog214/index.html
QGIS has adopted a LTR model similar to Firefox and 2.14 is the new LTR.
I've considered doing what RedHat does with Firefox and updating the
version of QGIS in EPEL with LTR releases. What is everyone's thoughts on
that?
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: python_provide macro in EPEL 7?

[Dave Johansen]

On Wed, Apr 6, 2016 at 8:39 PM, Orion Poplawski <or...@cora.nwra.com> wrote:

> On 04/06/2016 09:31 PM, Dave Johansen wrote:
>
>> I'm trying to build python-breathe in EPEL 7 (
>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/ ).
>> What's the right way to use/replace the %python_provide macro there?
>>
>> I get the following error:
>> https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/
>>
>> Thanks,
>> Dave
>>
>>
>
>
> I've checked in the fix.


I tried doing a build and got this error:
$ fedpkg build
error: line 47: Unknown tag: ERROR: python%{python3_pkgversion}-breathenot
recognized.
error: query of specfile
/home/dlj/fedora-scm/python-breathe/python-breathe.spec failed, can't parse
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] python_provide macro in EPEL 7?

[Dave Johansen]

I'm trying to build python-breathe in EPEL 7 (
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/ ).
What's the right way to use/replace the %python_provide macro there?

I get the following error:
https://admin.fedoraproject.org/pkgdb/package/rpms/python-breathe/

Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: PSA: epel-rpm-macros in EL5 mock buildroots

[Dave Johansen]

On Mon, Apr 4, 2016 at 11:32 AM, Jason L Tibbitts III 
wrote:

> Something went wrong when epel-rpm-macros-5 was added to the EPEL5
> buildroot such that it works fine in koji but isn't actually present
> when you build in mock.  So if you were trying to de-cruft your specs
> and found that things weren't working as you expected when you did a
> mock build, that's why.
>
> Unfortunately the issue has turned out to be complicated since before
> this comps hadn't changed since 2012 and something has probably broken
> in an odd way.  The rel-eng folks are looking into things.  Note that
> this also appears to break yom groupinfo and the like for any
> EPEL5-related things.
>
> In the meantime, if you want to just work around this yourself, edit
> /etc/mock/epel-5-*.cfg and add "epel-rpm-macros" to
> config_opts['chroot_setup_cmd'].  That will give you what koji has
> currently.
>

To my knowledge mock for EL 5 has been broken for several months now:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/GC3INT2TX3OZ7YBLIJ5H6LH2WMZNBTPR/#ZDKVRSLJEJSPMN7FQ5LYO66NBP5IIRKE
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Fwd: [rhelv6-beta-list] Red Hat Enterprise Linux 6.8 Beta Now Available for Testing

[Dave Johansen]

On Tue, Mar 15, 2016 at 2:34 PM, Stephen John Smoogen 
wrote:

> So the 6.8 Beta is coming out. I would like to use this time as a
> general request for EPEL packagers wanting to make large updates or
> retirements of packages from RHEL-6 to do so now.
>

Is there an sort of "official" process for doing this?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: using epel-rpm-macros

[Dave Johansen]

On Sun, Mar 27, 2016 at 7:52 AM, Dave Love  wrote:

>
>
> Jason L Tibbitts III 
> writes:
>
> > If you have a build dependency on the SCL tools then you're obviously
> > not building for EPEL,
>
> Well, I'm building for people running EPEL, and I didn't see this isn't
> with packages that depend on anything scl.  The scl stuff needs to be
> installed initially, e.g. in copr root parameters, if you're going to
> build scl packages at some stage.
>
> (I don't understand why software collections aren't allowed so that more
> packages could be contributed.)


Inclusion of SCLs has been discussed several times and there's just never
been a way to make it work. If I recall correctly, Fedora still doesn't
allow SCLs as well.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Please test Darktable 2.0.1 for inclusion in EPEL7

[Dave Johansen]

On Tue, Mar 1, 2016 at 1:50 PM, Peter Loeffler 
wrote:

> Hi,
>
> it's my first time doing this. So please be patient.
>
> I have built Darktable 2.0.1 for RHEL/CentOS 7.
> The repo can be found here:
> https://copr.fedorainfracloud.org/coprs/ploeffler/darktable2/
>

Darktable is already available in EPEL:
http://dl.fedoraproject.org/pub/epel/7/SRPMS/d/darktable-1.6.9-6.el7.src.rpm


>
> The spec-file is very simple but it should do the job.
> I included some rpms from fedora and nux-desktop to get it running.
>

Fedora Rawhide has 2.0, so that would probably be a better place to start
from:
http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS/d/darktable-2.0.0-2.fc24.src.rpm


> For now everything is installed to /opt/darktable which is the default.
> Not shure if this is ok.
>

It's ok for a personal/COPR repo, but not for general use in EPEL/Fedora.
Using one of the above SRPMs would probably be the better place to start
because they'll meet (or at least should meet) the packaging guidelines.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Old scl-utils packages?

[Dave Johansen]

On Fri, Feb 26, 2016 at 10:25 PM, Stephen John Smoogen <smo...@gmail.com>
wrote:

> On 26 February 2016 at 21:01, Dave Johansen <davejohan...@gmail.com>
> wrote:
> > It looks like EPEL 5/6 have old versions of scl-utils. Those are probably
> > added back at a point when the base OS didn't have them, but they are now
> > older versions than what's available in the base OS.
> > Should EPEL versions be removed?
>
> I didn't know they were in the base OS but in a side channel. If they
> are in the base, then yes we should remove them.
>

Sorry, maybe I jumped the gun a bit. I actually didn't check if it's in a
side channel on RHEL, but was basing these statements on the fact that it's
in CentOS:
https://git.centos.org/summary/?r=rpms/scl-utils.git
http://mirror.centos.org/centos/6/os/x86_64/Packages/scl-utils-20120927-27.el6_6.x86_64.rpm
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Old scl-utils packages?

[Dave Johansen]

It looks like EPEL 5/6 have old versions of scl-utils. Those are probably
added back at a point when the base OS didn't have them, but they are now
older versions than what's available in the base OS.
Should EPEL versions be removed?
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL repos to keep older RPMs to keep backward compatibility and open the road for more

[Dave Johansen]

On Thu, Feb 18, 2016 at 11:53 PM, Gilles Dubreuil  wrote:

> Hello,
>
> The idea, which is probably not new or has been asked before, is about
> having EPEL repos to behave like RHEL repos and keep RPMs version from
> previous release/updates.
>
> The best case scenario is for recent version of the programming
> languages, but it could apply to many other packages.
>
> Languages in particular have regular and important updates which are
> released as stable version. There is no reason for EPEL to not benefit
> from those.
>
> But bringing more recent release potentially breaks backward
> compatibility and therefore is not recommended by the Fedora/EPEL
> package update policy.
>
> Meanwhile if EPEL could keep older RPMs version like RHEL channels does,
> then we could satisfy more people by offering various versions.
>
> Does it make sense and is this doable?
>

I believe that COPR and/or SCL are much better fits for rolling out newer
versions of packages like this.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Dave Johansen]

On Thu, Feb 18, 2016 at 5:22 PM, Stephen John Smoogen <smo...@gmail.com>
wrote:

> On 18 February 2016 at 16:37, Dave Johansen <davejohan...@gmail.com>
> wrote:
> > On Thu, Feb 18, 2016 at 3:54 PM, Bryan J Smith <b.j.sm...@ieee.org>
> wrote:
> >>
> >> Dave Johansen wrote:
> >> > RHSCL is a non-starter where I work (and I imagine at other
> >> > locations). 2-3 years of support just isn't enough to make it a
> >> > worthwhile investment.
> >>
> >> Well, there usually _is_ more than one (1) [RH]SCL per RHEL release.
> >> So it's more like 2-3 releases that "rebase" every 2+ years, for 6-7
> >> years total of the RHEL release.
> >>
> >> The idea here is that you have up to three (3) years to "rebase."  ;)
> >>
> >> Not that [RH]SCL is 3 years and that's it.  I mean ... understand my
> >> intent here.  Sustaining engineering is _not_ free, it's _not_
> >> upstream, and people should be expected to rebase every 2-3 years,
> >> when it comes closer to Upstream.
> >>
> >> Again, understand the "bigger picture" of my "suggestion."
> >>
> >> > For example, we just barely started upgrading to EL 7 ... (cut)
> >>
> >> _So_ you will likely be on the _second_ [RH]SCL release for RHEL 7,
> >> instead of the _first_.  So ... what's the problem?
> >>
> >> So ... I have to now ask ... have you used [RH]SCL?  ;)
> >>
> >> I.e., Again, it's _not_ only 3 years of RHEL, but 3 years per release,
> >> with each RHEL releases getting 2-3 releases over 6-7 years.
> >>
> >> Ergo ...
> >
> >
> > SCL is an AWESOME idea, but for our organization, having to jump to the
> next
> > version of an SCL every 2-3 years just isn't possible. We use RHEL
> because
> > of its long support life cycle and starting to use the SCL breaks that
> idea.
> > If SCL had a lifecycle more akin to RHEL (i.e. something like release
> half
> > as often and support for twice as long), then it would be a different
> story.
> >
>
> One of the issues that I am finding is that most software these days
> has only a 3 year lifetime at best.. if you want it to be longer you
> are going to pay for it either by maintaining it yourself or paying
> someone else. The work to try and keep software 'stable' over a 6
> month lifetime seems to grow exponentially so that by the end of the 3
> years it is 1000 times harder than it was in the beginning. Now the
> number of people who are wanting to work on this older software for
> free (or if they are doing it for themselves to share it for "free")
> is incredibly small. I expect that we are looking at 10 packages in
> EPEL maybe? So we are going to be looking at rebasing and updates
> every 2-3 years no matter what for the majority of software. Expecting
> it not to be like that is Cnut's tidal problem.
>
>
> https://en.wikipedia.org/wiki/King_Canute_and_the_waves
>

As mentioned several times already, EPEL means different things to
different people. To me stability is significantly more important than
having the latest and greatest, so for a fair number of packages that means
"just leave things alone" and the "waves" are self inflicted.

But as was also mentioned, a lot of packages have jumped on the Chrome
bandwagon with crazy release cycles and maintaining security fixes in those
cases is basically impossible for a volunteer effort. From my perspective,
having a policy that "discourages but allows updates" with a very
deliberate and controlled process is the right model for EPEL.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Dave Johansen]

On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smith  wrote:

> Stephen John Smoogen wrote:
> > Sorry what I meant that it is built against all of RHEL not just a
> > couple of channels. Again this isn't a promise we ever made, but one
> > people assume we have made (and get surprised when they find out
> > differently).
>
> I can only imagine how difficult this gets for EPEL maintainers, even
> the ones with the RHEL Developer Suite subscription.  There are just a
> lot of add-ons and channels to track, even ones not in the RHEL Dev.
>
> As I've mentioned in years prior, the only way to prevent this is for
> the CentOS team to build everything, and that's a tall order, and only
> getting to be a bigger and bigger task by the day.  So EPEL is really
> one of those things that Red Hat customers pull down, but don't enable
> ... until something specifically is needed, and then it's checked for
> conflicts, and only on a small subset of systems.
>
> Non-Red Hat customers running CentOS usually have a much easier task
> of enabling EPEL, although there can still be some issues.
>
> > And this is where I made things worse by conflicting with channels
> > versus "entire OS"
>
> I don't think there is a perfect answer that satisfies all, and never
> will be.  And definitely not 4-5 years into where EPEL is today, from
> where the Red Hat product line went more and more vertical than it
> ever was before.
>
> It's one of those things that people have just accepted.  Although it
> is good for maintainers to recognize that the EPEL build system is
> going to -- gasp -- build against Red Hat packages, and not CentOS. ;)
>
> > Probably but I would prefer to either have them one way or another :).
> > I would prefer not to have the "where is my N?" during the decay days
> > of EPEL-6 that we are seeing in EL-5 as packages get EOL'd that
> > people expected to be there.
>
> Maybe I'm throwing this out in ignorance ...
>
> But maybe [Red Hat] Software Collections ([RH]SCL) offers a baseline
> for a  "reasonable lifecycle" that should be a target?  I.e., 3 years.
>
> E.g., any software that makes it into EPEL will have a "soft target"
> of at least 3 years support?
>

RHSCL is a non-starter where I work (and I imagine at other locations). 2-3
years of support just isn't enough to make it a worthwhile investment. For
example, we just barely started upgrading to EL 7 and it will be years
until a sizable portion of our machines have moved to EL 7 (we still have
quite a few EL 5 boxes).

For most packages, leaving the version that's there alone is probably a
decent solution, but for packages where security fixes continue to happen
and are important, then an "official" upgrade path would be good. Maybe
something like:
1) Current maintainer identifies upgraded version and reason for update
(hopefully limited to security fixes or something along those lines and not
just "I want a newer version"),
2) Notifies intention on mailing list,
3) Feedback from community, and
4) Perform upgrade

Something like this could potentially get maintainers to step up that are
willing to continue maintaining the current version. But in most cases, I'm
guessing this wouldn't happen but would give an official process and
expected timeline for user users.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Commit access for EPEL branches?

[Dave Johansen]

On Mon, Feb 1, 2016 at 1:07 PM, Adam Miller <maxamill...@fedoraproject.org>
wrote:

> On Mon, Feb 1, 2016 at 12:57 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> > On Mon, 1 Feb 2016 08:58:13 -0700
> > Dave Johansen <davejohan...@gmail.com> wrote:
> >
> >> I would like to package rpmorphan for EL [1]. I created an EPEL 7
> >> branch, but the current owner/maintainer of the EPEL 5 and 6 branches
> >> hasn't responded to my requests for commit access. Is there some way
> >> for me to get commit access or do I have to go through the whole
> >> non-responsive maintainer process [2]?
> >>
> >> [1]: https://admin.fedoraproject.org/pkgdb/package/rpms/rpmorphan/
> >> [2]:
> >>
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
> >
> > I pinged them on IRC, hopefully they will see this soon...
> >
>
> Yup, that's 100% my fault. I completely missed this in my email.
> Access granted. Apologies for the delay. Thanks Kevin for reaching
> out.
>

Awesome! Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Commit access for EPEL branches?

[Dave Johansen]

I would like to package rpmorphan for EL [1]. I created an EPEL 7 branch,
but the current owner/maintainer of the EPEL 5 and 6 branches hasn't
responded to my requests for commit access. Is there some way for me to get
commit access or do I have to go through the whole non-responsive
maintainer process [2]?

[1]: https://admin.fedoraproject.org/pkgdb/package/rpms/rpmorphan/
[2]:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL5 version of epel-rpm-macros in testing

[Dave Johansen]

On Fri, Jan 29, 2016 at 8:03 AM, Manuel Wolfshant <wo...@nobugconsulting.ro>
wrote:

> On 01/29/2016 05:00 PM, Dave Johansen wrote:
>
> On Fri, Jan 29, 2016 at 1:46 AM, Manuel Wolfshant <
> <wo...@nobugconsulting.ro>wo...@nobugconsulting.ro> wrote:
>
>> On 01/29/2016 04:41 AM, Orion Poplawski wrote:
>>
>>> On 01/28/2016 12:02 AM, Ding Yi Chen wrote:
>>>
>>>>
>>>>
>>>> - Original Message -
>>>> [...]
>>>> 
>>>>
>>>> Any ETA on rpmlint EL5 update according to this change?
>>>>
>>>>
>>> This gets dicey because rpmlint is a RHEL package, not EPEL.
>>>
>>> It cannot be found in
>> ftp://ftp.redhat.com/redhat/linux/enterprise/5Client/en/os/SRPMS/ so no,
>> it's not a RHEL package.
>> It has always been in EPEL
>>
>>
>> wolfy, former maintainer of rpmlint for EL5 and EL6
>>
>
> For EL5, yes it's an EPEL package, but for EL6 and EL7, it's in the base
> OS:
>
> ftp://ftp.redhat.com/redhat/linux/enterprise/6Workstation/en/os/SRPMS/rpmlint-0.94-3.1.el6.src.rpm
> https://git.centos.org/log/rpms!rpmlint/refs!heads!c7
>
>
> The original question was "Any ETA on rpmlint EL5 update according to
> this change?".
>

Sorry, I was just trying to point out that fixing the version of rpmlint in
EL5 doesn't fully resolve the problem, because the version in EL6 also
warns about at least some of the "issues" that are trying to be cleaned up
with this.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Issue with mock for EL 5?

[Dave Johansen]

On Wed, Jan 27, 2016 at 8:43 PM, Orion Poplawski <or...@cora.nwra.com>
wrote:

> On 01/27/2016 04:43 PM, Dave Johansen wrote:
>
>> On Wed, Jan 27, 2016 at 10:42 AM, Orion Poplawski <or...@cora.nwra.com
>> <mailto:or...@cora.nwra.com>> wrote:
>>
>> On 01/27/2016 09:43 AM, Dave Johansen wrote:
>> > I was trying to do some test builds with EL 5 using mock on CentOS
>> 7.2 and I
>> > kept getting the following error:
>> >   Installing :
>> > 2:shadow-utils-4.0.17-23.el5.x86_64
>> > 82/114
>> > /usr/sbin/groupadd: error while loading shared libraries:
>> libselinux.so.1:
>> > cannot open shared object file: No such file or directory
>> > /usr/sbin/groupadd: error while loading shared libraries:
>> libselinux.so.1:
>> > cannot open shared object file: No such file or directory
>> >   Installing :
>> > libutempter-1.1.4-4.el5.x86_64
>> > 83/114
>> > warning: group utmp does not exist - using root
>> >
>> > Any ideas?
>>
>> There must be some kind of dependency loop going on.  It may be:
>>
>> libselinux -> setransd (mcstrans) -> /sbin/chkconfig (initscripts) ->
>> coreutils -> libselinux
>>
>>
>> Should I open a bugzilla? Or is this an issue that's already being worked?
>>
>
> I didn't find anything in bugzilla.  But this being EL5, I'm not sure it
> would be fixed at this point...
>

I'm pretty sure that this is a new issue because even just initializing
mock fails for EL 5 and I'm pretty sure that hasn't always been the case.

For example, I ran the following and got the same error:
mock -r epel-5-x86_64 --init
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Necessity of some old RPM constructs in EL5

[Dave Johansen]

On Fri, Jan 22, 2016 at 1:45 AM, Paul Howarth  wrote:

> On 22/01/16 03:11, Jason L Tibbitts III wrote:
>
>> I'm now working on some magic macros for EPEL5.  Currently (on my
>> machine, at least) you can use %license and don't need BuildRoot:.  I'm
>> curious about some other boilerplate constructs, though.
>>
>> %defattr in %files:
>> I've been told that even EPEL5 doesn't need this, but still it
>> persists.  Can someone verify that it really is not required?  Why do
>> people keep putting it in if so?
>>
>
> The need for this went away with rpm 4.4, so EL-4 needed it and EL-5 does
> not. It's probably still there because people can't remember whether it was
> EL-5 or EL-6 that removed the need for it, and left it there to be on the
> safe side.
>

And it's not helped by the fact that the version of rpmlint on EL 5 and 6
warns when it's missing.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Dave Johansen]

On Sun, Dec 13, 2015 at 11:28 PM, Peter Robinson 
wrote:

> On Mon, Dec 14, 2015 at 3:16 AM, Ken Dreyer  wrote:
> > On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson 
> wrote:
> >> 2) Automatic unpushing of updates that haven't gone stable after X
> >> time (I propose 3 months/90 days here). That should be ample time to
> >> know if it's good/bad.
> >
> > Could we make it go the other way, and submit the update to stable if
> > it's received no feedback for 90 days?
>
> No, because on two of the 3 I referenced there was bad karma and no
> response from the "maintainer" to the feedback.
>
> > Often I'll let my update sit in epel-testing for a long time because I
> > want to give users a large window of opportunity to test the update.
> > It's not that it's abandoned, it's just that it's not an urgent
> > update, so why rush it? If the update hits the karma threshold earlier
> > than I expected, so much the better.
>
> I think 90 days is enough to let people test it, ultimately the
> maintainer should have done the testing and know the vast majority of
> it is good, it should be more to get non standard use cases, corner
> cases etc.
>

In theory yes, but the real world is far messier than that. There are a few
packages that I maintain in EPEL because a package I needed depend on it,
but I don't use the functionality. So I know the package I use works but
I've never exercised/tested the functionality of the depended on package. I
wish that I had time for that to not be the case, but sadly that's just the
reality of the situation.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Centos 7, 32 bits edition

[Dave Johansen]

On Sat, Oct 17, 2015 at 3:55 PM, Karanbir Singh 
wrote:

> On 17/10/15 23:45, Stephen John Smoogen wrote:
>
> >
> > I don't think they would be "Fedora EPEL" then because the packages
> > wouldn't be built by koji, signed by us etc. I am not saying that such
> > builds couldn't happen in cbs.. it just wouldn't be EPEL.
>
> but you are building for/against a distro that had the same origin,
> would people at that point care if it was Fedora EPEL or CentOS EPEL ?
>

We do. I realize that it's a silly distinction, but getting software
approved that's "from RedHat" is tons easier for us than when it's "from
CentOS".
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

[Dave Johansen]

On Tue, Sep 22, 2015 at 6:56 AM, Remi Collet 
wrote:

> Le 21/09/2015 16:12, Haïkel a écrit :
> > Hi,
> >
> > Since the CentOS acquihire, there was a lot of discussion about EPEL's
> future.
> > Since the FOSDEM meetup between Fedora/CentOS folks, there was little
> > progress on that topic
>
> Just enable EPEL in CBS, and that's all.
>
> Remi.
>
>
> P.S. and explain to SIG member how to contribute to EPEL.
>

+1. I agree that using EPEL rather than trying to replace it is a much
better solution.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] [CentOS-devel] [Proposal] Converge EPEL and CBS

[Dave Johansen]

On Mon, Sep 21, 2015 at 7:12 AM, Haïkel  wrote:

> Hi,
>
> Since the CentOS acquihire, there was a lot of discussion about EPEL's
> future.
> Since the FOSDEM meetup between Fedora/CentOS folks, there was little
> progress on that topic
>
> After a discussion with a Smooge, I decided to come with a proposal,
> knowing that
> 1. Fedora wants to keep EPEL within it umbrella
> 2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages
> (or retag them for other SIGs)
> leading to poor maintenance as they don't follow EPEL tickets for all
> their dependencies.
> 3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
> *may* turn the former irrelevant
> 4. Some EPEL packages are poorly maintained especially on older EL
> releases and/or orphaned
>
>
> We've reached the point where both EPEL/CBS would greatly benefit to join
> hands.
>
> So I suggest that we consider the following:
> * EPEL will still use Fedora dist-git
> * EPEL builds should be done in CBS to make it easier for SIGs to consume
> it.
> * EPEL will use CentOS repositories instead of mirroring RHEL repositories
> * Bridging Fedora/CentOS accounting system (CentOS is migrating to
> FAS)  <== we need to see the feasibility of this but that would be
> optimal, that would increase the permeability between our two
> contributors pools which is something, we all want to encourage.
> * Create a EPEL provenpackager group under CentOS core SIG
> supervision, allowing them to appoint people to maintain EPEL
> packages.
>
> I suggest that we keep the EPEL name to acknowledge EPEL historical
> effort to provide quality additional packages for EL distros.
> Fedora contributors would still be able to contribute to EPEL, and
> CentOS contributors to make it up their standards.
>
> Would that work for you?
>

I'm a maintainer of several EPEL packages and a CentOS user. After reading
through this, I don't understand the value in this shift. Also, what are
the potential negatives of the change?
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] QGIS 2.8.2 for EPEL 7

[Dave Johansen]

I just built QGIS 2.8.2 for RHEL/EPEL 7 (
http://koji.fedoraproject.org/koji/taskinfo?taskID=9997800 ) and it is
available in the testing repo (
https://admin.fedoraproject.org/updates/qgis-2.8.2-1.el7 ). I built it
without PyQwt because it doesn't support Qwt 6 (
http://lists.osgeo.org/pipermail/qgis-developer/2014-December/036112.html
), so I'm sure that some functionality is disabled and/or won't work but
the main application is available for testing.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] cmake and cmake28 in RHEL 6?

[Dave Johansen]

On Sat, May 16, 2015 at 7:48 PM, Orion Poplawski or...@cora.nwra.com
wrote:

 On 05/15/2015 10:57 PM, Dave Johansen wrote:

 On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski or...@cora.nwra.com
 mailto:or...@cora.nwra.com wrote:

 On 04/21/2015 08:48 PM, Dave Johansen wrote:

 On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski
 or...@cora.nwra.com mailto:or...@cora.nwra.com
 mailto:or...@cora.nwra.com mailto:or...@cora.nwra.com wrote:

  On 04/20/2015 09:32 PM, Dave Johansen wrote:

  I just noticed that the version of cmake that comes
 with RHEL 6 is
  currently 2.8.12.2 and the EPEL has a cmake28 package
 that is at
  version
  2.8.11.2. I believe that RHEL 6 originally shipped with
 cmake
  2.6 and
  updated in a later point release, but I have two
 questions:
  1) Is the cmake28 a duplicate and need to be removed?


  Yes.


 Ok. Is this already being worked on? Or does a bugzilla need to be
 created for it?


 A quick search:

 https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28list_id=3417355

 turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351

 There is some question as to whether or not it is worth the pain to
 retire.  I suppose you could also consider it pulling things away
 from EPEL users.  If it is kept, it probably should be updated at
 least.


 Would it be possible to create a Bugzilla and request that a virtual
 provide for cmake28 be added to the cmake package in RHEL? I believe
 that would allow the package in EPEL to be retired without requiring
 changes to existing .spec files. I'm guessing that a cmake28 symlink
 might be needed as well, but it still seems possible and a solution that
 shouldn't have too much headache.


 Sure, anything is possible :).   Although I don't see what the big deal
 about changing the EPEL packages would be.   If anything, it would just
 bring them back in line with the Fedora branches.


My concern would just be the added effort of maintaining both of them and
it falling behind like has already happened here.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] cmake and cmake28 in RHEL 6?

[Dave Johansen]

On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski or...@cora.nwra.com
wrote:

 On 04/21/2015 08:48 PM, Dave Johansen wrote:

 On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski or...@cora.nwra.com
 mailto:or...@cora.nwra.com wrote:

 On 04/20/2015 09:32 PM, Dave Johansen wrote:

 I just noticed that the version of cmake that comes with RHEL 6 is
 currently 2.8.12.2 and the EPEL has a cmake28 package that is at
 version
 2.8.11.2. I believe that RHEL 6 originally shipped with cmake
 2.6 and
 updated in a later point release, but I have two questions:
 1) Is the cmake28 a duplicate and need to be removed?


 Yes.


 Ok. Is this already being worked on? Or does a bugzilla need to be
 created for it?


 A quick search:
 https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28list_id=3417355

 turns up:  https://bugzilla.redhat.com/show_bug.cgi?id=1159351

 There is some question as to whether or not it is worth the pain to
 retire.  I suppose you could also consider it pulling things away from EPEL
 users.  If it is kept, it probably should be updated at least.


Would it be possible to create a Bugzilla and request that a virtual
provide for cmake28 be added to the cmake package in RHEL? I believe that
would allow the package in EPEL to be retired without requiring changes to
existing .spec files. I'm guessing that a cmake28 symlink might be needed
as well, but it still seems possible and a solution that shouldn't have too
much headache.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Current update policy?

[Dave Johansen]

On Wed, Mar 18, 2015 at 6:34 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Tue, 17 Mar 2015 21:36:41 -0700
 Dave Johansen davejohan...@gmail.com wrote:

  What is the current update policy for EPEL? The stated one seems to be
  along the lines of no major changes (
  http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like
  whatever the packager is willing to maintain is the actual policy.
 
  I ask because a bugzilla was just opened against a package I maintain
  ( https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted
  to know how I should handle it.
 
  Does it need to be closed as wontfix? Or should a notice of upcoming
  major update policy be put in place to handle things like this?

 Rex already closed it as WONTFIX, however to expand on that:

 The current policy is to not change the user experence or require
 manual intervention on updates if at all possible. There are some cases
 where there's not much choice (like when the version shipped has
 serious security or data loss bugs and a upgrade to a new version is
 the only answer), but in those cases theres announcements to the
 epel-announce list and lots of time in testing.


Is that really true? The Qt 5 package in EPEL 6 has been updated several
times and I don't recall ever seeing an email/announcement/etc.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Current update policy?

[Dave Johansen]

On Wed, Mar 18, 2015 at 10:39 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Wed, 18 Mar 2015 08:00:35 -0700
 Dave Johansen davejohan...@gmail.com wrote:

  Is that really true? The Qt 5 package in EPEL 6 has been updated
  several times and I don't recall ever seeing an
  email/announcement/etc.

 Were the upgrades incompatible? You have to manually intervene?


Honestly, on the machines I'm using, I installed 5.2 and haven't updated
since 5.3 was released because I didn't want to rebuild and re-test all of
my stuff, but my understanding of the following is that the upgrades are
not completely compatible:
http://upstream.rosalinux.ru/versions/qt.html
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] Current update policy?

[Dave Johansen]

What is the current update policy for EPEL? The stated one seems to be
along the lines of no major changes (
http://fedoraproject.org/wiki/Updates_Policy ) but it seems more like
whatever the packager is willing to maintain is the actual policy.

I ask because a bugzilla was just opened against a package I maintain (
https://bugzilla.redhat.com/show_bug.cgi?id=1201808 ) and I wanted to know
how I should handle it.

Does it need to be closed as wontfix? Or should a notice of upcoming major
update policy be put in place to handle things like this?

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

Re: [EPEL-devel] include-what-you-use failing tests on PowerPC

[Dave Johansen]

On Mon, Feb 16, 2015 at 12:19 PM, Stephen John Smoogen smo...@gmail.com
wrote:



 On 14 February 2015 at 11:00, Dave Johansen davejohan...@gmail.com
 wrote:

 I'm working on packaging include-what-you-use and it's failing tests on
 PowerPC. I don't have access to PowerPC hardware to do the necessary
 debugging, so I just opened a bugzilla to document it (
 https://bugzilla.redhat.com/show_bug.cgi?id=1192723 ). Hopefully,
 someone can figure out what the problem is and submit a patch.
 Thanks,
 Dave


 I saw a similar problem you had with the arm with a possible fix listed by
 Peter Robinson. Did that work for PPC64? If not, I would excludearch64 for
 the time being.


For Fedora on ARM, it's failing to build and I haven't had a chance to try
the fix yet.

For EPEL on PowerPC, it's building but failing during the tests. I'm
guessing that ARM will run into the same test failure once it's building.

For the time being I've done an ExcludeArch for both.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Source tarball not found?

[Dave Johansen]

On Thu, Jan 29, 2015 at 9:50 PM, T.C. Hollingsworth 
tchollingswo...@gmail.com wrote:

 On Thu, Jan 29, 2015 at 9:30 PM, Dave Johansen davejohan...@gmail.com
 wrote:
  I'm trying to build llvm after applying a patch and I keep getting an
 error
  about lldb-3.4.src.tar.gz not being found, but that file has been there
 for
  previous builds and fedpkg says it has already been uploaded. Any ideas
 on
  what's wrong?
 
  The build.log can be found at:
  https://kojipkgs.fedoraproject.org//work/tasks/8365/8778365/build.log

 It's probably because you have:

 %if %{with lldb}
 Source3:
 %{downloadurl_base}/lldb-%{version_base}%{?prerel}.src.tar.gz
 %endif

 and %{with lldb} evaluates to false during SRPM creation time, so the
 tarball is not included in the SRPM and therefore isn't available to
 the binary build later on.

 Just remove this conditional.  You should always include all sources
 in the SRPM regardless of what's actually enabled in the build, so
 other people who just have the SRPM can turn on options if they want
 without having to download extra sources.


http://koji.fedoraproject.org/koji/taskinfo?taskID=8779288
That did the trick.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] Source tarball not found?

[Dave Johansen]

I'm trying to build llvm after applying a patch and I keep getting an error
about lldb-3.4.src.tar.gz not being found, but that file has been there for
previous builds and fedpkg says it has already been uploaded. Any ideas on
what's wrong?

The build.log can be found at:
https://kojipkgs.fedoraproject.org//work/tasks/8365/8778365/build.log

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

Re: [EPEL-devel] Questiona regarding c++11 support

[Dave Johansen]

On Wed, Jan 14, 2015 at 9:12 PM, Zhiwei Zhu z_...@wargaming.net wrote:

  Dear all,



 I am not sure whether this has been discussed before or whether it’s
 appropriate to discuss this in this list.



 My question is about c++11 support for the projects on epel (probably more
 specifically, epel7).  Do we have any kind of general policy regarding
 c++11 support?

 I am asking this because recently we encountered a problem related to
 this. The case is that our project is built with option ‘-std=c++11’ while
 the library used by our project on epel (specifically mongo-cxx-driver) was
 not built with this option, and our process simply crashes during start.

 The root cause is the ABI built with c++11 option is actually not
 compatible with that without it. Please refer to
 https://gcc.gnu.org/wiki/Cxx11AbiCompatibility.



 So the ‘-std=c++11’ draws a clear line between binaries/libraries, all of
 them must be built either with it or without it(C code is probably fine).
 You cannot mix them togother, otherwise there might be risks.



 Is there any general policy regarding this c++11 support? Or just
 maintainers make the decision for specific project?



 If the question is not approriate to discuss in this list, please ignore
 it. Or if anyone has any idea about where I can find relevant information,
  could you please share with me?


devtoolset seems to be the right solution for C++11 support because it
offers better ABI compatibility ( see section 2.2.2 at
https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/3/html/3.0_Release_Notes/DTS3.0_Release.html#Features
).

However, having said that, I previously brought up the idea of making the
devtoolset available for use in the EPEL (
https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html
) but the conversation never really picked up any traction. I would
definitely love to see devtoolset be made available for use when building
packages in the EPEL but I'm just not sure how to get that ball rolling.

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

Re: [EPEL-devel] Unknown origin Build error

[Dave Johansen]

Yes. That's the error.
On Jan 2, 2015 4:15 PM, Moez Roy moez@gmail.com wrote:

 you mean like this:

   8516012 buildSRPMFromSCM
 (/banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open (
 buildhw-03.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin
 for fedpkg-minimal-0.5.1.0-2.el7.noarch:
 file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/
   0 free  1 open  0 done  1 failed
 8516006 build (epel7-candidate,
 /banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open (
 buildhw-07.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin
 for fedpkg-minimal-0.5.1.0-2.el7.noarch:
 file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/
   0 free  0 open  0 done  2 failed



 On Fri, Jan 2, 2015 at 3:09 PM, Dave Johansen davejohan...@gmail.com
 wrote:

 I just tried building llvm on EPEL 7 and received an unknown origin build
 error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490 ). Is
 this some temporary issue because of a recent update that will resolve
 itself?
 Thanks,
 Dave

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



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


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

[EPEL-devel] Unknown origin Build error

[Dave Johansen]

I just tried building llvm on EPEL 7 and received an unknown origin build
error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490 ). Is
this some temporary issue because of a recent update that will resolve
itself?
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Unknown origin Build error

[Dave Johansen]

Nevermind, I guess. It appears to be working now.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8517009

On Fri, Jan 2, 2015 at 5:00 PM, Dave Johansen davejohan...@gmail.com
wrote:

 Yes. That's the error.
 On Jan 2, 2015 4:15 PM, Moez Roy moez@gmail.com wrote:

 you mean like this:

   8516012 buildSRPMFromSCM
 (/banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open (
 buildhw-03.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin
 for fedpkg-minimal-0.5.1.0-2.el7.noarch:
 file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/
   0 free  1 open  0 done  1 failed
 8516006 build (epel7-candidate,
 /banshee:df89331371895d1b042d9f8a08887bbcb203ceae): open (
 buildhw-07.phx2.fedoraproject.org) - FAILED: BuildError: Unknown origin
 for fedpkg-minimal-0.5.1.0-2.el7.noarch:
 file:///var/tmp/koji/tasks/4663/8514663/repo_442593_premerge/
   0 free  0 open  0 done  2 failed



 On Fri, Jan 2, 2015 at 3:09 PM, Dave Johansen davejohan...@gmail.com
 wrote:

 I just tried building llvm on EPEL 7 and received an unknown origin
 build error ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8516490
 ). Is this some temporary issue because of a recent update that will
 resolve itself?
 Thanks,
 Dave

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



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


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

Re: EPEL Questions about SCL during meeting (was: Anybody has something for agenda for Env-and-Stacks WG meeting today? (2014-09-09))

[Dave Johansen]

On Thu, Sep 11, 2014 at 12:47 PM, Matthew Miller mat...@fedoraproject.org
wrote:

 On Wed, Sep 10, 2014 at 03:51:00PM +0200, Honza Horak wrote:
  However, there are and will be cases where somebody would like to
  create a non-SCL RPM depended on a software collection, which is
  something not solved properly yet and the solution might be quite
  different from collection to collection.

 This makes me kind of scared. I'm all for the first sort of software
 collection, but I think limiting this helps constrain the problem set.

 (Although I don't think such packages should be limited from, eg, Fedora
 Playground.)


I'm not sure how/if this matters on Fedora, but for EL, being able to use
devtoolset would be a big gain and would allow for inclusion of packages
that require a newer compiler than gcc 4.4 that comes with RHEL 6 (
https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html
).
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Can 7 packages depend on Software Collections packages?

[Dave Johansen]

On Wed, Aug 27, 2014 at 6:22 AM, Karanbir Singh mail-li...@karan.org
wrote:

 On 08/26/2014 11:07 PM, Eric Smith wrote:
  On Tue, Aug 26, 2014 at 3:08 PM, Stephen John Smoogen smo...@gmail.com
 wrote:
  No they can not. Every package we ship in EPEL must only rely on what is
  shipped in either EPEL or base RHEL (or CentOS as it doesn't have a ton
 of
  confusing channels).
 
  OK.  I suppose I should ask the collections people whether a
  collection package for EL is allowed to depend on EPEL.

 the idea with SCL is that you extend a collection, or inherit another
 one by building your own collection. Its a oneway street, once you are
 in the scl lands.


It depends on if you're talking about making an SCL or using one (like
devtoolset). I previously asked about the concept of using devtoolset in
particular (
https://lists.fedoraproject.org/pipermail/epel-devel/2013-September/008737.html
) and think that it would be nice because it would allow for support of
packages that can't be built with gcc 4.4 that comes with EL.

One way to accomplish this would be to have an EPEL-DT repo that was built
with the newer version of gcc that comes with devtoolset. It would be nice
because it would allow developers to make use of it but wouldn't
necessarily require that the user have a devtoolset subscription (which is
my understanding of how devtoolset was meant to be used).

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

Re: EPEL Clang package doesn't work on Amazon Linux

[Dave Johansen]

On Mon, Apr 28, 2014 at 1:11 PM, Dave Johansen davejohan...@gmail.comwrote:

 On Mon, Apr 28, 2014 at 12:46 PM, Tyler Brock tyler.br...@gmail.comwrote:

 Update: testing packages work as advertised. Just wanted to keep you
 updated and thank you again.

 Will this go into the standard EPEL automatically or do we need to do
 something else at this point?


 Bodhi (the Fedora/EPEL update publication system) uses karma and delay
 times for testing of updates. You can read the details here (
 http://fedoraproject.org/wiki/How_to_test_updates ), but basically, if
 the package gets enough karma it can be pushed out sooner but otherwise it
 can be rolled out to the official repos 14 days after being available in
 the testing repos. So once that time has passed, I'll put in the request
 that it be moved to the official repos.


This update has been moved to the stable repo.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Amazon Linux and

[Dave Johansen]

On Thu, May 8, 2014 at 7:36 PM, Christopher Meng cicku...@gmail.com wrote:

 On Fri, May 9, 2014 at 9:57 AM, Matthew Miller mat...@fedoraproject.org
 wrote:
  Quite a lot; they make no attempt at compatibility. I think I'd respond
 with
  that. EPEL packages might work on Amazon Linux, and they might not.

 Matthew, thanks for your reply.

 I took the info from the bug, and found that pcre on amazon linux is
 8.x, quite fresh, RHEL only has 7.x version for customers.

 So I believe it's worthwhile to add some notes on EPEL page to alert the
 incompatibility.


The EPEL is designed to support RHEL and its derivatives. Amazon Linux
seems to have started with EL6 as a base to at least some extent but has
since evolved significantly. They do have a FAQ (
https://aws.amazon.com/amazon-linux-ami/faqs/ ) and it does reference the
EPEL and how to use it, but it also talks about how it is updated to
include the latest components on a regular basis. It also talks about how
there are several packages that are in Amazon Linux that are newer than
those in the EL6 and the EPEL.

Honestly, I think that the documentation of the issues with the EPEL
packages should really go on the Amazon side of things. They're the ones
that are deviating from EL and they should be letting their users know
about that instead of just saying you can use the packages from EPEL. I
guess that doesn't preclude the EL/EPEL community from trying to be good
citizens and help users out with a little documentation, but I don't think
any significant amount of effort should be put into it.

Also, I'm not all that familiar with EC2 but it does appear that they do
have a EL offering ( http://aws.amazon.com/partners/redhat/ ) that should
be fully compatible with EPEL and that should definitely be proposed to
anyone that runs into issues using the EPEL. It also looks like there's
options for using CentOS as well ( http://wiki.centos.org/Cloud/AWS ), so I
think there are plenty of good options for those wanting to use the EPEL
and it just may not be that Amazon Linux is high on that list.

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

Re: EPEL Clang package doesn't work on Amazon Linux

[Dave Johansen]

On Mon, Apr 21, 2014 at 11:40 AM, Tyler Brock tyler.br...@gmail.com wrote:

 Hey Dave, hope you had a nice weekend.

 Any update on the rpms?


Repos for x86 32-bit and 64-bit can be found at:
http://daveisfera.fedorapeople.org/yum/llvm-3.4/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Clang package doesn't work on Amazon Linux

[Dave Johansen]

On Tue, Apr 1, 2014 at 1:25 PM, Anssi Johansson e...@miuku.net wrote:

 1.4.2014 23.11, Tyler Brock kirjoitti:

  Thanks so much for looking into this Dave. Yes, libstdc++ was installed.


 It might be worth mentioning that the Amazon-provided libstdc++-devel is
 4.6.3-3.10.amzn1, and it doesn't seem to provide
 /usr/include/c++/4.4.4/iostream like the CentOS version does.


What does running yum provides /usr/include/c++/4.4.4/iostream on one of
these Amazon boxes output?
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Clang package doesn't work on Amazon Linux

[Dave Johansen]

On Tue, Mar 25, 2014 at 2:08 PM, Tyler Brock tyler.br...@gmail.com wrote:

 Here is a gist containing the output of attempting to compile the program
 after installing the clang package on each platform I mentioned:

 https://gist.github.com/TylerBrock/9771402

 -Tyler


 On Tue, Mar 25, 2014 at 4:54 PM, Tyler Brock tyler.br...@gmail.comwrote:

 To my knowledge it was originally based on CentOS but it has since
 diverged.

 It may be useful to mention that this same issue affects multiple Red Hat
 derivatives (including RHEL 6.4 itself) and not just Amazon Linux. I
 attempted the same process on Red Hat 6.4, Fedora 20, and Amazon Linux
 2013.09, and it fails on all three of these distributions with the same
 errors. In fact, the only distribution on which I have been able to get it
 to work is CentOS 6.4.

 -Tyler


 On Tue, Mar 25, 2014 at 1:46 AM, Dave Johansen davejohan...@gmail.comwrote:

 On Mon, Mar 24, 2014 at 6:38 PM, Tyler Brock tyler.br...@gmail.comwrote:

 Hey Everyone,

 I've been trying to use clang package on Amazon linux via EPEL and have
 installed version 3.4-9.el6 yet am unable to compile even the simplest of
 programs:
 #include iostream

 int main(){
 std::cout  Hello World  std::endl;
 }

 Saving the above into a file named test.cpp and compiling with clang++
 test.cpp produces the following error:

 test.cpp:1:10: fatal error: 'iostream' file not found
 #include iostream
  ^
 1 error generated.

 When attempting the same with gcc (g++) it works as expected so It
 seems like the clang compiler cannot find the required C++ headers and
 library files.

 I have contacted Amazon AWS support and they verified that the issue is
 reproducible by them running the latest version of Amazon Linux with
 updated packages from EPEL.

 I've tried installing devel headers for clang and multiple versions of
 libstd++ which seem to be placed in /usr/include/c++/gcc-version but
 which, when used by gcc, do not require the path to them be specified at
 all. It just works.

 I have a feeling the clang package is not built to work properly with
 Amazon Linux as C++ headers and library files (for either for libc++ or
 libstdc++) such as iostream should be found by default. Any help in
 resolving the matter would be greatly appreciated.

 It may also be worth noting that on CentOS the clang package seems to
 work fine.


 I'm the maintainer of clang in the EPEL, but honestly I know nothing
 about Amazon Linux. Is it an EL variant or claim any sort of
 compatibility with EL? A known issue even on EL/CentOS with clang is that
 much of the C++11/14 support won't work because of the old version of the
 standard library that is available on EL. It sounds like this isn't your
 issue, but if C++11/14 support is desired, then the devtoolset (
 http://rhn.redhat.com/errata/RHEA-2013-1226.html ) is the best route to
 follow.

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




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


I've tested on CentOS 6.5, RHEL 6.5 and RHEL 6.4 and all of them work. Do
you have the package libstdc++-devel installed? That package not being
installed is the only thing that I can think of that might be causing this
problem and maybe that package should be listed as a requires in the .spec
for clang.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Clang package doesn't work on Amazon Linux

[Dave Johansen]

On Mon, Mar 24, 2014 at 6:38 PM, Tyler Brock tyler.br...@gmail.com wrote:

 Hey Everyone,

 I've been trying to use clang package on Amazon linux via EPEL and have
 installed version 3.4-9.el6 yet am unable to compile even the simplest of
 programs:
 #include iostream

 int main(){
 std::cout  Hello World  std::endl;
 }

 Saving the above into a file named test.cpp and compiling with clang++
 test.cpp produces the following error:

 test.cpp:1:10: fatal error: 'iostream' file not found
 #include iostream
  ^
 1 error generated.

 When attempting the same with gcc (g++) it works as expected so It seems
 like the clang compiler cannot find the required C++ headers and library
 files.

 I have contacted Amazon AWS support and they verified that the issue is
 reproducible by them running the latest version of Amazon Linux with
 updated packages from EPEL.

 I've tried installing devel headers for clang and multiple versions of
 libstd++ which seem to be placed in /usr/include/c++/gcc-version but
 which, when used by gcc, do not require the path to them be specified at
 all. It just works.

 I have a feeling the clang package is not built to work properly with
 Amazon Linux as C++ headers and library files (for either for libc++ or
 libstdc++) such as iostream should be found by default. Any help in
 resolving the matter would be greatly appreciated.

 It may also be worth noting that on CentOS the clang package seems to work
 fine.


I'm the maintainer of clang in the EPEL, but honestly I know nothing about
Amazon Linux. Is it an EL variant or claim any sort of compatibility with
EL? A known issue even on EL/CentOS with clang is that much of the C++11/14
support won't work because of the old version of the standard library that
is available on EL. It sounds like this isn't your issue, but if C++11/14
support is desired, then the devtoolset (
http://rhn.redhat.com/errata/RHEA-2013-1226.html ) is the best route to
follow.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL appdata-tools in EL 7 beta?

[Dave Johansen]

I just tried building qt-creator for EPEL 7 beta, but it failed because the
appdata-tools package doesn't seem to be available. Is that not part of
EL/EPEL 7 beta? Should I just remove the use of it from the .spec? Or is
there a better solution?
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL 7 branch requests

[Dave Johansen]

On Tue, Mar 11, 2014 at 8:02 AM, Paul Howarth p...@city-fan.org wrote:

 On 11/03/14 14:59, Dave Johansen wrote:

 On Sun, Feb 23, 2014 at 10:22 AM, Kevin Fenzi ke...@scrye.com
 mailto:ke...@scrye.com wrote:

 On Sun, 23 Feb 2014 18:10:10 +0100
 Dominik 'Rathann' Mierzejewski domi...@greysector.net
 mailto:domi...@greysector.net wrote:

   Hello everyone,
   are the EPEL7 branch requests on
   https://fedoraproject.org/wiki/EPEL/epel7/Requests still being
   processed or are we back to the standard branch requests in the
   original review bugs?

 Yes they are.

 I'll look at processing it later today if no one beats me to it.


 I added the packages that I maintain to the list and they've been added,
 but do I have to kick off the builds on koji? Or is that done
 automatically?


 You have to do the builds yourself.


Sounds good.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Issue with koji?

[Dave Johansen]

On Thu, Feb 20, 2014 at 10:26 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Thu, 20 Feb 2014 07:54:07 -0700
 Dave Johansen davejohan...@gmail.com wrote:

  I'm trying to do a build on koji and ran into an error during the mock
  buildroot setup
  ( http://koji.fedoraproject.org/koji/taskinfo?taskID=6488038 ).
 
  I posted previously on the Fedora devel mailing list but haven't
  figured it out yet (
 
 https://lists.fedoraproject.org/pipermail/devel/2014-February/195111.html
  ).
 
  Is this something wrong with koji? Or with the EL6/EPEL packages?

 I answered you on the devel list:

 https://lists.fedoraproject.org/pipermail/devel/2014-February/195114.html

 Did a more recent build also fail?

 Please resubmit.


Yes, waiting did work for that issue (
https://lists.fedoraproject.org/pipermail/devel/2014-February/195156.html),
but this is another issue and appears to that the building of the
source
.rpm isn't working properly for some reason.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Thu, Jan 16, 2014 at 6:28 PM, Toshio Kuratomi a.bad...@gmail.com wrote:

 On Thu, Jan 16, 2014 at 04:47:04PM -0800, Dave Peterson wrote:
 
  Wouldn't this be a perfect use case for Software Collections?
 
 
 http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/
  Software_Collections_Guide/index.html
 
 I was considering this earlier and I'm a bit conflicted about that.
  There's
 several problems with this.  The most obvious is that SCLs are rather
 coarse
 grained and we want to solve this for both the coarse grained stuff like
 (python interpreter) and fine grained things (like upgrading a single
 library)

 The second problem is that we don't just want these things for users to
 use.  We also
 want them for our own use.  But SCLs are meant to be isolated from the
 system.so we've mostly decided that things in the system shouldn't use SCLs
 to work.  So we still need to solve the problem of newer python interpreter
 and newer django framework for use with apps that EPEL ships.


What about having a separate EPEL repo for SCLs and/or these newest version
of things? Like you mentioned before, this takes more work, but if then
those that want the stable base can have it and those that want the newest
can have it as well.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Dave Johansen]

On Fri, Jan 17, 2014 at 6:00 AM, Stephen Gallagher sgall...@redhat.comwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/16/2014 10:14 AM, Kevin Fenzi wrote:
  On Wed, 15 Jan 2014 10:32:18 -0500 Stephen Gallagher
  sgall...@redhat.com wrote:
 
  Perhaps this would be a good time to reopen the conversation of
  minor-release policy changes?
 
  Sure.
 
  RHEL releases approximately every six months with a minor
  release. It seems fair to allow major EPEL upgrades to occur in
  sync with those releases as well.
 
  So my suggestion would be that EPEL should have two branches for
  EPEL 7: the epel7 branch and the epel7-pending branch. The idea
  of this second branch would be sort of an EPEL Rawhide, where
  major upgrades can be staged. Then, when RHEL releases a minor
  update (such as RHEL 7.1), we have a (one-month?) integration
  period where we ensure that packages in epel7-pending work on the
  newest minor release and then they are merged back to epel7. If
  they miss this merge window, they have to wait until the next
  minor release.
 
  This allows us a regular, planned ability to move to newer EPEL
  packages, without destabilizing EPEL in general.
 
  ok, issues/thoughts:
 
  * Another branch is a fair bit more work rel-eng and infra wise.
  Would they be completely seperate? How do we merge them at a update
  point?
 
  ie, say I have foo. I have 1.0 in epel7 and push 1.2 to
  epel7-pending. Does the epel7-pending one use bodhi? Does it get
  signed and composed and push to a repo somewhere? now, say rhel7.1
  comes out. How do we reconcile the two branches/trees/composes?
 

 My thoughts are these (in no particular order).
  * Treat this branch like Rawhide. All builds targeted at this are
 composed to a repo. Signing is nice, but not mandatory in my opinion.
  * When rhel7.1 comes out, there is no automatic movement from
 epel7-pending into the epel branch. We open a merge window where
 packages are allowed to merge from the epel7-pending git branch.
 Merging a major upgrade outside this window is forbidden. At this
 time, any packager that believes their package is ready for prime-time
 may manually perform a merge, build and submission to Bodhi.


  * The change point seems like it would be kinda fluid, which would
  not be great expectation wise. Ie, say rhel7.1 comes out. How long
  after that do we wait to push the changes? We can't really do it
  the same time, as we won't know for sure what that will be. We
  could do it as soon as it's public, but then enterprise rebuilds
  aren't ready yet. We could wait for CentOS, but then do we wait for
  SL? OEL? Do we tell users it can happen some random time after a
  minor release, please pay attention?
 

 I think we could set a policy of merge window opens one week after
 official RHEL release and remains open for two/three weeks after
 that. Packages have to go through Bodhi approval for upgrade (perhaps
 we mandate at least one positive karma review on major upgrades?)
 which may take longer than the merge window, but they have to be
 submitted within that time.


  * The majority of epel packages I think don't care about this.
  It's only a subset. Perhaps we could do something with them? Move
  them to coprs, get them in as CentOS variants, something?
 

 The majority isn't necessarily as interesting as the popular packages.
 There are plenty of people out there who want to see new Django,
 Wordpress, Trac, etc. packages that we simply cannot cleanly upgrade
 in EPEL 6 today because they aren't fully backwards-compatible.

 COPRs is really a workaround for (IMHO) a failure of policy in EPEL to
 remain useful as the world moves ahead. It's pretty unrealistic to
 expect volunteer package maintainers to support their packages for the
 same duration that Red Hat supports RHEL (currently ten years for RHEL
 5 and 6). I think we're discouraging community inclusion if we don't
 offer people a policy that allows them to keep their package closer to
 upstream for reduced maintenance effort.


Yes, this makes the experience better for maintainers, but makes the
experience worse for users and developers of existing tools/infrastructure.
All the RHEL users I know choose it because they want a stable platform
that isn't changing every 6 months to a year. Like Toshio mentioned before,
existing projects want what's there to stay there and new projects want the
latest and greatest. The EL mentality is stable and predictable and the
Fedora mentality is latest and greatest, so I think that both options are
there for those that want them and I don't think that changing EL to be
more Fedora like is a good thing.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Updating ODB in ?

[Dave Johansen]

On Tue, Dec 3, 2013 at 12:06 AM, Dan Horák d...@danny.cz wrote:

 On Mon, 2 Dec 2013 21:42:10 -0700
 Dave Johansen davejohan...@gmail.com wrote:

  On Mon, Dec 2, 2013 at 8:19 AM, Kevin Fenzi ke...@scrye.com wrote:
 
   On Mon, 2 Dec 2013 09:45:44 +0400
   Peter Lemenkov lemen...@gmail.com wrote:
  
Hello All!
   
2013/12/2 Dave Johansen davejohan...@gmail.com:
 I recently submitted ODB 2.2 to the EPEL for EL 5/6 and version
 2.3 has been released (

 http://codesynthesis.com/pipermail/odb-announcements/2013/37.html
 ). The wiki seems to indicate that updating software for feature
 releases is discouraged (
 https://fedoraproject.org/wiki/EPEL_Updates_Policy#Stable_Releases
 ), so is updating ODB to 2.3 in the EPEL not really possible?
 Assuming that's the case, is there a recommended solution for
 maintaining access to newer versions of ODB for EL users?
   
ODB is still a young package (in terms of existing in EL
repositories) so I would update it anyway. However in the future
ypu'd better to provide parallel-installable odb30, odb40 etc
packages.
  
   The questions to ask are:
  
   Does the upgrade require intervention? ie, if someone did the
   upgrade would they have to manually change config files, or migrate
   databases or whatever?
  
 
  No, the 2.3 version just adds some features and there wouldn't be any
  needed changes to config files or databases to support the update.
 
 
   Next, is the package a gui one that changes look and feel? ie, would
   some user who updated suddenly have to relearn where the various
   options are?
  
 
  There's no GUI or user facing part of it, so it would be effect
  developers but not users.
 
 
   Finally, does it change abi/api any? If it was updated would people
   have to rebuild other things to work with it?
  
 
  There were additions to the API to support the new features and I'm
  guessing that there may be ABI changes as well. Basically, I'm
  guessing that a rebuild would be necessary.

 you can easily check the possible API/ABI difference with the
 abi-compliance-checker tool


I put in a request to have it added to upstream-tracker.org and it looks
like 2.3 does have ABI breakage issues:
http://upstream-tracker.org/versions/libodb.html
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Updating ODB in ?

[Dave Johansen]

On Mon, Dec 2, 2013 at 8:19 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Mon, 2 Dec 2013 09:45:44 +0400
 Peter Lemenkov lemen...@gmail.com wrote:

  Hello All!
 
  2013/12/2 Dave Johansen davejohan...@gmail.com:
   I recently submitted ODB 2.2 to the EPEL for EL 5/6 and version 2.3
   has been released (
   http://codesynthesis.com/pipermail/odb-announcements/2013/37.html
   ). The wiki seems to indicate that updating software for feature
   releases is discouraged (
   https://fedoraproject.org/wiki/EPEL_Updates_Policy#Stable_Releases
   ), so is updating ODB to 2.3 in the EPEL not really possible?
   Assuming that's the case, is there a recommended solution for
   maintaining access to newer versions of ODB for EL users?
 
  ODB is still a young package (in terms of existing in EL
  repositories) so I would update it anyway. However in the future ypu'd
  better to provide parallel-installable odb30, odb40 etc packages.

 The questions to ask are:

 Does the upgrade require intervention? ie, if someone did the upgrade
 would they have to manually change config files, or migrate databases
 or whatever?


No, the 2.3 version just adds some features and there wouldn't be any
needed changes to config files or databases to support the update.


 Next, is the package a gui one that changes look and feel? ie, would
 some user who updated suddenly have to relearn where the various
 options are?


There's no GUI or user facing part of it, so it would be effect developers
but not users.


 Finally, does it change abi/api any? If it was updated would people
 have to rebuild other things to work with it?


There were additions to the API to support the new features and I'm
guessing that there may be ABI changes as well. Basically, I'm guessing
that a rebuild would be necessary.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Updating llvm/clang?

[Dave Johansen]

On Sun, Dec 1, 2013 at 10:48 PM, Peter Lemenkov lemen...@gmail.com wrote:

 2013/12/2 Dave Johansen davejohan...@gmail.com:
  Currently, llvm/clang in the EPEL repo has been orphaned and I was
  considering packaging YouCompleteMe (
  https://github.com/Valloric/YouCompleteMe ) for EL, but if requires
 clang
  3.2 or higher and so I was wondering if it would be possible for me
  llvm/clang to be updated to 3.3. I have spoken with the Fedora maintainer
  (ajax) and he was ok with the idea, but said that it would need
 approval. I
  have made the necessary updates to the .spec file of llvm 3.3 so it will
  build on EL 6 and would be happy with becoming the maintainer if this was
  approved.

 Providing LLVM ver. 2.x nowadays sounds a joke so I'd rather update it
 to a very recent version. Also it's a leafnode standalone
 application(s) which makes updating even simpler.


Ok, I'll contact ajax and get his ok on the changes that I made to the
.spec file and then start the process of becoming maintainer and doing the
update.
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL Updating ODB in ?

[Dave Johansen]

I recently submitted ODB 2.2 to the EPEL for EL 5/6 and version 2.3 has
been released (
http://codesynthesis.com/pipermail/odb-announcements/2013/37.html ).
The wiki seems to indicate that updating software for feature releases is
discouraged (
https://fedoraproject.org/wiki/EPEL_Updates_Policy#Stable_Releases ), so is
updating ODB to 2.3 in the EPEL not really possible? Assuming that's the
case, is there a recommended solution for maintaining access to newer
versions of ODB for EL users?
Thanks,
Dave
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL Updating llvm/clang?

[Dave Johansen]

Currently, llvm/clang in the EPEL repo has been orphaned and I was
considering packaging YouCompleteMe (
https://github.com/Valloric/YouCompleteMe ) for EL, but if requires clang
3.2 or higher and so I was wondering if it would be possible for me
llvm/clang to be updated to 3.3. I have spoken with the Fedora maintainer
(ajax) and he was ok with the idea, but said that it would need approval. I
have made the necessary updates to the .spec file of llvm 3.3 so it will
build on EL 6 and would be happy with becoming the maintainer if this was
approved.

As of right now, it looks like there isn't anything in the EPEL that
depends on llvm/clang, so at least from this perspective it shouldn't be
that big of a deal.

Here's the command I ran to find dependencies and its output:
repoquery -q --whatrequires --recursive --resolve --repoid=epel llvm
llvm-0:2.8-14.el6.i686
clang-0:2.8-14.el6.i686
clang-analyzer-0:2.8-14.el6.
i686
clang-devel-0:2.8-14.el6.i686
clang-doc-0:2.8-14.el6.noarch
llvm-devel-0:2.8-14.el6.i686
llvm-doc-0:2.8-14.el6.noarch
llvm-ocaml-0:2.8-14.el6.i686
llvm-ocaml-devel-0:2.8-14.el6.i686
llvm-ocaml-doc-0:2.8-14.el6.noarch

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

Re: EPEL Access to devtoolset in ?

[Dave Johansen]

On Fri, Sep 20, 2013 at 8:44 PM, T.C. Hollingsworth 
tchollingswo...@gmail.com wrote:

 On Fri, Sep 20, 2013 at 2:23 PM, Dave Johansen davejohan...@gmail.com
 wrote:
  Part of the confusion may also come from the fact that the binaries
  generated by devtoolset are standalone and can be run on vanilla
 installs of
  RHEL 5/6 (i.e. without the devtoolset installed). So generally the
  devtoolset is only needed during build time, but since the ODB compiler
 is a
  plugin for gcc, the devtoolset is required for it's use when generated
 code
  for use with the runtime.
 
  In summary, the devtoolset requires the appropriate subscription from RH,
  but that is the point of my request. I would like to request that
 devtoolset
  be made available on Koji so it can be used to build certain packages.
 The
  idea is that then it will build the rpm on the server and it will be
  available in the EPEL (but not the devtoolset itself). This means that
  anyone who would want to use this package would need to have the
 devtoolset
  installed, so it doesn't violate any of the RH/EPEL policies, but would
  enable the use of the devtoolset with the EPEL.

 As you indicated in the other thread, the devtoolset channel is only
 included in
 developer RHEL subscriptions.  I'd presume the vast majority of EPEL
 consumers
 have server-type subscriptions, so they wouldn't have access to it,
 correct?

 That kind of sucks—there would be packages in EPEL that would have broken
 deps
 for a lot of EPEL users and no real way of indicating to those users what
 the
 problem is.  :-(

 What about CentOS and Scientific Linux?  These are 100% fully supported
 targets
 for EPEL [1] and cannot be ignored.  If they have no access to it, it
 shouldn't
 be used in EPEL.  On the other hand, if most of those users have access to
 the
 necessary dependencies, it might lessen the severity of lack of access to
 bona
 fide RHEL users in some peoples' eyes.


There are rebuilds of devtoolset by both the CentOS and Scientific Linux
guys. It obviously comes without the support that you get with the RedHat
subscription, but it's still an option and is available to anyone (not just
the CentOS or Scientific Linux guys). The repos can be found at:
http://people.centos.org/tru/devtools-1.1/
http://ftp.scientificlinux.org/linux/scientific/6.4/i386/external_products/devtoolset/


 In general, it seems your package is much more suited for a fedorapeople
 repo or
 similar.  It doesn't seem to be generally useful to the vast majority of
 EPEL
 consumers, just to users with a very limited set of RHEL subscriptions.
  What's
 the point of making something available in EPEL if the vast majority of
 EPEL
 users can't use it?


I don't really get this line of reasoning. Is generally useful now a
requirement to be part of the EPEL? I've always had the understanding that
if it's useful to someone on RHEL, they're willing to maintain it, and it
makes it through the approval process, then it's ok to include in the EPEL.
I recognize that RedHat has made the use of the devtoolset unnecessarily
complex because of the additional subscription that's required, but that's
why I want to start this discussion. I'd like to help the community figure
out how to make use of this very useful tool (the devtoolset) and be able
to add to the excellent set of packages that the EPEL already is.

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

Re: EPEL Access to devtoolset in ?

[Dave Johansen]

On Mon, Sep 16, 2013 at 8:37 PM, Kevin Fenzi ke...@scrye.com wrote:

 On Mon, 16 Sep 2013 20:32:41 -0700
 Dave Johansen davejohan...@gmail.com wrote:

  How can I get involved in that process? I would definitely like to
  help out with enabling the support for them in the EPEL.

 Join the packaging list and see this post just today:

 https://lists.fedoraproject.org/pipermail/packaging/2013-September/009525.html


So after a little discussion on the packaging list, it was decided that
this is the right place to have the conversation (
https://lists.fedoraproject.org/pipermail/packaging/2013-September/009554.html).

I think part of the confusion may have come because I don't want to package
an SCL, but I want to make use of a specific SCL that RedHat has created.
The discussion going on in the packaging mailing list is about the
guidelines for how to create SCLs, so my request isn't really pertinent
there. Anyway, I'll try to describe the situation a little better.

There are two parts of ODB: 1) the compiler and 2) the runtime. The
compiler takes an input and generates C++ code that can be built against
and used with the runtime. The generated code and the runtime can be used
with gcc 4.2 or greater.

The issue is that ODB requires gcc's plugin support (
http://gcc.gnu.org/wiki/plugins ) to parse the input. Plugin support was
added in gcc 4.5 and only gcc 4.4 is available on RHEL 5/6. The devtoolset
makes a newer version available, which enables the use of the compiler and
not just the runtime.

Part of the confusion may also come from the fact that the binaries
generated by devtoolset are standalone and can be run on vanilla installs
of RHEL 5/6 (i.e. without the devtoolset installed). So generally the
devtoolset is only needed during build time, but since the ODB compiler is
a plugin for gcc, the devtoolset is required for it's use when generated
code for use with the runtime.

In summary, the devtoolset requires the appropriate subscription from RH,
but that is the point of my request. I would like to request that
devtoolset be made available on Koji so it can be used to build certain
packages. The idea is that then it will build the rpm on the server and it
will be available in the EPEL (but not the devtoolset itself). This means
that anyone who would want to use this package would need to have the
devtoolset installed, so it doesn't violate any of the RH/EPEL policies,
but would enable the use of the devtoolset with the EPEL.

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

EPEL Access to devtoolset in ?

[Dave Johansen]

http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
I know that the devtoolset requires an additional subscribe to get
access, but is there a way to make use of it in the Koji build process
so that those who are subscribed to the devtoolset can make use of the
package that uses it in the EPEL?

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

Re: EPEL Access to devtoolset in ?

[Dave Johansen]

On Mon, Sep 16, 2013 at 11:08 AM, Kevin Fenzi ke...@scrye.com wrote:
 On Mon, 16 Sep 2013 10:43:50 -0700
 Dave Johansen davejohan...@gmail.com wrote:

 http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
 I know that the devtoolset requires an additional subscribe to get
 access, but is there a way to make use of it in the Koji build process
 so that those who are subscribed to the devtoolset can make use of the
 package that uses it in the EPEL?

 EPEL strives to use Fedora packaging guidelines.

 from:
 https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Software_Collection_Macros

 Software Collections (as defined here) are not permitted to be built
 or enabled in official Fedora packages.

 Until there are Fedora guidelines for them, no way EPEL is going to
 enable them blindly, sorry. ;)

 There is work underway to craft guidelines for them, you might look at
 assisting in that effort and adding needed bits for using them in EPEL
 too.

How can I get involved in that process? I would definitely like to
help out with enabling the support for them in the EPEL.

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