[EPEL-devel] EPEL8 ?

2019-06-04 Thread Jim Perrin


On 6/4/19 6:25 AM, Miroslav Suchý wrote:
> What is the status of EPEL8? Or more precise - can I - as Mock maintainer - 
> do something so we can have EPEL available
> immediately when RHEL is out? Obviously it is too late for RHEL 8, but I am 
> looking in future (RHEL9).
> 

In the immediate term, there isn't much that can be done by interested
contributors, but I appreciate the offer and willingness to help.
Without getting too into the weeds, we needed to have tooling changes
landed for handling modules, and ursine packages as well as a few
updates to koji in order to make this work, as well as some creative
scripting by the Infra team to plumb it all in. We are working through
this and in typical community fashion "it'll be released when it's
ready". We know folks want EPEL and we're working it as fast as we can.

For the future, I'm working with RHEL leadership to make sure this is
taken into account for the planning process. I make no promises, but I
am making it known.




-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-15 Thread Jim Perrin


On 05/15/2018 12:06 PM, Stephen John Smoogen wrote:



>   Modules
> 
> EPIC-6
> 
>Because EL-6’s tooling is locked at this point, it does not make
>sense to investigate modules.
> 
> EPIC-7
> 
>Currently EL-7 does not support Fedora modules and would require
>updates to yum, rpm and other tools in order to do so. If these
>show up in some form in a future minor release, then trees for
>modules can be created and builds done.
> 


I *think* the version of rpm has been bumped enough as of EL 7.5 to
support the tooling needed for modules. This would clearly need to be
verified, but if this is the case then modern version of dnf may be all
that's required.


> EPIC-next
> 
>The tooling for modules can match how Fedora approaches it. This
>means that rules for module inclusion will be similar to package
>inclusion.  EPIC-next modules must not replace/conflict with CentOS
>modules. They may use their own namespace to offer newer versions
>than what is offered and those modules may be removed in the next
>minor release if CentOS offers them then.
> 


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

2017-08-03 Thread Jim Perrin


On 08/01/2017 10:05 AM, Stephen John Smoogen wrote:

> I will bring this up at the meeting tomorrow, but I believe that the
> plan would be something like the following:
> 
> 1. "Update" the current package with README.deprecated explaining why
> the package is being removed from the repository and what a user needs
> to do to get newer versions. A /usr/share/docs/ceph/upstream-ceph.repo
> may also be useful. [Putting in a Summary that the package is deprecated
> may also be useful.]
> 2. Announce on epel-devel and epel-announce this is going to happen.
> 2. push the update out to users.
> 3. orphan the package in EPEL
> 4. remove it after a month after the update went to stable. 
> 
> We also need to look at coming up with tools and a process to better
> look at packages we have in the repository so we don't make both the
> maintainer (aka Kaleb) and the users lifes miserable. 
> 
> Does the above sound reasonable ?
> 


I think that's the best course of action.

+1 here.




-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org


[EPEL-devel] Re: Requirements for SRPM names

2016-09-13 Thread Jim Perrin


On 09/13/2016 01:28 PM, Stephen John Smoogen wrote:
> On 13 September 2016 at 14:13, Avram Lubkin <av...@rockhopper.net> 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.".
>>
> 
> Limited arch packages are ones where you are building something for
> say ppc or aarch64 which has a RHEL package already in x86_64 but no
> corresponding RHEL ppc or x86_64 one. The reason to put a 0. in front
> is that sometimes RHEL does offer such packages later in a release
> cycle and we want that version to overwrite anything we built to
> satisfy a dependency. [Also if CentOS builds all the packages for
> their port of EL-X to PPC or aarch64 we do not conflict with their
> packages.]
> 
> This is only meant for that case.
> 
>> 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.
>>
> 
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
> 
> My personal take is that all python3 apps should be called python3 in
> their names and all python2 apps should have been called python2 as
> every time python does these major updates we end up with years of
> maintaining this split brain damage which lasts longer than the
> language version exists.



