[EPEL-devel] Re: Requirements for SRPM names

2016-09-13 Thread Dennis Gilmore 
On Tuesday, September 13, 2016 11:54:41 PM CDT Peter Robinson wrote:
> >> I'm looking for some clarification on the naming requirements for
> >> SRPMs.
> >> 
> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> >> be the same, but the release number would be pretended with "0.".
> >> 
> >> Could someone please clarify?
> >> 
> >> If, in fact, the name can be the same, it will make it much easier to
> >> provide Python 3 packages for EPEL since a separate package would not
> >> be required in the Fedora Package DB.
> > 
> > So, here's the thing (at least as I understand it):
> > 
> > koji operates on source packages.
> > 
> > If there's a package in RHEL called 'foo' and also one in EPEL called
> > 'foo' it will use the epel one in all cases for everything that foo
> > makes.
> 
> Is that the case with external repos? I didn't think it was that smart
> in that case, but I'm tired so might be mis-remembering.
It 100% is the case. Koji treats external repos exactly the same as internal.  
it even taks special care to ensure that all binary rpms for a given srpm are 
included even if the binary rpms are spread acorss different external repos

> > So, with the limited arch packages this means that _ALL_ things
> > building in koji will use the epel package. The reason for the
> > prepended 0 is so that users don't install the epel package and instead
> > get the newer rhel version. The limited arch guideline also says you
> > should try and keep the package as close as possible to the rhel
> > version.
> 
> For el7, and even in some of the big (java*) use cases in el6 the
> delta in packages between the arches is getting a lot less, and I
> believe this will be more so as we move forward in el7.
I honestly am not sure there is any limited arch packages in epel7 

> > So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> > python-foobar-1.0-1.noarch.rpm and then we made a epel
> > python-foobar-1.0-1.el7.src.rpm that had
> > python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> > against python-foobar in epel would break (it would be not found). End
> > users would be ok, but buildroots could be broken by it.
> > 
> > So we are kinda in a lerch here... I think the best way is just new
> > packages with python3-whatever.
> > 
> > kevin
> > 
> > 
> > 
> > ___
> > epel-devel mailing list
> > epel-devel@lists.fedoraproject.org
> > https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject
> > .org
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.o
> rg

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

[EPEL-devel] Re: Requirements for SRPM names

2016-09-13 Thread Dennis Gilmore 
On Tuesday, September 13, 2016 5:35:29 PM CDT Neal Gompa wrote:
> On Tue, Sep 13, 2016 at 5:26 PM, Kevin Fenzi  wrote:
> > On Tue, 13 Sep 2016 14:13:44 -0400
> > 
> > Avram Lubkin  wrote:
> >> I'm looking for some clarification on the naming requirements for
> >> SRPMs.
> >> 
> >> In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
> >> can't conflict with RHEL SRPM names, but in the Limited Arch Packages
> >> [2]section of EPEL: Packaging, it seems to imply the SRPM name would
> >> be the same, but the release number would be pretended with "0.".
> >> 
> >> Could someone please clarify?
> >> 
> >> If, in fact, the name can be the same, it will make it much easier to
> >> provide Python 3 packages for EPEL since a separate package would not
> >> be required in the Fedora Package DB.
> > 
> > So, here's the thing (at least as I understand it):
> > 
> > koji operates on source packages.
> > 
> > If there's a package in RHEL called 'foo' and also one in EPEL called
> > 'foo' it will use the epel one in all cases for everything that foo
> > makes.
> > 
> > So, with the limited arch packages this means that _ALL_ things
> > building in koji will use the epel package. The reason for the
> > prepended 0 is so that users don't install the epel package and instead
> > get the newer rhel version. The limited arch guideline also says you
> > should try and keep the package as close as possible to the rhel
> > version.
> > 
> > So, if we had say: python-foobar-1.0-1.el7.src.rpm in rhel that made a
> > python-foobar-1.0-1.noarch.rpm and then we made a epel
> > python-foobar-1.0-1.el7.src.rpm that had
> > python3-foobar-1.0-1.noarch.rpm it would mean anything that builds
> > against python-foobar in epel would break (it would be not found). End
> > users would be ok, but buildroots could be broken by it.
> > 
> > So we are kinda in a lerch here... I think the best way is just new
> > packages with python3-whatever.
> 
> That doesn't make sense. Builds are done by pulling in base, epel, and
> buildroot repositories into a generated mock config and executed (i.e.
> passed to mock to build the SRPM and then the RPMs). No part of mock
> would have a problem here. Therefore, there is no reason for the
> absurdity of having python3-* SRPMs.
> 
> Sure, Koji operates on SRPMs, but Fedora Koji does not build RHEL or
> CentOS. So this particular problem doesn't exist from that perspective
> either. Content from RHEL/CentOS essentially is a black box to Koji.

The koji repos will only include binary packages from exactly one source rpm 
of a given name. koji builds its own repos and does not use the repos in the 
way you think and you would at home. Koji was tought to treat external repos 
exactly the same as internal repos. Net result being if you rebuild python-foo 
to get a python3 build you will have to also build python2 version and ensure 
that the nvr is lower. The only realistic option given that there will be 
python3 mass rebuilds as python versions change is to have python3 specific 
srpms

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

[EPEL-devel] Standing down from EPSCo

2016-03-09 Thread Dennis Gilmore 
Hi All,

