[EPEL-devel] EPEL8 ?
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
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 ?
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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.
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
-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
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
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?
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?
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.
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]
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
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