I'm in the process of working through this for a few python bits for
EPEL7. While I generally agree, it's problematic at times because the
fedora sources provide a sane split for this, while the EL sources do
not. This occasionally means creating a new package just for EPEL rather
than simply branching the fedora tree.


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: Strategy for Node.js upgrade in EPEL 7

2016-09-13 Thread Jim Perrin


On 09/13/2016 08:28 AM, Stephen Gallagher wrote:

>> Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be
>> cutting over to 6.x on or around that date, so this testing request is
>> time-sensitive.

I'm wondering if it might not be prudent to put something in fedora
magazine about this that we could redistribute or link-to for CentOS as
well. This change seems like it deserves making some community noise
beyond some threads on the mailing list.


Thoughts?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org


Re: [EPEL-devel] [Fedocal] Reminder meeting : EPSCo weekly meeting

2015-06-05 Thread Jim Perrin
This meeting will be canceled as most of the EPSCo members are attending
the FAD.

On 06/05/2015 12:00 AM, den...@ausil.us wrote:
 Dear all,
 
 You are kindly invited to the meeting:
EPSCo weekly meeting on 2015-06-05 from 17:00:00 to 18:00:00 UTC
At e...@irc.freenode.net
 
 The meeting will be about:
 
 
 
 Source: https://apps.fedoraproject.org/calendar/meeting/2542/
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Python3 vote

2015-03-20 Thread Jim Perrin
+1 from me as well.

On 03/19/2015 05:57 PM, Stephen John Smoogen wrote:
 At the last meeting I promised we would hold a vote on the Python 3 on the
 mailing lists. I got sidetracked after the meeting and never got to calling
 a vote on it. However in that time I haven't seen any complaints from the
 EPSCO members so would like to just have a +1/-1 vote by tomorrow on the
 proposed python3 item
 
 https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3
 
 I am +1 on this.
 
 
 
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] Need help with SL 7, Wine, and 32 bit problem

2014-11-03 Thread Jim Perrin


On 11/03/2014 04:37 PM, ToddAndMargo wrote:

 Are there 32 bit libraries somewhere out these for this version
 of Wine?
 


Currently no, not for EL7.



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


[EPEL-devel] appdb quirk for EPEL7 packages

2014-10-23 Thread Jim Perrin
In going through some of the security updates for EPEL 7, I've noticed a
few quirks, and I'm unsure of the cause/design.

Example - https://apps.fedoraproject.org/packages/nginx