Effective immediately I am stepping down from EPSCo, I am unable to give it 
the time it deserves. There is just too much going on in Fedora. I will gladly 
help and guide people to get involved in making process changes in how we ship 
EPEL, or adding a faster stream, or whatever gets decided upon. 

Regards

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding epel-rpm-macros to the buildroot

2016-01-20 Thread Dennis Gilmore 
On Wednesday, January 20, 2016 08:26:13 AM Kevin Fenzi wrote:
> On Wed, 20 Jan 2016 01:02:46 -0600
> 
> Jason L Tibbitts III  wrote:
> > I've now done many mass rebuilds both with and without epel-rpm-macros
> > in the buildroot and have found exactly 31 failures which result from
> > the presence of the macro package.  This macro package enables, in
> > EPEL6, the use of %license in the %files section of the spec without
> > having to conditionally define it.
> 
> ...snip...
> 
> > Does anyone have any objections to me doing either of these?  If I can
> > get the macro package into the buildroot then I can move on with
> > adding some of the other requested macros.  This should all be much
> > easier with the rebuild infrastructure I have in place now.  I can
> > also move on to trying to help out EPEL5 as well.  I'd really like to
> > put this phase of the work to bed as soon as is feasible.
> 
> Sounds great to me, and thanks for working on this. :)
> 
> kevin
+1

When you are ready for the change to be made, please file a ticket with 
releng, we will need to coordinate a koji and comps change.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

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

2015-09-23 Thread Dennis Gilmore 
On Tuesday, September 22, 2015 08:45:32 PM Karsten Wade wrote:
> On 09/22/2015 11:35 AM, Dave Johansen wrote:
> > 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.
> 
> AIUI, the concern is that what is labeled/supported by the CentOS
> Project as 'CentOS' needs to go through the CentOS Project QA system.
> We simply cannot blindly accept builds from outside of the CentOS
> builders just on say-so. (Compare to RPMfusion et al -- putting that
> repo in as a default for Fedora users is more than a legal issue, it's
> a QA/test/build/sign/release issue.)

I disagree here, it is entirely a legal issue, if there were not the legal 
issue to deal with then the packages would be in Fedora and the rest is taken 
care of.

> Two possible pathways from there are:
> 
> 1. Rebuild all of EPEL in cbs.centos.org for SIGs to use; make it
> available as an alternate repo (of just rebuilt packages); encourage
> people to choose EPEL otherwise without an associated QA endorsement.

This seems wasteful, but is an option.

> 2. Figure out how to test EPEL 100% against CentOS (such as Fedora's
> Koji builds EPEL against CentOS and runs all latest CentOS Project QA
> before signing and shipping.)
We are unlikely to build EPEL against CentOS except for arches not supported 
by Red Hat (i686 today).  But we should be able to setup tests in taskotron 
that test against CentOS as well as against RHEL.  that is something I could 
fully support.

> On the latter, I only have an indication that might work -- I defer to
> the CentOS and EPEL experts to figure out the technical how-to. :) But
> once they are done & happy, I'd then be happy to sign-off on calling
> the result 'CentOS'.

We would need to engage the QA team to see what we can do in taskotron exactly

Dennis


signature.asc
Description: This is a digitally signed message part.
___
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

2015-09-22 Thread Dennis Gilmore 
On Monday, September 21, 2015 08:58:21 PM Haïkel wrote:
> 2015-09-21 19:46 GMT+02:00 Kevin Fenzi :
> > On Mon, 21 Sep 2015 16:12:07 +0200
> > 
> > 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.

Why is this? would it be enough that the CBS had epel as an external repo that 
can be added to SIG's projects? that way epel and updates can be available to 
build against.

> > Which tickets do you mean here? They are only rebuilding some packages,
> > but not others or?
> 
> Any tickets filed against EPEL, for instance, if a bug or CVE is fixed
> against EPEL package,  CBS rebuilds won't be impacted as there's no
> way to automate that.
> Some examples from CentOS Cloud SIG:
> * RabbitMQ: it's a runtime requirement for OpenStack, we could just
> reuse EPEL packages but that would mean that Cloud SIG repository
> wouldn't be self-contained
> => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
> * A hell lot of python build requirements, that have to be rebuilt in
> CBS, as CBS don't have access to EPEL packages.
if we build and track in epel and use epel in CBS to build against we should 
be covered.
 
> For instance, if the EPEL package gets fixed for a CVE, the CBS
> package may not get fixed (and vice-versa).
> Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
> 
> >> 3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
> >> *may* turn the former irrelevant
> > 
> > I suppose, but lots of people use/look to epel for packages, I don't
> > think that will change to using packages from CentOS sigs overnight.
> 
> I agree.
> 
> >> 4. Some EPEL packages are poorly maintained especially on older EL
> >> releases and/or orphaned
> > 
> > Sure, just like any large collection of packages.
> 
> Yes, but all the more a reason to make it easier for CentOS community
> to participate to this efforts

I am all for making it easier to contribute to EPEL, one thing to consider is 
that to contribute to EPEL you must agree to the FPCA, afaik CentOS does not 
have an equivalent and at the least Legal requires it for Fedora and EPEL

> >> 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.
> > 
> > How do EPEL maintainers launch builds in CBS?
> 
> Through bstrinson centpkg tool as for the tooling aspect
> (infra-related issues are covered in a later point)
why would it need to if we are using fedora's dist-git? It seems very very 
messy here.
 