This does not show an EPEL7 build, even though there clearly is one (and
it's flagged for a security update
https://bugzilla.redhat.com/show_bug.cgi?id=1126892).

The same thing happened with thunderbird (
https://apps.fedoraproject.org/packages/thunderbird) as well. I'm going
to continue going through the EPEL7 security bugs, to see if this is
consistent behavior, or if the first two packages I saw were oddities.

Is there something that would cause them to not show up in appdb as
being part of epel7?

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] EPEL Cloud-init in -7

2014-10-22 Thread Jim Perrin


On 10/11/2014 04:13 PM, Sam Kottler wrote:

 
 I’m the primary maintainer in EPEL + Fedora. Would certainly be able to help 
 on the CentOS side as well and apply patches as needed.


While some of the patches have different names, it looks like we
(CentOS) have 4 patches that are not included in the epel cloud-init.
Everything else is (other than the configured username).

These add support for cloudstack and opennebula as providers, as well as
fixing a hostname issue for centos 7 users.

Sam, would you review the linked patches and commit them into the epel7
cloud-init?

https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-hostnamefix.patch

https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-opennebula.patch

https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-opennebula-requiretty.patch

 
https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-cloudstack-urlhandling.patch



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL CentOS curator group proposal

2014-09-25 Thread Jim Perrin
Earlier this week on the CentOS devel list I proposed an interim method
to help make it easier for centos contributions to flow into epel.

Essentially the proposal is that CentOS would like a 'curator' group
(name can be determined later) similar to the wrangler's group.

Members of this group would be responsible for shepherding packages
designated by the various SIG efforts in CentOS through the process of
getting these packages in epel. This means that rather than having an
individual owner, packages would have group ownership. Members of this
group will be required to have access to make package modifications on
the CentOS side so that they meet the packaging standards for EPEL.
Additionally, it would help to have an EPEL proven packager as part of
the group as well in order to help make things move a little quicker.

Would this be acceptable from an EPEL standpoint? What would be required
from an EPEL perspective to make this happen?





-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL CentOS curator group proposal

2014-09-25 Thread Jim Perrin


On 09/25/2014 10:28 AM, Steve Traylen wrote:
 Excerpts from Antonio Trande's message of 2014-09-25 17:15:45 +0200:
 Hi Jim.

 On 09/25/2014 04:36 PM, Jim Perrin wrote:
 Earlier this week on the CentOS devel list I proposed an interim method
 to help make it easier for centos contributions to flow into epel.

 Essentially the proposal is that CentOS would like a 'curator' group
 (name can be determined later) similar to the wrangler's group.

 Members of this group would be responsible for shepherding packages
 designated by the various SIG efforts in CentOS through the process of
 getting these packages in epel. This means that rather than having an
 individual owner, packages would have group ownership. Members of this
 group will be required to have access to make package modifications on
 the CentOS side so that they meet the packaging standards for EPEL.
 Additionally, it would help to have an EPEL proven packager as part of
 the group as well in order to help make things move a little quicker.

 Would this be acceptable from an EPEL standpoint? What would be required
 from an EPEL perspective to make this happen?

 EPEL is for RHEL, Scientific Linux, Oracle Enterprice other than CentOS; 
 would we need of special curator group for every distro?
 CentOS contributions could flow simply by taking part on EPEL and by 
 integrating any special (previously discussed) packaging need .

I don't see that this prevents any other groups from participating at
all. The idea is for the benefit of the other groups as well, as they
ultimately would get a larger package set to use.

 This would be my take also, getting pkgs into EPEL is a pretty well
 defined process as is a becoming a packager. I don't see an extra step/group 
 is needed within CentOS is needed.  

It is defined. It's also perceived as cumbersome, laborious and painful,
and so many would-be contributors don't even attempt to contribute. This
is simply a proposal allowing those who are willing to act in place of
the original packagers to help contribute. This benefits every group
mentioned above, instead of keeping packages within the project.


 Group ownership of pkgs in EPEL? So many people can own a package
 already. I am unsure what the 'wrangler' group example is.

Why list 10 owners when you can list a single group?

Wranglers discussed and defined during last week's meeting:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-September/010153.html


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL CentOS curator group proposal

2014-09-25 Thread Jim Perrin


On 09/25/2014 12:22 PM, Till Maas wrote:
 On Thu, Sep 25, 2014 at 09:36:07AM -0500, Jim Perrin wrote:
 
 Members of this group would be responsible for shepherding packages
 designated by the various SIG efforts in CentOS through the process of
 getting these packages in epel. This means that rather than having an
 individual owner, packages would have group ownership. Members of this
 group will be required to have access to make package modifications on
 the CentOS side so that they meet the packaging standards for EPEL.
 Additionally, it would help to have an EPEL proven packager as part of
 the group as well in order to help make things move a little quicker.

 Would this be acceptable from an EPEL standpoint? What would be required
 from an EPEL perspective to make this happen?
 
 Can you please be more detailed about who should get which privileges
 and how? E.g. do you want to become the new members packagers without
 being properly sponsored?

Very much no. Members of this group would be submitting packages on
behalf of those in the CentOS community who don't wish to do so
themselves. If the package doesn't measure up, it gets no special
treatment and would be fixed prior to acceptance.

Members of this group would be required to go through the usual
sponsorship/submission practices, etc.

 
 Also do you plan to not use Fedora's git repository to build packages
 from?

These packages may not necessarily start off in fedora's git, but per
EPEL policy they should end up there if they're to be built for epel. I
would imagine most are likely already in fedora's git as the upstream,
and would require only branch+patch ownership.

 
 Technically, support is already possible by just becoming packagers,
 since there is also group ownership in the package database.

Yes, but I'm told this is not generally common practice, which is why I
wanted to bring it up here first to make sure it's not a problem.


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL CentOS curator group proposal

2014-09-25 Thread Jim Perrin


On 09/25/2014 12:27 PM, Till Maas wrote:
 On Thu, Sep 25, 2014 at 11:47:43AM -0500, Jim Perrin wrote:
 
 This would be my take also, getting pkgs into EPEL is a pretty well
 defined process as is a becoming a packager. I don't see an extra 
 step/group 
 is needed within CentOS is needed.  

 It is defined. It's also perceived as cumbersome, laborious and painful,
 and so many would-be contributors don't even attempt to contribute. This
 is simply a proposal allowing those who are willing to act in place of
 the original packagers to help contribute.
 
 If the packages are going to meet Fedora's guidelines, the current
 process is not as bad as it might be perceived. If someone is qualified
 and motivated it is very easy to become package maintainer and if you
 have several people who want to contribute they can easily review each
 others packages to show that they are qualified and I am very confident
 that it won't be hard to find a sponsor then.

I don't disagree. It's partly the perception that's keeping people from
attempting it. I'm hoping that this would provide a method to help
smooth that perception over.

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Cloud-init in -7

2014-09-09 Thread Jim Perrin


On 09/09/2014 10:02 AM, Karanbir Singh wrote:
 hi guys,
 
 The cloud-init is causing lots of issues and we need to workout how best
 to handle this.
 
 We have a cloud-init in the CentOS Instance SIG that is curated locally,
 based off the last EL7 cloud-init ( 0.7.5 ); but there is now a
 cloud-init in epel7 as well, which has a different patchset but higher
 Release id.
 
 I could now go and build a higher Release, but can we workout a better
 longer term solution to stuff like this ?

As the patches used in the CentOS package have been accepted upstream,
perhaps they could be merged into the epel package so that there's only
one shipped.



Alternatively, is cloud-init an actual shipped RH package that should be
excluded/blacklisted from epel?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Reformed Steering Committee

2014-09-01 Thread Jim Perrin


On 08/29/2014 08:32 PM, Carl George wrote:
 Howdy!
 
 Currently the ius-release package depends on epel-release.  This is because 
 several of our packages have dependencies from EPEL.  Would these new 
 proposed repos be supplementary to the current EPEL, or something else?

Correct. EPEL currently has a large user-base, and some basic
expectation for how it should function. Changing that would do more harm
than good.

These repositories would be in addition to the existing EPEL structure.

 
 Here are the current IUS mailing lists.
 
 Core developers:
 core...@iuscommunity.org
 ius-core...@lists.launchpad.net
 
 Community members:
 ius-commun...@lists.launchpad.net
 
 Carl George
 Rackspace GNU/Linux Engineer
 
 From: Rahul Sundaram [methe...@gmail.com]
 Sent: Friday, August 29, 2014 07:38 PM
 To: EPEL Development List
 Cc: core...@iuscommunity.org
 Subject: Re: EPEL Reformed Steering Committee
 
 Hi
 
 
 On Fri, Aug 29, 2014 at 5:12 PM, Stephen John Smoogen 
 smo...@gmail.commailto:smo...@gmail.com wrote:
 
 
 
 On 29 August 2014 15:03, Rahul Sundaram 
 methe...@gmail.commailto:methe...@gmail.com wrote:
 Hi
 
 
 On Fri, Aug 29, 2014 at 2:48 PM, Stephen John Smoogen wrote:
 At last week's EPEL meeting, it was proposed that at least a short term 
 governing committee be put together to help on the following items:
 
 1) EPEL.next (EPIC or EPEL-rolling, etc)
 
 Has there been any attempt to bring in the people working on IUS repository?  
 Perhaps their needs could be considered when launching new sub repositories
 
 
 Not yet. It is a good idea to bring up at this point. Are there any IUS 
 people on the list already? Or do you know people we should contact? [The IUS 
 lists I am on are very very quiet so I am not sure who that would be these 
 days.]
 
 I am adding their contact email in CC
 
 Rahul
 
 
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Reminder: 2014-08-29 meeting #epel