> > How do builds get signed?
> 
> That would be left to CentOS core SIG team
Okay, I would like to know what exactly that means and entails, for one we 
have no way to export the private keys for epel from Fedora's sigul server. 
changing keys would be a pain and require a lot of careful work.

> > How do updates get pushed out to EPEL users? Does CentOS have a bodhi
> 
> Good question, from my current experience, I get little feedback on my
> EPEL updates and never got one pushed to stable just through karma.

So what can we do to add extra QA and testing? as that is what is needed to 
get builds pushed via karma. I do not see that magically being fixed.

> > instance?
> > 
> >> * EPEL will use CentOS repositories instead of mirroring RHEL
> >> repositories
> > 
> > CBS seems to not have ppc64... so no more ppc64 EPEL packages?
> 
> True, if we could get some stats over ppc64 (and any arch unsupported
> by CentOS), that would help weighting on the decision as for any
> trade-off.

We are talking about adding ppc64le aarch64 and possibly s390x to epel.  there 
is also the issue that will creap up because of the differences in how RHEL 
and CentOS ship that packages from EPEL will not be installable on RHEL when 
build on CentOS.  This is a RHEL issue, but it is nicer to track by building 
against REHL and not CentOS,  though we also discussed having i686 builds that 
use CentOS to build against

> > Also, this would probibly be some kind of big deal to some people who
> > like that EPEL is built against rhel. Personally, I don't think it
> > matters, but it would have to be communicated clearly.
> 
> (I also saw Karsten reply about it)
> It needs to be communicated, but considering CentOS good history on
> that matter, I personally don't think it's

Re: [EPEL-devel] EPEL for z Systems s390x

2015-06-23 Thread Dennis Gilmore 
On Wednesday, June 24, 2015 09:11:17 AM Dan Callaghan wrote:
 Excerpts from Bryan Chan's message of 2015-06-24 08:29 +10:00:
  Dan Horák d...@danny.cz wrote on 2015-06-23 02:31:23 PM:
   On Tue, 23 Jun 2015 13:52:41 -0400
   
   Filipe Miranda fmira...@redhat.com wrote:
This can be addressed maybe by IBM, by offering build systems to
help developers test their packages.
   
   Ack, that's something for IBM, from Red Hat side it would require
   providing RHEL for System z subscriptions to such devel systems.
   Currently we have one public guest running Fedora available to the
   community, so it should be solvable. In addition to real HW there are 2
   solutions capable running current Linux distributions under emulation.
  
  Dan, could you elaborate on the emulation aspect? Do you mean IBM zPDT
  and Hercules? I am curious if you are using emulation in the build farm
  today.
  
  IBM is currently engaging open-source software companies to encourage
  support for the platform. IBM partners can essentially get access to
  hardware for development purposes at a discount.
  
  For the community, we have a program called Community Development
  System for Linux on z, whereby open source projects can sign up for
  free access to Linux guests on our z Systems (for a limited time):
  
  http://www-03.ibm.com/systems/z/os/linux/support/community.html
  
  During registration, you can request a RHEL installation. I am not
  sure whether it comes with a RHN subscription.
  
  Other community hardware access options are now being considered, and
  I hope something more streamlined can be announced soon.
 
 One possibility is to make some z/VM guests available to approved Fedora
 contributors using beaker.fedoraproject.org, the same way that Red Hat
 engineers can use our internal Beaker instance to reserve z/VM guests.
 
 I would love to see the arches that people don't have at home, like
 ppc64 and aarch64, on beaker.fedoraproject.org too.
 
 The only big unresolved issue with beaker.fedoraproject.org right now is
 how to hook up FAS authentication. I haven't had a chance to figure that
 out yet.

A bigger issue would be having a z series machine that can be tied into 
fedora's beaker instance. Considering that there is none in Fedora space 
today. I do not imagine IT or Red Hat Security allowing some tunnel into the 
systems inside of  Red Hat. Assuming we can find hardware then sure would be 
great.

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] Summary/Minutes from today's EPEL Meeting (2015-05-15)

2015-05-15 Thread Dennis Gilmore 
=
#epel: EPSCo (2015-05-15)
=


Meeting started by dgilmore at 17:03:00 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/epel/2015-05-15/epel.2015-05-15-17.03.log.html
.



Meeting summary
---
* init  (dgilmore, 17:03:29)

* python3  (dgilmore, 17:05:19)
  * ACTION: dgilmore to add epel-rpm-macros to correct groups for comps
and koji  (dgilmore, 17:07:42)

* meeting time  (dgilmore, 17:08:01)

* restart epic discussions  (dgilmore, 17:10:31)
  * ACTION: bstinson to talk with smooge and present a plan  (dgilmore,
17:12:00)

* meeting process  (dgilmore, 17:13:40)
  * AGREED: move the meeting to #fedora-meeting  (dgilmore, 17:22:21)

* next weeks chair  (dgilmore, 17:22:31)
  * LINK: https://fedoraproject.org/wiki/EPEL-meeting-process   (nirik,
17:23:54)
  * Evolution to run next weeks meeting  (dgilmore, 17:24:13)

* open floor  (dgilmore, 17:24:32)
  * consenus is that we want to support more arches in epel. but we need
to come up with a plan and do some testing to implement  (dgilmore,
17:54:07)