2014-08-28 Thread Jim Perrin


On 08/28/2014 05:11 PM, Stephen John Smoogen wrote:
 We will be holding our weekly EPEL meeting tomorrow at 1600 UTC.
 
 Topics will be:
 
 1) EPEL-7 moves out of Beta
 2) EPEL.fill-in-blank
 3) Open Flood.


I regret that I won't be able to make the meeting this time around. I
brought up a few things off-list that may be worth discussing.


If this is to be a regular meeting time, I'll certainly be able to
attend the next.

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Proposed meeting: Fri Aug 22 16:00:00 UTC 2014

2014-08-15 Thread Jim Perrin


On 08/14/2014 06:51 PM, Stephen John Smoogen wrote:
 I am proposing that the EPEL community hold a meeting in #epel on Friday
 August 22, 2014 16:00:00 UTC to go over various community items:

I'll be there.

 Suggested topics:
 
 #topic Forking of EPEL packages to a faster moving repository
 
 a) Proposed name of repository is EPIC
 b) What packages stay, which packages go.
 
 #topic Setup and controls for said repository
 
 When do packages update in EPIC repository, how are they announced and
 where?
 
 #topic Review and cleanup of EPEL policies
 
 There was a problem with several packages being removed which broke other
 packages. These packages were removed because we have in the past not allow
 orphaned or non-maintain packages.. but where is this documented.
 
 #topic Open Floor
 
 Place for the meeting will be in #epel
 
 To determine when this meeting occurs in your timezone please type:
 
 date -d '2014-08-22 16:00:00 UTC'
 
 example:
 
 [smooge@seiji ~]$ date -d '2014-08-22 16:00:00 UTC'
 Fri Aug 22 10:00:00 MDT 2014
 
 
 
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
 

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
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-13 Thread Jim Perrin