Meeting ended at 17:57:50 UTC.




Action Items

* dgilmore to add epel-rpm-macros to correct groups for comps and koji
* bstinson to talk with smooge and present a plan




Action Items, by person
---
* bstinson
  * bstinson to talk with smooge and present a plan
* dgilmore
  * dgilmore to add epel-rpm-macros to correct groups for comps and koji
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dgilmore (101)
* Evolution (32)
* nirik (24)
* avij (12)
* bstinson (10)
* rsc (5)
* zodbot (3)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] wine 32

2015-05-07 Thread Dennis Gilmore 
On Wednesday, May 06, 2015 06:53:54 PM Stephen John Smoogen wrote:
 On 6 May 2015 at 18:21, ToddAndMargo toddandma...@zoho.com wrote:
  On 05/06/2015 09:31 AM, Stephen John Smoogen wrote:
  On 6 May 2015 at 00:28, ToddAndMargo toddandma...@zoho.com wrote:
  Hi Kevin and EPEL,
  
  Is there any sign of EPEL 7 support for Wine 32 yet?  The
  lack of Wine 32 is keeping me on SL 6.6 and it is starting
  to drive me nuts!
  
  EPEL: think of the guilt you would feel if I get
  stuck in an insane asylums over the lack of wine 32
  support!  Seriously, the guilt would haunt you to the end
  of your days.  Okay, maybe not, but still ...
  
  Sadly it isn't possible in EPEL. There are not enough of the i686
  libraries available to compile all the tools needed. It will require
  people actually doing the work to making an i686 CentOS or Scientific
  Linux but that only seems possible if the glibc/kernel/some other
  tools are not the same as in x86_64 and it would require people to
  actually do the work which no one has shown much effort in wanting to
  do.
  
  Hi Steven,
  
  Does this help?
  
  https://www.centos.org/forums/viewtopic.php?f=48t=49542
  
  Seems like most of the thinking has already been done.
 
 Not really. That works well for building it yourself and you should
 follow those instructions for your own benefit. It doesn't work in our
 build system for various reasons I can give hand-wavey answers to but
 Dennis Gilmore or another Release Engineer could answer in depth if
 you need. [And from my last asking about this.. it isn't something
 that can be fixed simply.]

a few issues, the biggest one is that koji enforces single arch in the 
buildroots. so we can only build i686 in a i686 chroot. since we do not have 
enough i686 content to enable building i686 its not possible that route.  the 
other way to try and do it would be to cross build the world so that we have 
x86_64 rpms with 32 bit content in them.  that would require exeptions to the 
packaging guidelines, and somoene to write new specs for every package needed 
and to get them through review.  in the end you would have to use a non rhel 
evironment and you would have say glibc32 openssl32 etc x86_64 rpms that means 
a massive support burden.  without Red Hat providing full 32 bit trees its 
just not a realistic option to support any 32 bit builds for epel7

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Process for supporting of new architectures

2015-03-10 Thread Dennis Gilmore 
On Tuesday, March 10, 2015 03:43:03 PM Michael Wolf wrote:
  Peter Robinson pbrobinson at gmail.com wrote:
  
  ...snip...
  
   1) Who is championing an architecture?
  
  Primarily IBM, but this will widen with the OpenPOWER foundation and
  it's members widening and HW from that initiative starting to become
  available. In the case of aarch64, if that happens, there will be
  similarities through Linaro Enterprise Group (LEG).
  
  Would we then have a tracker bug and a way for maintainers to call on
  these resources when/if their packages don't build?
  
   2) Where do developers get access to hardware that they can debug
   issues if they want to.
  
  I'll let Mike (from IBM) answer this one in detail but there's a
  number of Universities hosting publicly accessible instances of HW
  with a process in place, Linaro has similar process with access to
  aarch64 HW running Fedora releases.
  
  This would be good to know.
  
   3) How do we remove an architecture for whatever reasons?
 
 [Possible
 
   ones could be it turns out that CentOS i686 is dropped after one
   subrelease... or PPC64be is dropped by IBM because everyone moved
   to PPC64le. Or Itanium3 comes out and no one wants x86_64.]
  
  I don't see that would be any different to how we dropped PPC from
  mainline Fedora back in the F-12/13 timeframe but the architectures,
  once added to core RHEL, will be supported for the lifecycle of RHEL
  so I don't see that this process would be any different to how we
  dropped i686 or any of the 32 bit architectures in the transition
 
 from
 
  el6 - el7. I personally don't think it's actually worth expending
 
 too
 
  much time on this process until the issue arises, cross the bridge
  when we get there so to speak.
  
  I'm assuming we would keep ppc64 around too for now on the rhel's we
  support?
  
  ...snip...
  
  I don't see those issues any different to any of the other
  architectures or hardware that's needed to run Fedora infrastructure
  whether it be servers, storage or network. We have Enterprise
 
 support
 
  on the HW with all due process.
  
  Well, we don't have any ppc-le builders currently for EPEL.
  I guess this would need to be figured out off list first?
  
  We do have secondary arch Fedora ones, but the EPEL builders are in
 
 the
 
  primary koji, so they would need to be their own thing and have
  support, etc. I dont think we want to share builders with Fedora
  secondary ppc...
  
  We can figure this out off list tho.
 
 Some of the new P8 hardware that was recently racked is intended to be
 for EPEL on ppc64/ppc64le, I just need to get it configured and build
 VMs done etc
 
 Just out of curiosity how many systems are currently in place to do the
 EPEL builds for BE ppc64?