On 08/13/2014 09:23 AM, Kevin Fenzi wrote:
 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
 
 ...snip...
 
 For CENTOS7: the epel repofile will be shipped directly with centos
 for the first time.
 
 Note that this will be in centos-extras (but thats enabled by default,
 so just a nitpick)
 
 ...snip...
 
 Where are we going?
 Pain Points:
 * Inability to yum downgrade because only include one old package in
 the updates tree
 
 Yeah, there were some recent mash patches that might help here.
 Allowing us to keep 1 or 2 older ones too. 
 
 ...snip lots of problems... 
 
 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.
 
 We are working to revamp/improve this. 
 
 * 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 Stable.  Good for
 packages which change all the time.
 * Debian also has protection mechanism that says no major or no
 major.minor version updates in apt (their yum equivalent).
 * Red Hat already releases different lifecycle repositories (layered
 products).  Why not replicate what they do.
 * What about implementing EPEL as a set of projects like Fedora
 Playground?
   * Would change the guarantees and expectations of EPEL *quite* a
 bit.
   * Maybe as the way to implement EPIC rather than EPEL.
 
 I think we really do need to look at another repo for things that are
 so rapid. It's going to be very hard to change user expectations for
 EPEL now, since it's already entrenched. 

I don't think these two options are exclusive.

A second repository would certainly help keep original expectations of
epel in place, and is a good idea.