There is currently two builders for ppc64 

Dennis

signature.asc
Description: This is a digitally signed message part.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Meeting face to face CentOS Project and EPEL

2015-01-10 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 02 Jan 2015 01:27:16 +
Karanbir Singh kbsi...@centos.org wrote:

 hi,
 
 crossposting this to centos-devel and epel-devel
 
 we are working to arrange a meeting with the EPEL folks at Fosdem
 2015, on 31st Jan at 7pm ( venue to be confirmed ), to try and
 workout some options on how the two efforts might best co-ordinate.
 
 A key part of the conversation would also focus on how SIGs and other
 contributors to downstream repos in centos.org can interface with and
 set expectations on the epel repos.
 
 Everyone able to make it please let me know your names so I can track
 attendance and make reservations accordingly.
 
 Regards,
 

I should be able to attend, still organising travel 

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUsaKUAAoJEH7ltONmPFDRXqUP/0WbuGUuadHLZcQ3ejSxqtIY
XN86mlXV3F8GFmnY+DusrGCFeNJn2EslPVp6KosDpE3DYwyUS899kZ37N54chDBh
QqJOqd0d9sv9qQuMU+8eUqK26IbRJao78zBkiUQaCkWmRY7BOWHHzX+MFthigxzW
5wBpHrJnC14Qjd5ap2epZFl5AmoajVxawfZblAqxzUcVbF5l6s3IUuyxQM79I5XD
HRQToe6tROJk4VDb5WwWM5Y2dcUJU0WLcNsMAOin7/DluJXwbMDW3NN+HXpWDnvq
8lO/fqvMnFxT0cnCbyMl/lb/NluCSF16yHduljCqsmMjXmLgbLn+ZqCt6v5T2Zy5
NvwEpY9uSyo+jv+pXvn+3M9sgRlUTg1QUP/RKkVESUjm0ketbbizYPvD0O8eqBNV
v9euqczx3lxmNUiPV7oYvXAmFsrwlnhG7j/weiC4PJo1alJqa+lH+w7VG1XJJCnT
zviE2xwAOVOcIMTbfloIrw9vC3N5Qm1K7j4S5DcyvCHl6E5tXx1Qvpb6OJUn5JzX
KN+2sd0XiltPj7WyBsxdQhN6gOHKKcaTtqFlKrPnq27cIfgKDdO1etAWH1ocroS3
OuXWLzyFA/PZ3KJZ2YgK65u9J14Yqd6GrQFGn3h1MLSAC/VBX1kKqyEYkKgJmJM+
E6dr2/WEPr+ASbufBajV
=xpYp
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL moving epel 7 out of beta

2014-08-29 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 29 Aug 2014 07:53:06 +0200
Remi Collet fed...@famillecollet.com wrote:

 Le 28/08/2014 23:26, Dennis Gilmore a écrit :
  Hi All,
  
  Kevin and I working to move epel 7 out of beta,  as of a few hours
  ago builds require bodhi updates to get pushed out. 
 
 EPEL-7 is now on Bodhi.
 
 But trying to push an update for a freshly buld package:
 
   No package found on these branches: el7
 
 Any idea ?

Bodi has hard coded assumptions about epel and wasn't updated to deal
with the changes we made for epel7 it will be fixed today.

Dennis

 Remi.
 
 
 P.S.:
 Package: php-horde-Horde-Mime-2.4.5-1.el7
 Tag: epel7-testing-candidate
 Status: complete
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUAHCAAAoJEH7ltONmPFDRAJ0QANMyzMXn4ASbBw7gyGQevZam
tZpBUc6Nb+3tIj32cBWaC5GOOuVMeheLMWcnukCYBa63a38Z0uBk58lYfzEWh8s0
GHiKpjjp5uQSB6k8ksVQ7SFdPkAP4m9Iqg/5/CEFoj+eVFpD0EmFIVH646Zf4CmJ
u61eY1YnCKqNkaCalQro+sNTnzxli0hwfKruTIEssOqqkLHAbH+puYWB2MPXQmUw
IHh9qESQnzcB+KgOHnjy6J6LeXu1Jv3uDmwZ+no7tkA3n43ECIAFlgH8OMmdH3Id
+WV/JQWk/LfIV7YuC5RcevYwZSbL8YKhT8Oy8DMaD81LbrLbgvnigVHlhzRq/Lk+
xZYheoz5tn5m5U0BosvoNY26HJ/KV0hBdYyk8SrISr/D9JnyX+dC6keQ23Mh/ecP
ZQejcaQZH6jnmMWeTwAOcVCWFqcX9BRLYL8dhApg8icAc8arGHQYtGoUipVytDIi
am7u+M4VfQBAAtsmpe+bbGaCPih5B9gjY6RK11ClIIObMjKn41gropmKbdNWPv+O
sGjBXw9TpBzvnx2rkRLMzFUOKVrE3y4L0UHhk5scIEAYfpkZNUD0/KI9MpmLGqGS
yzNpjLd3BGYD/pV54ewQj/NCvv+kVZ6iAzhYjqTXtEY8QJTVeVb/HcFLvsSI6GQE
uG0AbZ5TPuDR1gRGBeu+
=ju0W
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL moving epel 7 out of beta

2014-08-28 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

Kevin and I working to move epel 7 out of beta,  as of a few hours ago
builds require bodhi updates to get pushed out. you can now me sure
that all packages are signed. we are cleaning up the broken deps in the
repo and moving everything that has broken deps to
epel7-testing-candidate and they will need to have updates created,
making sure to deal with the broken deps. 

Additionaly this means that the wiki can no longer be used for branch
requests. that all needs to be done via bugzilla now.

Thanks

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJT/56XAAoJEH7ltONmPFDR+V0P/17ta0bHqchHR6rtr50t1/9z
ZMBSO94HmjhHRdcS9jn1KvCXvct9T3sXFGHG5M18BT1ZF3qIB/edroEK3nfV9PEZ
vghEZZXOW1GO5w1cvaV2Y8h9l1vb3NdLHx73luzhnxol1AeTngh+1a4F6ZbDaEWx
1VcXEbLsa6l8N640ugvGJQIhP7kmXRD1Z+lyXcE1PL7GWHti2Fb8fDtnbpEzEEIv
pcbv7R667g27qpmnpZ9EGjNRgwFpaWKMnjITdr6HtwwnsG1AdKifP2TfpDyRTznn
Z9IMJNCd9e91Ost5TgsuklFrvuIc+Ye3m+BqQYMpkH2LmRCALQNvw8Ck3eq3zeIE
aOn0Q6iC1FraIHq0nON4gWomUG8d+K9eD+pU7BXTR+BkyWZns1b1YNGsGseTdR6x
NcqCargDqul/D4NY7GuAX/9SJGMHKc+f42XlzwtcTZXs3ZAclv78DsnS8EKAomWD
4wJ8j6BkUXUZcIgSmA4nUCvoOmrJbz1K5k4AET9rJndVxoP1ZFhbIt2O6HlHHQuZ
WC5eNXJxEWLx6JdZ9SBBd3czNRpo7B6lRJ+2qXgOV0SUqptKyLKbdKEzlQkGJGkF
83VFyyCzeQJG0O/FD+DKWDiLs+lyEoiPpiJgHfBjwx+AEoduzYUCWP7/K0Sf3HYz
4FqlVxE1cxt4NMjPxUxA
=I5Dp
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL zabbix for EL7

2014-08-13 Thread Dennis Gilmore 
On Wed, 13 Aug 2014 09:49:14 +0200
Patrick Hurrelmann patrick.hurrelm...@lobster.de wrote:

  Orion built zabbix22 (2.2.5) in EPEL 7 yesterday.
 
  Volker
 
 Hi Volker,
 
 I just wanted to test the packages, but the zabbix22 rpms are not
 signed. Could you please push signed rpms?
 
 Thx a lot for your and other's hard work on zabbix rpms.
 
 Regards
 Patrick
 

epel rpms are not guaranteed to be signed until we go out of beta.
releng signs them, packagers have no ability to do so.

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

Re: EPEL Notes from .next discussion.

2014-08-12 Thread Dennis Gilmore 
On Tue, 12 Aug 2014 21:05:07 +0200
Stephen John Smoogen smo...@gmail.com wrote:

 At FLOCK this year, I did a short workshop on what was labeled
 EPEL.Next. At that we went over a bit of what EPEL has done in the
 past, what its current challenges are, and what could be its future.
 Toshio Kuratomi was great in capturing what was said at the meeting
 and
 
 EPEL
 
 
 * Extra packages for enterprise linux
   * Lots of name recognition now
 * Formed as rhel5 was being released
 people needed more packages.  at the time there were a ton of addon
 repos. None of the m were compatible with each other necessarily.
 All the other repos, dag, freshrpms, etc overrode the base os in some
 places.
 
 Decided for EPEL, overriding RHEL was something we wouldn't do.
 
 Started with RHEL3,4 and soon after release we had 5.
 
 RHEL was supported 5-7years and we figured we could support EPEL
 packages for the same length of time.
 
 Early controversy - repotags (shortened name that can be in the
 packages.
 
 [graph of Fedora machines measured by unique ips that hit
 mirrormanager vs EPEL machines]
 [graph shows steady growth in EPEL.  Larger initial Fedora machines
 that rose and then plateaued]
 [graph shows a noticable dip every weekend.  Can also see the dip in
 Fedora numbers for the Incident.]
 [graph is probably conservative in numbers as many enterprises
 
 Second graph:
 [Graph shows combined growth same as last graph.]
 [Graph shows EPEL5 that has risen but plateaued about the time EPEL6
 came out.]
 [graph shows that EPEL6 has been growing and has surpassed the EPEL5
 plateau.]
 
 
 Where are we now:
 We support 3 arches.
I think you mean 3 releases. we have 3 arches for epel5 and epel6 and 2
for epel7

 RHEL4: 1258 srpms. EOL
 RHEL5: 3651 srpms
 RHEL6: 5449 srpms
 RHEL7: 3100 srpms and growing fastest
 
 For CENTOS7: the epel repofile will be shipped directly with centos
 for the first time.
 
 Current Problems:
 * 10+ year support for RHEL now.  Hard for EPEL packagers to commit to
 doing the same.
 * We have requests for both newer and older conflicting packages.
   - Currently policy is not to have unpleasant surprises regarding
 compatibility.
   - puppet2.x vs puppet3.x
 * Some people need major changes to build new software
 * Some people need no changes in order to keep existing software
 running
 * Developer burnout: People come in and after a few years, they are
 burnt out because they can't upgrade the things that they want due to
 the compatibility policies.

I think i would like to see us add an epel-extras repo where things can
change faster. Things like mediawiki, puppet, etc could go in extras.

 Where are we going?
 Pain Points:
 * Inability to yum downgrade because only include one old package in
 the updates tree
   * Harder for EPEL than Fedora because EPEL users have more need to
 rollback if an incompatibility creeps in and because EPEL users may
 schedule their releases
 * Not every part of package repo is suitable for inclusion in anaconda
 because we may not have dep closure in the subset of the repo.
   * Which RHEL point release can also make a difference because the
 base RHEL sometimes upgrades incompatibly and we don't keep a
 separate build for both point releases.
 * Can take a long time to push packages through bodhi.  Can take 7
 days to push a CVE through bodhi. (global EPEL and Fedora problem)
 * Not all maintainers interpret Don't break compatibility in the
 same way.
 * Many guidelines are verbal, not formal.
 * Some maintainers are mainly Fedora maintainers and don't know what
 people are using it for in EPEL.  They respond to requests to install
 or update a package out of a willingness to help but don't know what
 users need.
 * No guideline enforcement.
 * Takes a while for new EPEL releases to be brought out once a new
 RHEL release is made (because CentOS hasn't released yet).
   * Traditionally, we wait because contributors may not have RHEL
 entitilements so they need to have CentOS to test.
 * Need entitlements for contributors to run RHEL (Easiest: Use RHEL,
 SciLinux, Fermi Linux).
 * Packages get added to one of the RH base repositories and then we
 have to pull them from the EPEL repositories.
 * Some people have extra layered products from RH and do not want us
 to conflict with those.  Other people do not have the layered
 products and therefore want to be able to get those packages from
 EPEL.
 * Overlap between EPEL and CentOS Extras.
 
 
 Ideas to deal with Pain
 * Get RHEL licenses for contributors.  There is a process but it
 takes a long while because of the tax problems for giving it to
 people.  Current procedure is that we get requests, we give the names
 to a person inside of RH and then they eventually get back to us with
 licenses.
 * Let's create EPIC: separate repo. 3 year lifespan instead of 10
 year, rhel life cycle.
 * Debian Volatile repository and also Debian Backports.  These repos
 contain newer versions of packages, even for Debian

Re: EPEL does rhel7 support multilib?

2014-05-06 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 04 May 2014 13:16:05 -0500
Rex Dieter rdie...@math.unl.edu wrote:

 In short, because of bugs filed requesting 32bit builds,
 https://bugzilla.redhat.com/show_bug.cgi?id=1094050
 https://bugzilla.redhat.com/show_bug.cgi?id=1093964
 
 I know epel-7 only does x86_64, ppc64 archs, does RHEL7 also not
 support multilib (e.g. the ability to run x86 binaries on x86_64)?

Rhel7 does, but there is not enough i686 that epel can do multilib, so
epel7 is not goingto support multilib at all

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTaSUKAAoJEH7ltONmPFDRtE0QAIeE+1LM0KiS7H6vSSZY4bOa
dqwO7s6PjOYh5UREtfTBgrQ8MeQIJnylmeqdtyOK0CPpkrskJyKPMdshaiY98/Qj
lugQBAsc7HJ6lvVyFcU0DpwmT4Qq9MfVLPW6H586OEP5U6/F1pLYfScETr3r5A8j
293yNuuGith5cZywq0c8oQzRCF7jfNMHaLnWQ+BXUPpK2gCdNs8xQ+EgIOQUIKQy
POVjj0NBbc7RnpzKHbamWww3eD9ts+5E4ExcOdLWfsdDvTzDuD2r6mh0vOVNPoEu
lNEzEUwTL95FDQoGCUZKnZePHt63qQ3jJpEIDj/U/1kykNPJDurT7JHwGKarpJl9
/zdnvGMgKF8T4KCG/gBP4NA4ZNt/6CKd1xq3uhWYhpXHouyBRw0XNZLSpTxHo2Gs
3Hs/cxsI7po1TyjY4ox6SuHMhDLQBeUdMLnKCtjcpC1WiyDC/qmeowrYODeenvoZ
ICfHxZLeGl6Oayt+bqq/3Y4qPtNGhP86U0uTfp5VRdq19NTyq+81U+03axTRexK0
FEzj+pyNF/KkZWtkq0CWHS6Fv06e8rip9rWCHIiMlXxIWPTfck2xW+1dzb/sqdIr
Z4T47W1pzCkBSKL8/WVDsb3gY3JWrJgms2BhRMOUrnyhnEYBT5jaPeurbU7/jAa0
+ixtBJchRe1j2mcZk1Sk
=HYIf
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Project collaboration and supplementary arch support

2014-03-20 Thread Dennis Gilmore 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 18 Mar 2014 13:40:42 +0100
Simone Caronni negativ...@gmail.com wrote:

 Hello,
 
 On 18 March 2014 11:54, Jim Perrin jper...@centos.org wrote:
 
  Specifically we intend to continue producing for the i686
  architecture, as well as adding ARMv7 builds. These additional
  builds will allow users with legacy hardware (or 32bit cloud
  images) to migrate to newer versions while addressing the growing
  demand for ARM support.
 
  EPEL provides a valuable resource to CentOS (and other builds), and
  since a number of projects based on CentOS rely heavily on EPEL, we
  would like to request that support for these additional
  architectures be added to EPEL via a 'secondary arch'.
 
 
 as a contributor I would really like to have i686 as one of the main
 architectures. With the current situation, there's no chance to
 rebuild many of the packages that could benefit of RHEL 7 multilib
 support. RHEL 7 supports 32 bit programs, but we're not really able
 to use them in EPEL.
 
 Quick example: I maintain Steam for Fedora, and would like to add it
 also to the RPMFusion's EPEL repository; but the package is 32 bit
 only and there is currently no way to package 32 bit dependencies
 (like SDL2) into EPEL 7.

EPEL doesnt support multilib at all. so its really not going to help
you here.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTK2PWAAoJEH7ltONmPFDRtRgQAJRbeLVUl/wOb65xXf2SwBHU
ch0+FFcL3/Ct9vJOL0P+UKjGrtbxn64nxqTAa+OV/sotvtcQcou2s3RchykFhEwG
Jr0Tc8ERUi0/+1J8AnYrsOpvCDAULRJcLosbVLjt3Hlq35cAfiHM3pusI1/n3DK4
YvjjYjdRlONcBGmyYEa6OAqiewjHowLrJYQK4B52zdgIFfyjYLgkYVHRlmVKNkEV
BWxJE9k8c9r+0Zm8ctPgHUhCNSsCPmlOZ+CDcqAsmxjVYsHarveLgnzwDr/9zmlz
ascNquBD1eDjJhhX5DrxOxvgDqY57LWZ2lumwwx9BbH0bATQAaxwqWxI8q1uUa/E
DdRxAQkJ9thTLrPEDGK1KLpQ9oQ8xsTyAWD7kjUhsNe1+mfbnM0Ite5Fmbc2xAbg
CKsmqi+aKNEDlgoX1E73++VoFBQcsAJJT23PsPSkb8w0lgyBUQvauqzejPO76vuY
5HYyObI3GiwynAXq0FrHdw4agKZ1/S87ACm1RBft/EEIZIls7SZP5jEFVHvpJGs2
Ch5WqtM8qxp5jNPxkRJilNOVbsvrsm2+HDaSgKC/sqRfFA8Vg1zwcuaGSWVHw6ZE
0nPRrD+mVGN7HG4P/Pv3tZE+gXZgcLpAZWYx9o7hRw0t4lfHT6O6MTqYQf2yNVRZ
RzUSTktvZyEOrBAWp/+L
=pL6W
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL epel7 planning and processes

2013-12-15 Thread Dennis Gilmore 
El Sun, 15 Dec 2013 23:01:15 -0600
Dennis Gilmore den...@ausil.us escribió:
 El Thu, 12 Dec 2013 17:07:34 -0700
 Kevin Fenzi ke...@scrye.com escribió:
  Greetings. 
  
  Several folks have been asking about epel7 and we should get the
  ball rolling now that there is a public rhel7 beta. 
  
  I'd like to propose a similar plan to the one we used for epel6,
  which the possible exception of branching method. 
  
  For epel6 we asked maintainers who didn't want to branch their
  packages from epel5 into epel6 to add a 'dontbranch' file to cvs (at
  the time) and then we mass branched all the rest of the packages
  into epel6. This was good for adding in a lot of packages quickly,
  but resulted in some packages that to this day never got a build
  (where maintainers decided they didn't want to build/support, etc). 
  
  So, I was thinking this time perhaps we could: 
  
  * Setup a wiki page that contains all packages that are in
  rhel7beta. (for reference)
done https://fedoraproject.org/wiki/EPEL/epel7

  * Setup another wiki page for epel7  
  * As soon as there is a group of packages there, Branch them. 
  * Keep the wiki page open until we are out of beta/rawhide mode and
folks can mass add packages there for branching, process once a
  day or something. 
  (this would avoid overloading scmadmins if someone wanted to branch
  a bunch of packages). 
  
  Thoughts or better ideas for branching? 
  
  The rest of the process would include: 
  
  * Setup git scripts to allow epel7 branches. 
  (Default would be branch from f19)
 Done
 
  (need to decide if the git branch name is el7 or epel7).
 I went with epel7 it matches pkgdb and koji, to me it is much cleaner
 and clearer. (note you will need the fedpkg update that I built today
 to build.
 
  * Create gpg keys and add to signing server/verify pages. 
 gpg keys created, need to finish the steps
 
  * Branch epel-release and add keys, etc.
 Done 
  * Add koji tags and build targets, etc. 
 Done
 
  * Add bugzilla version for bugs. 
 Added, i also disabled epel4
 
  * Probibly some wiki help to update things 
  * Setup nightly cron job that composes epel7 in rawhide mode. 
 Just needs some tweaking and enabling should be done soon.
  * Don't depend on packages being signed until we exit rawhide mode. 
 
 epel.repo has gpgcheck=0 currently. Im open to changing it. but we
 can't guarantee that all packages are always signed.
 
  * Move from rawhide - normal mode some time after rhel7 final is
  out (with 6 it was a few months after). 
 I think we waited for CentOS 6 to come out
  
  Can anyone think of other things we need to do?
  
  Any other general questions or comments ?
  
  kevin
 



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