EPEL itself still provides a base for many projects, and could improve
upon existing user expectations.

 I guess for my uses the parallel installable stuff works fine. I know
 thats not the case for others though, so a more rapidly moving repo
 would be better for them. I wonder if it wouldn't be good to coordinate
 with CentOS folks and see where such a repo would make the most sense? 

I certainly think we should do this. It would benefit both our SIG
communities as well as other interested users.


 The idea of having a release tree was an interesting one. However, it's
 going to be a lot more work. If we are saying here's EPEL 7.0 release
 repo we would need to make sure it's well tested and has no issues.
 ie, we would need to go through much of what Fedora does for a release. 
 Do we have any QA folks at all? ;) 

I believe there's an effort for common QA underway. This would be an
area where we (CentOS and Fedora/EPEL) could coordinate.

 I think more practical might be the idea of shipping multiple old
 versions in the existing repos. 
 
 * Formalize the governance of EPEL.
   * Written policies of some sort for decision making
   * Elections?
   * Problems to solve:
 * Don't want to just listen to the people who are loudest
 * Don't want to just listen to the people who have been around the
 longest
 
 I'd prefer to avoid voting those that do the work should have the
 most input. Or perhaps those that show up. ;) There was some talk about
 trying to do meetings again. I gave up in dispair last time I tried,
 but would happily attend if someone else wants to organize them. 
 
 * Do we want automated testing of EPEL?  yes.  get it working on
 whatever subset you can and we'll go on from there.
 
 Yeah, I would love some automated testing. 

This should be possible in the reasonably near future.


 
 * Move to CentOS as build system?  Gives us additional arches.
 
 Yeah, if they do a 32bit x86 and 32bit arm, that would give us more
 arches. 

32bit x86 is definitely happening. I'm not certain about 32bit arm,
largely because of the largely varied hardware support requirements and
uboot.

64bit arm(uefi backed) is certainly on our roadmap.



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL several yum priorities exclusions in el6 noticed

2014-06-27 Thread Jim Perrin
-devel-3.0-13.el6.i686 from epel excluded (priority)
 -- freerdp-devel-1.0.2-1.el6.x86_64 from epel excluded (priority)
 -- perl-IO-Tty-1.08-3.el6.x86_64 from epel excluded (priority)
 -- perl-UNIVERSAL-can-1.15-1.el6.noarch from epel excluded (priority)
 -- perl-MIME-Types-1.28-2.el6.noarch from epel excluded (priority)
 -- perl-Module-Find-0.08-3.el6.noarch from epel excluded (priority)
 -- perl-Devel-Cycle-1.10-3.1.el6.noarch from epel excluded (priority)
 -- xerces-c-devel-3.0.1-0.20.1.el6.i686 from epel excluded (priority)
 -- perl-Pod-Spell-1.01-6.1.el6.noarch from epel excluded (priority)
 -- perl-String-Format-1.15-2.1.el6.noarch from epel excluded (priority)
 -- xerces-c-devel-3.0.1-0.20.1.el6.x86_64 from epel excluded (priority)
 -- wordnet-devel-3.0-13.el6.x86_64 from epel excluded (priority)
 -- perl-Font-AFM-1.20-3.1.el6.noarch from epel excluded (priority)
 -- lzop-1.02-0.9.rc1.el6.x86_64 from epel excluded (priority)
 -- wxGTK-2.8.12-1.el6.i686 from epel excluded (priority)
-- xerces-c-3.0.1-0.20.1.el6.i686 from epel excluded (priority)
 -- perl-Test-Perl-Critic-1.01-7.1.el6.noarch from epel excluded (priority)
 -- wxGTK-devel-2.8.12-1.el6.i686 from epel excluded (priority)
 -- wxGTK-2.8.12-1.el6.x86_64 from epel excluded (priority)
 -- perl-Class-MethodMaker-2.15-2.el6.x86_64 from epel excluded (priority)
 -- python-urwid-0.9.9.1-1.el6.x86_64 from epel excluded (priority)
 -- perl-Test-Spelling-0.11-5.1.el6.noarch from epel excluded (priority)
 -- perl-Class-Data-Inheritable-0.08-0.3.1.el6.noarch from epel
excluded (priority)
 -- freerdp-plugins-1.0.2-1.el6.x86_64 from epel excluded (priority)
 -- perl-Syntax-Highlight-Engine-Kate-0.04-5.1.el6.noarch from epel
excluded (priority)
 -- perl-UNIVERSAL-isa-1.03-1.el6.noarch from epel excluded (priority)
 -- perl-B-Keywords-1.09-3.1.el6.noarch from epel excluded (priority)




-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL quick epel7 update

2014-06-16 Thread Jim Perrin


On 06/16/2014 02:49 PM, Simone Caronni wrote:

 In previous releases CentOS was inserting in the distribution all the
 packages that make up the full spectrum of RHEL variants, so in version 6
 it included for example the Workstation channel and a full Workstation was
 installable for CentOS 6 (in fact all the content never fit into 1 dvd). As
 far as I know they are not changing this policy.
 

We aren't.


 By using CentOS as the basis and not RHEL 7 we could have all the channels
 that are not used at the moment for building.


As much as I'd like to see CentOS as the basis for *everything* (I may
be a bit biased here), I don't think this is a good idea.

RHEL packages by their very nature will come out first. This puts EPEL
in a position to work with them immediately, and to remain impartial
across the rebuilding community (springdale/puias, centos, SL, that
database company, etc). If CentOS lags behind for some unforseen reason,
why put everyone else out until we get our act together? Same with every
other rebuild. We know RHEL packages will be out on time every time
because they're the ones delivering them.

To me, the only current time it would make sense for CentOS to be the
base repo would be for something RHEL doesn't ship, such as x86 or other
arch.



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL quick epel7 update

2014-06-16 Thread Jim Perrin


On 06/16/2014 02:39 PM, Simone Caronni wrote:
 On 16 June 2014 21:28, Kevin Fenzi ke...@scrye.com wrote:
 
 On Mon, 16 Jun 2014 21:03:57 +0200
 Simone Caronni negativ...@gmail.com wrote:
 CentOS 7 is being built also for i386 and that would
 mean a lot of semplification into adding packages in EPEL 7. Right
 now the situation is a bit weird as many multilib dependencies cannot
 be satisfied and there are many obstacles in getting i386 binaries to
 run.

 That however, is another kettle of fish. ;)

 So, you are suggesting we move to building against CentOS instead of
 RHEL and support 32bit? Where is the CentOS 32bit effort at?

 
 As far as I know they are coming out with a completely installable i386
 tree on release date. A quick look hints that all of the packages are being
 built for 32 bit as well:


We are doing this, however not as the core distribution, but as a
special interest group effort. We cannot promise that we can sustain it
for the full life of EL7.

I had cornered Kevin and Dennis earlier this year to discuss the
possibility of adding the 32bit version as a secondary arch, however
they both (wisely) wanted to see how it turned out before committing.

Since we're the only ones doing 32bit that I'm aware of, it has less
user impact. Lets get EPEL7 proper out the door first and then openly
discuss adding the x86 secondary arch.


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL xsensor GUI Failed, any bug reports?

2014-06-11 Thread Jim Perrin
You sent this yesterday as well, and it was politely ignored, as it's
not really a question for this list.

Bugzilla was working fine yesterday. It's working today as well. Please
check and fix your network connection.

On 06/11/2014 02:52 PM, ToddAndMargo wrote:
 Hi,
 
 Scientific Linux 6.5, 64 bit
 
 I can not get Red Hat's bugzilla to work (502 proxy error).
 
 Does anyone know is there is a bug report against
 xsensors for GUI Failed?
 
 $ uname -r
 2.6.32-431.17.1.el6.x86_64
 
 $ rpm -qa xsensors
 xsensors-0.73-1.el6.x86_64
 
 
 Many thanks,
 -T
 
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel

-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL thoughts or views on packages deliberately left out of rhel?

2014-04-29 Thread Jim Perrin
The RC for el7 specifically omits packages that have drawn interest in
the past. A few examples of such packages would be kmail and pidgin.

kmail is ordinarily part of the kde-pim suite, but is stripped from the
final build via some 'rm' handiwork in the spec. Pidgin is omitted from
the build via a check to see if the build host is rhel. The libs are
used and included, but the binary is no longer produced.

I'm curious to know if anyone from the epel side has thought about how
these might be included. This doesn't appear to be a more
straightforward case like thunderbird, but would require some prep-work
to not overwrite core packages.

Thoughts as to how this might be accomplished?


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77


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


EPEL group creation requests.

2014-03-28 Thread Jim Perrin
With cinnamon and mate being added for epel7, how would one go about
requesting that groups be created for them, similar to the xfce group?


-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL EPIC! [was Re: and SCL]

2014-03-21 Thread Jim Perrin


On 03/21/2014 11:49 AM, Sam Kottler wrote:
 
 
 - Original Message -
 From: Peter Lemenkov lemen...@gmail.com
 To: EPEL Development List epel-devel@lists.fedoraproject.org
 Cc: rberg...@fedoraproject.org
 Sent: Friday, March 21, 2014 6:25:50 PM
 Subject: Re: EPEL EPIC! [was Re: and SCL]

 2014-03-21 16:07 GMT+04:00 Matthew Miller mat...@fedoraproject.org:

 It doesn't exist, it's an idea that Robyn has floated semi-seriously
 as a way to provide a repo that moves faster than EPEL. Rather than
 try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
 Packages for Infrastructure and Cloud (EPIC) that had a different,
 faster-moving charter. EPIC would target the *EL platform just as EPEL
 does.

 Faster moving rate is great indeed. But adding more than on version of
 software (no matter of how many repos it takes) means only one - we
 have to impose additional support requiremetns on a packagers.

 The social contract requiremens for EPEL support (which of souce
 isn't a real support) is way too high for the average maintainer.
 That's the reason I believe the entire EPEL idea was a huge mistake
 and waste of time - unfortunately I failed to discuss this with other
 fellow fedora members during FOSDEM Fedora.NEXT related talks.
 
 Completely agreed about the issues surrounding maintenance and security 
 backporting. Even upstreams that are supportive of packaging in distros just 
 *can't* support a basically randomly supported of their software for 10 
 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that 
 direction because the upstreams simply don't have the manpower to be able to 
 work with the software is packaging a (4|8) year old version of their 
 software. Additionally, most people who run enterprise linux expect ABI/API 
 and upgrade stability so maintainers resort to changing their packages as 
 little as possible. That manifests itself as neglect.
 
 I'd love to see EPIC happen, as I've been telling robyn for the past year and 
 a half :-)


So, lets lay out a couple assumptions and improvements and see where we
end up.

What are the needs and wants for both packagers and users?
What are the lessons to learn from EPEL when creating EPIC?
Does one repository solve this, or would this need to be a project
structure with multiple repositories underneath?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL Project collaboration and supplementary arch support

2014-03-18 Thread Jim Perrin
In preparation for the launch of EL7 and due to community demand, the
CentOS Project will be providing additional arch support not included in
RHEL. 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'. This would be similar to the
Fedora distro structure regarding PPC64 and s390x, so that the impact to
the existing EPEL build structure should be minimal. Since adding arch
support can complicate packaging,  we would offer that the SIG
maintainers of these additional architectures provide assistance where
possible in the event that some packages don't build properly. I don't
want to duplicate the efforts already made by the EPEL contributors to
supplement the base packages provided in the distribution simply for
arch support, especially when much of the work is already handled via
Fedora's git infra.

Is this proposal acceptable to the EPEL devs and contributors?



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel