[EPEL-devel] Contact to Oracle Linux EPEL repo maintainer

[Peter Soppe]

Hello EPEL Team,

I am trying to find out how to contact the maintainer of the Oracle Linux
EPEL repository.
The only website I found about EPEL and Contact is
https://fedoraproject.org/wiki/EPEL/FAQ#contact

My current issue is that I use the Oracle Linux 8 EPEL package "cacti" -
and there is a security issue that is solved in cacti Version 1.2.27
(2024-05-12).

This version is available in the Fedora/RHEL Epel
https://packages.fedoraproject.org/pkgs/cacti/cacti/  since 2024-05-21 (9
days after release)
but not in the Oracle Linux EPEL:
https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/index.html
Here the latest available Version is 1.2.23 (2023-01-13) which is about 19
months old.

I want to know if there are plans to update the cacti version in the Oracle
EPEL repo and if yes what is the planned timeline to do so.

Best regards,
  Peter Soppe

-- 
Peter Soppe
Email: pe...@soppe.net
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: [EXT] Re: Does EPEL 9 Koji have older c9s packages than local mock?

[Peter Georg]

On 26/04/2022 13.00, Miro Hrončok wrote:

On 22. 04. 22 19:53, Miro Hrončok wrote:

Hello,

I've been trying to debug a segfault during %check that only occurs in 
epel9 Koji, but not in mock.


At the end, I compared the list of packages with:

$ koji list-buildroot 34845388 | sort > koji
$ mock -r centos-stream+epel-9-x86_64 shell -- rpm -qa | sort > mock
$ diff -u koji mock | grep -v ' '
+acl-2.3.1-3.el9.x86_64
-audit-libs-3.0.7-101.el9.x86_64
...

This seems like my local mock has newer c9s packages than the Koji 
build repo. Is that expected, or is pulling c9s packages into the 
build repo stuck on Koji side?


Actually, I got an idea that EPEL 9 Koji might already be using 
(internal?) RHEL 9.0, possibly I have missed this switch... However, 
the centos-stream-release package contraditcs taht idea :/


I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g. 
pyproject-rpm-macros-1.0.1-1.el9.



Thanks for all the answers -- I see them in the archives but never 
received them :(


Was this "freeze" ever announced somewhere? I might have missed that as 
well, considering I am clearly missing some email.


The only announcement about this "freeze" I can remember was part of the 
"CPE Weekly Update – Week of February 28th – March 3rd" which was at 
least sent to de...@lists.fedoraproject.org and centos-de...@centos.org.

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Questions about installing epel-release

[Peter]

On 1/07/20 10:07 pm, Dominik 'Rathann' Mierzejewski wrote:

This looks fine, although it seems it was re-signed with CentOS signing
key.
CentOS packages epel-release in the extras repo, so this is normal when 
it's installed that way.



Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Questions about installing epel-release

[Peter]

On 30/06/20 8:13 am, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 29 June 2020 at 03:27, Wei, Catherine wrote:

Thanks. I fixed this by changing the reposdir=/etc/yum.163.yum.repos.d
to /etc/yum.repos.d/, then the epel repository can be found.


There are no such references in the epel-release package.


This would have been a change made by the user before installing 
epel-release, or possibly it came from some panel software, or a VPS 
vendor or ... who knows, but crazy things get done by prior admins, 
clueless vendors, etc.



Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: RHEL 7.5 for aarch64

[Peter Robinson]

On Fri, Apr 13, 2018 at 2:41 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> The aarch64 config is 'special' in the general config and was
> hardwired to pulling 7.4. I am updating it to 7.5 and will see what
> other changes might be needed.

Can we add this to the SOP as it's not the first time it's happened :)

> On 13 April 2018 at 02:52, Peter Robinson <pbrobin...@gmail.com> wrote:
>> You should likely ask that on the epel-devel list, but I've added
>> smooge in as he's the EPEL lead.
>>
>>
>>
>> On Fri, Apr 13, 2018 at 6:22 AM, Bojan Smojver <bo...@rexursive.com> wrote:
>>> Anyone knows when RHEL 7.5 packages will be available for aarch64 in
>>> koji, so that new dependencies get picked up? I'm trying to build EPEL7
>>> xorgxrdp against the latest xorg-x11-server and all other arches have
>>> 1.19.5, but aarch64 is stuck on 1.19.3.
>>>
>>> PS. Buildroot overrides don't work here, AFAICT.
>>>
>>> Thanks,
>>> --
>>> Bojan
>>> ___
>>> devel mailing list -- de...@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Ansible in EL7

[Peter Robinson]

On Wed, Apr 11, 2018 at 12:58 AM, Todd Zullinger  wrote:
> James Hogarth wrote:
>> I was under the impression that as of 2.4.0 in EL7 we removed ansible
>> from EPEL7 since Red Hat included it in their extras repo, and EPEL
>> policy is not to conflict.
>>
>> I was surprised just now to see ansible 2.5.0 on a test centos system,
>> when it wasn't in extras, and on a little bit of a search found:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7ef392255b
>>
>> Of course this is a bit of an issue for CentOS/RHEL users that have
>> need for the Red Hat ansible as they have been upgraded, and RH will
>> need to epoch bump (or release 2.5.1 and we pull this from EPEL7 then)
>> to ensure they get it from the right repo.
>>
>> With a branch retirement shouldn't this have been blocked in koji?
>
> Red Hat announced today that Ansible was being deprecated
> from the extras channel.  Their advice is that those who
> have "previously installed Ansible and its dependencies from
> the Extras channel are advised to enable and update from the
> Ansible Engine channel, or uninstall the packages as future
> errata will not be provided from the Extras channel."
>
> https://access.redhat.com/errata/RHSA-2018:1075
>
> Given that, I believe it is reasonable to see ansible return
> to EPEL.  This was discussed in previous EPEL meetings a
> bit, so I'm sure it was known to at least some of the folks
> involved.

There probably should be an announcement sent to the epel announce
list then it gets to a wider audience so more people know this.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Adding devtoolset to EPEL

[Peter Robinson]

>> I have gotten scl's for RH PPCLE and x86_64 downloaded to the Fedora
>> Infrastructure batcave. I have not been able to get aarch64
>> downloaded. I need help here on getting the cdn address correct.
>>
>> I need someone from releng (I guess it would be Peter?) to help us
>> enable this in koji.
>>
>> After that dts should be ready for updates.
>
> Any updates? :)

Sorry, I took the action to sort out the aarch64 DTS and to close out
the rest to get it enabled in koji. Had other deadlines in the last
week or so that took priority, those are now done (as of about 90 mins
ago) so I'll finish this up this afternoon and reply to this mail once
complete.

P
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Adding devtoolset to EPEL

[Peter Robinson]

On Fri, Jan 26, 2018 at 4:41 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> Several meetings ago, the EPEL Steering Committee took up the following 
> points:
>
> 1. Peter Robinson's DTS enablement request
>  A. What packages require it (chromium etc)
>  B. Is there a version in CentOS?

Yes, CentOS builds the DTS and makes it available via the SCL repositories [1]

>i. If not is it possible for it to exist in CentOS?
>   ii. If not what work would a CentOS version take and how long?
>  iii. If not and not possible does this make EPEL non-workable/closed source
>   on it?

So because CentOS has it available all 3 of those questions are irrelevant.

>  C. What problems are known for getting it into Koji
>i. Does it cause problems with normal packages

No, it doesn't. It doesn't "Provide" any of the core toolchains or any
other package so like any other package not in the core build root you
need to explicitly add it to the BuildRequires in the package spec
file.

>   ii. Do users need to have any bits from it to work? [old yacc/bison problem]

No, DTS has been available as part of the standard RHEL subscription
for _YEARS_ and is in use widely.

>  iii. Does koji have problems with this as another channel to work with?

No, just like extras/optional and any of the other additional channels
it has no impact, users need to explicitly add buildrequires to get
any of the packages into their buildroot.

>   iv. Does Fedora have the ability to get this channel
> or need to use a different one (aka CentOS one if it exists)?

Yes, it's provided as part of the standard Red Hat el7 subscription.
Any RHEL user that had a standard RHEL subscription can add the
channel, this is no different from Optional/Extras so no different for
any of the other EPEL use cases.

> ==
>
> At that time, EPSCO agreed that we are ok with this for just the
> development toolkit. We are still needing to work out the following
> items:
>
> 1. How do we do this with mock so that people who rebuild with CentOS can do 
> so.

For RHEL users they need to add the appropriate DTS channels, for
CentOS users they just have to follow the details in the CentOS wiki
[2]

> 2. How do we get Koji to do this

Add DTS to the sync process, add the new repos for all the supported
architectures to the koji external-repos as per
Server/Optional/HA/Extras that are already part of the el7.

> 3. What are the packaging guidelines that need to be put into EPEL
> packaging guidelines as the SCL guidelines were never finalized and
> the devtoolset is an scl that we would be building against.

The DTS isn't really a SCL, it's maintained by a completely different
team and is released on a different schedule. I would think it would
be covered by the same guidelines as the "Extras" repository which,
like DTS, provides additional toolchains such as Golang so what were
the extra packaging guidelines that were required when Extras were
made available in the el7 buildroot?

Any other questions you'd like to use to fillibuster this?

Peter

[1] https://buildlogs.centos.org/centos/7/sclo/
[2] https://wiki.centos.org/AdditionalResources/Repositories/SCL
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Meeting Agenda for 2017-01-03

[Peter Robinson]

On Wed, Jan 3, 2018 at 4:17 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> I would like to cover the following items today:
>
> 1. Peter Robinson's DTS enablement request

Replying inline in case I can't make the meeting due to timezone (I'm
on GMT+8 ATM)

>  A. What packages require it (chromium etc)

chromium is one, there's a bunch of requests around it for
POWER/aarch64 and other optimisations.

>  B. Is there a version in CentOS?
>i. If not is it possible for it to exist in CentOS?
>   ii. If not what work would a CentOS version take and how long?
>  iii. If not and not possible does this make EPEL non-workable/closed source
>   on it?

It definitely exists for CentOS, some of their SIGs are already using
it for aarch64 stuff.

>  C. What problems are known for getting it into Koji
>i. Does it cause problems with normal packages

It should not, it's just a new set of packages and packages need to
explicitly add it as build requires, it is set up that way and doesn't
cause issues in use in standard RHEL and associated build stuff.

>   ii. Do users need to have any bits from it to work? [old yacc/bison problem]

Should be all included in the relevant repos.

>  iii. Does koji have problems with this as another channel to work with?
>   iv. Does Fedora have the ability to get this channel
> or need to use a different one (aka CentOS one if it exists)?

It's part of the standard RHEL subscription.

> 2. Package blocking is no longer available in Fedora build system
>  A. Can it be added at some point and what work is needed?
>  B. If it can't be how to deal with multiple duplicates in future?
> 3. Orphan reports no longer work due to new build system.
>  A. Will they ever?
>  B. What can we do in the meantime?
> 4. Cleaning up duplicate packages between RHEL Extras and EPEL

Are these supported across all EPEL architectures?

>  WALinuxAgent
>  python-passlib
>  python2-crypto
>  libev-devel
>  libtommath-doc
>  libev
>  libtomcrypt
>  python-paramiko-doc
>  python-httplib2
>  libev-source
>  sshpass
>  python2-jmespath
>  libtommath-devel
>  libev-libevent-devel
>  libtommath
> ==
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Using devtoolset for EPEL builds

[Peter Robinson]

On Mon, Nov 13, 2017 at 9:59 AM, Peter Robinson <pbrobin...@gmail.com> wrote:
> On Fri, Oct 21, 2016 at 12:01 AM, Peter Robinson <pbrobin...@gmail.com> wrote:
>>>> I need/want/would like to build new node 6 for EL6, but gcc is too old.
>>>> For that reason, I'd like to use devtoolset-4-gcc, but the build fails
>>>> (obviously) because the package doesn't exist.
>>>>
>>>> So, is there a way to make that work somehow?
>>>> I am not sure about enabling external repos during build, maybe someone
>>>> will be wiser.
>>>
>>>
>>> This has already been discussed several times:
>>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/KSEYFHCLVPK6DZBDOOPMK46AO65V2SM2/
>>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/7HWJYGXFOMEROUYY2TQKZLKC2MSAAA7R/
>>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/YQLNZYT5ATELGMHNGET7QCOG3S3UIYT5/
>>>
>>> There are some potential roadblocks, but it comes down to someone writing up
>>> an official proposal and going through the full approval process.
>>
>> So one of the major blockers for me for WRT to using DTS in builds it
>> that it is currently x86_64 only but with the next release, (DTS 6.0)
>> it will support all the RHEL architectures [1] which certainly make it
>> easier to support across platforms. We obviously don't want to deal
>> with it prior to GA and I have no idea when the intended GA is it's
>> certainly worth discussing further now as to what are the
>> requirements, advantages, potential issues etc.
>
> I think this is now worth revisiting, at least for EL7, now DTS is out
> and supports key architectures. Thoughts?
>
> https://developers.redhat.com/blog/2017/10/25/announcing-release-software-collections-developer-toolset-new-compilers/

Smooge: can this be added to the agenda for the next meeting?

I'm happy to do the work to enable it, just want to make sure it's
wanted before I start.

Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Using devtoolset for EPEL builds

[Peter Robinson]

On Fri, Oct 21, 2016 at 12:01 AM, Peter Robinson <pbrobin...@gmail.com> wrote:
>>> I need/want/would like to build new node 6 for EL6, but gcc is too old.
>>> For that reason, I'd like to use devtoolset-4-gcc, but the build fails
>>> (obviously) because the package doesn't exist.
>>>
>>> So, is there a way to make that work somehow?
>>> I am not sure about enabling external repos during build, maybe someone
>>> will be wiser.
>>
>>
>> This has already been discussed several times:
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/KSEYFHCLVPK6DZBDOOPMK46AO65V2SM2/
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/7HWJYGXFOMEROUYY2TQKZLKC2MSAAA7R/
>> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/YQLNZYT5ATELGMHNGET7QCOG3S3UIYT5/
>>
>> There are some potential roadblocks, but it comes down to someone writing up
>> an official proposal and going through the full approval process.
>
> So one of the major blockers for me for WRT to using DTS in builds it
> that it is currently x86_64 only but with the next release, (DTS 6.0)
> it will support all the RHEL architectures [1] which certainly make it
> easier to support across platforms. We obviously don't want to deal
> with it prior to GA and I have no idea when the intended GA is it's
> certainly worth discussing further now as to what are the
> requirements, advantages, potential issues etc.

I think this is now worth revisiting, at least for EL7, now DTS is out
and supports key architectures. Thoughts?

https://developers.redhat.com/blog/2017/10/25/announcing-release-software-collections-developer-toolset-new-compilers/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible1.9 package

[Peter Rex]

You seem to be the guy who does the builds. If you could advise, despite
the grumpiness:

Since updating Ansible playbooks, tasks, libraries and such to work with a
more current Ansible version isn't practical, on existing servers, we're
thinking of adding "exclude=ansible1.9 ansible" to the relevant section of
the "epel.repo" config file to keep it at 1.9, and on new servers, just
install the old ansible1.9 package via RPM (which I managed to find on a
mirror that hadn't been updated yet).

However, I'm wondering if we should worry about future changes to
dependencies. Most are in @base so I doubt they will stop working with an
older versions of Ansible, but do you think we should "exclude" other @epel
packages in Ansible 1.9's spec file, or do you think they would they keep
working with Ansible 1.9 even if they were updated in the future. The only
other @epel package in use on the control servers is git, which shares no
common dependencies with ansible1.9.

Writing that down, I think I answered my own question (answer = why not
"exclude" them from yum update?), but if you have an opinion you're willing
to share, please do. The other @epel package dependencies are:

python-crypto2.6
python-httplib2
python-jinja2-26
python-keyczar
sshpass

# rpm -qp ansible1.9-1.9.6-2.el6.noarch.rpm --requires
/usr/bin/python
PyYAML
config(ansible1.9) = 1.9.6-2.el6
python(abi) = 2.6
python-crypto2.6
python-httplib2
python-jinja2-26
python-keyczar
python-paramiko
python-setuptools
python-simplejson
python-six
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
sshpass
rpmlib(PayloadIsXz) <= 5.2-1

# repoquery --requires ansible
/usr/bin/python2.6
PyYAML
python(abi) = 2.6
python-crypto
python-crypto2.6
python-httplib2
python-jinja2-26
python-keyczar
python-paramiko
python-setuptools
python-simplejson
python-six
python2-jmespath
sshpass

# yum history info 7
Loaded plugins: fastestmirror
Transaction ID : 7
Begin time : Fri Nov  3 12:13:07 2017
Begin rpmdb: 218:9695f8cd22db900948a11d2d1346ec6f4728e54a
End time   :12:13:22 2017 (15 seconds)
End rpmdb  : 234:5cef426bcb5a193a4595179386f2b1900998507b
User   : root 
Return-Code: Success
Command Line   : install ansible1.9-1.9.6-2.el6.noarch.rpm
Transaction performed with:
Installed rpm-4.8.0-55.el6.i686 @CentOS/6.9
Installed yum-3.2.29-81.el6.centos.noarch   @CentOS/6.9
Installed yum-plugin-fastestmirror-1.1.30-40.el6.noarch @CentOS/6.9
Packages Altered:
Dep-Install PyYAML-3.10-3.1.el6.i686  @base
Install ansible1.9-1.9.6-2.el6.noarch
@/ansible1.9-1.9.6-2.el6.noarch
Dep-Install libyaml-0.1.3-4.el6_6.i686@base
Dep-Install python-babel-0.9.4-5.1.el6.noarch @base
Dep-Install python-crypto-2.0.1-22.el6.i686   @base
Dep-Install python-crypto2.6-2.6.1-2.el6.i686 @epel
Dep-Install python-httplib2-0.7.7-1.el6.noarch@epel
Dep-Install python-jinja2-26-2.6-3.el6.noarch @epel
Dep-Install python-keyczar-0.71c-1.el6.noarch @epel
Dep-Install python-markupsafe-0.9.2-4.el6.i686@base
Dep-Install python-paramiko-1.7.5-2.1.el6.noarch  @base
Dep-Install python-pyasn1-0.0.12a-1.el6.noarch@base
Dep-Install python-setuptools-0.6.10-3.el6.noarch @base
Dep-Install python-simplejson-2.0.9-3.1.el6.i686  @base
Dep-Install python-six-1.9.0-2.el6.noarch @base
Dep-Install sshpass-1.06-1.el6.i686   @epel
history info





On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi <ke...@scrye.com> wrote:

> On 11/02/2017 11:03 AM, Peter Rex wrote:
> > Thanks for the info, Ricardo. Hadn't found the retirement notice.
> Security,
> > I guess. I can't resist saying, though, that I regret using Ansible and
> my
> > assumption that one of the Es in EPEL stood for Enterprise. Oh well, live
> > and learn.
>
> Sorry things didn't work out as you would have liked.
>
> ansible1.9 was always intended as a short term 'bridge' to help give
> folks more time to migrate to 2.0. When upstream stopped supporting it,
> we retired it in EPEL as well. ansible is very very fast moving and
> complex and there's no way we could backport even security fixes to an
> out of date 1.9 version. Sorry.
>
> You can of course still use 1.9 if you wish, just realize that it
> doesn't get any bugfixes or security updates.
>
> kevin
>
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible1.9 package

[Peter Rex]

They aren't very smart. I'm pretty sure I could pin the blame on Ricardo.

On Fri, Nov 3, 2017 at 6:08 AM, Manuel Wolfshant <wo...@nobugconsulting.ro>
wrote:

> On 11/03/2017 06:09 AM, Peter Rex wrote:
>
> Security flaws mean nothing to the application I use Ansible for, but
> stability does. Control servers are in private networks, and they configure
> equipment guarded by murderous thugs, so no problem there.
>
> The control servers don't get updated that often, but when they do, it's
> not good if things stop working, because, you know, the equipment they
> configure is owned by people who employ murderous thugs to guard it. Kind
> of a problem.
>
> We originally looked at Ansible and thought, OK, Red Hat, nothing more
> stable than that. Ansible, flagship product. It seemed like a good bet, but
> turned out not to be, that Red Hat wasn't likely to deprecate a major
> version of a software package during the lifetime of one of its operating
> systems, in this case EL6. Given how much of a moving target Ansible has
> turned out to be, I definitely should have subscribed to epel-announce, to,
> you know, minimize the chance of getting murdered, but here we are.
>
> Make sure that the murderous thugs do not find out that you confused the
> stability of RHEL ( which is a commercial product backed by an enterprise
> which asks for money and delivers services ... and rather long term stable
> APIs for most of the software they offer  ) with the one of EPEL which is a
> community-driven-best-effort-based product
>
> wolfy ( Who's not afraid of murderous thugs because he's protected by
> a murderous 3mo old cat -- it murdered several toys already)
>
>
> Anyhow, thanks for the feedback.
>
>
> On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi <ke...@scrye.com> wrote:
>
>> On 11/02/2017 11:03 AM, Peter Rex wrote:
>> > Thanks for the info, Ricardo. Hadn't found the retirement notice.
>> Security,
>> > I guess. I can't resist saying, though, that I regret using Ansible and
>> my
>> > assumption that one of the Es in EPEL stood for Enterprise. Oh well,
>> live
>> > and learn.
>>
>> Sorry things didn't work out as you would have liked.
>>
>> ansible1.9 was always intended as a short term 'bridge' to help give
>> folks more time to migrate to 2.0. When upstream stopped supporting it,
>> we retired it in EPEL as well. ansible is very very fast moving and
>> complex and there's no way we could backport even security fixes to an
>> out of date 1.9 version. Sorry.
>>
>> You can of course still use 1.9 if you wish, just realize that it
>> doesn't get any bugfixes or security updates.
>>
>
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible1.9 package

[Peter Rex]

Ah thanks, I ended up finding the 1.9.6-2 version on a mirror that hadn't
been updated yet. Seems to work fine.

On Fri, Nov 3, 2017 at 9:09 AM, Stephen John Smoogen <smo...@gmail.com>
wrote:

> On 3 November 2017 at 00:09, Peter Rex <prex5...@gmail.com> wrote:
> > Security flaws mean nothing to the application I use Ansible for, but
> > stability does. Control servers are in private networks, and they
> configure
> > equipment guarded by murderous thugs, so no problem there.
> >
> > The control servers don't get updated that often, but when they do, it's
> not
> > good if things stop working, because, you know, the equipment they
> configure
> > is owned by people who employ murderous thugs to guard it. Kind of a
> > problem.
> >
> > We originally looked at Ansible and thought, OK, Red Hat, nothing more
> > stable than that. Ansible, flagship product. It seemed like a good bet,
> but
> > turned out not to be, that Red Hat wasn't likely to deprecate a major
> > version of a software package during the lifetime of one of its operating
> > systems, in this case EL6. Given how much of a moving target Ansible has
> > turned out to be, I definitely should have subscribed to epel-announce,
> to,
> > you know, minimize the chance of getting murdered, but here we are.
> >
>
> OK how can we better explain this in the future? There seems to be
> some sort of misunderstanding that EPEL is giving the same guarentees
> as a paid for product from Red Hat. I can understand the grumpiness if
> you had gotten this under Red Hat contract support and things got
> bumped. In that case you are paying Red Hat to do that work of keeping
> software around for N years or it is clear in the contract that this
> software is not considered 'long term supported'.
>
> In any case you can get a hold of ansible1.9 from
> https://koji.fedoraproject.org/koji/buildinfo?buildID=690794
>
>
>
>
> > Anyhow, thanks for the feedback.
> >
> >
> > On Thu, Nov 2, 2017 at 2:48 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> >>
> >> On 11/02/2017 11:03 AM, Peter Rex wrote:
> >> > Thanks for the info, Ricardo. Hadn't found the retirement notice.
> >> > Security,
> >> > I guess. I can't resist saying, though, that I regret using Ansible
> and
> >> > my
> >> > assumption that one of the Es in EPEL stood for Enterprise. Oh well,
> >> > live
> >> > and learn.
> >>
> >> Sorry things didn't work out as you would have liked.
> >>
> >> ansible1.9 was always intended as a short term 'bridge' to help give
> >> folks more time to migrate to 2.0. When upstream stopped supporting it,
> >> we retired it in EPEL as well. ansible is very very fast moving and
> >> complex and there's no way we could backport even security fixes to an
> >> out of date 1.9 version. Sorry.
> >>
> >> You can of course still use 1.9 if you wish, just realize that it
> >> doesn't get any bugfixes or security updates.
> >>
> >> kevin
> >>
> >>
> >>
> >> ___
> >> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> >> To unsubscribe send an email to epel-devel-leave@lists.
> fedoraproject.org
> >>
> >
> >
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> >
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible1.9 package

[Peter Rex]

Thanks for the info, Ricardo. Hadn't found the retirement notice. Security,
I guess. I can't resist saying, though, that I regret using Ansible and my
assumption that one of the Es in EPEL stood for Enterprise. Oh well, live
and learn.

On Thu, Nov 2, 2017 at 9:28 AM, Ricardo J. Barberis <rica...@palmtx.com.ar>
wrote:

> El Miércoles 01/11/2017 a las 23:58, Peter Rex escribió:
> > Is gone. Any particular reason?
>
> Yep, mostly security vulnerabilities and 2.x being available, check out
> these
> threads for more info:
>
> https://lists.fedoraproject.org/archives/list/epel-devel@
> lists.fedoraproject.org/message/BVB3PXVUFNKKGHGVAOGVNNZODJBFYTMR/
> https://lists.fedoraproject.org/archives/list/epel-devel@
> lists.fedoraproject.org/message/VZ3BFEZ5526KMZI53MUZL6YZK3Z7EBB2/
>
> Cheers,
> --
> Ricardo J. Barberis
> Usuario Linux Nº 250625: http://counter.li.org/
> Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
> Senior SysAdmin / IT Architect - www.DonWeb.com
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] ansible1.9 package

[Peter Rex]

Is gone. Any particular reason?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Problem with vulkan on epel7

[Peter Robinson]

On Wed, Sep 20, 2017 at 10:03 AM, Tuomo Soini  wrote:
> Vulkan was retired at https://pagure.io/releng/issue/6948
>
> But rpm is still in repo. All other packages retired on same ticket are
> gone but that one is still there. What's the issue with this
> retirement? According git repo it was retired ok.

It's not reporting blocked in koji [1]

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=23126
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: How to clean up EPEL 7 broken repoclosure

[Peter Robinson]

On Thu, Aug 24, 2017 at 11:16 PM, Stephen John Smoogen  wrote:
> So with CentOS-7 CR updated to 7.4 I did a repoclosure of our current
> repository. Various packages are needing items which are neither in
> CentOS or EPEL. The most needed requirements are:
>
>   2  librados2-devel = 1:0.80.7
>   2  libxfce4util.so.6()(64bit)
>   2  libzmq.so.4()(64bit)
>   2  nautilus-python
>   7  nodejs(abi) = 0:0.10
>   7  nodejs(v8-abi) = 0:3.14
>   2  python-musicbrainzngs >= 0:0.4
>   2  python-paste-script
>   4  python-rados = 1:0.80.7
>   3  python-rbd = 1:0.80.7
>
> Including epel-testing did not help as it just added more packages
> which are without requirements.
>   7  golang(github.com/stretchr/testify/assert)
>  10  golang(golang.org/x/net/context)
>   3  golang(golang.org/x/net/context/ctxhttp)
>   2  golang(golang.org/x/net/http2)
>   2  golang(golang.org/x/net/http2/hpack)
>   4  librados2-devel = 1:0.80.7
>   2  librbd1-devel = 1:0.80.7
>   2  libxfce4util.so.6()(64bit)
>   2  libzmq.so.4()(64bit)
>   7  nodejs(abi) = 0:0.10
>   7  nodejs(v8-abi) = 0:3.14
>   2  python-docker-squash >= 0:1.0.0-0.3
>   2  python-musicbrainzngs >= 0:0.4
>   2  python-oslo-config
>   3  python-oslo-utils
>   3  python-paste-script
>   8  python-rados = 1:0.80.7
>   6  python-rbd = 1:0.80.7
>
> There are a lot of
>
> The 79 packages with problems are
>
> TurboGears-1.1.3-8.el7.noarch
> airinv-1.00.1-2.el7.x86_64
> banshee-2.6.2-11.el7.x86_64
> beets-1.4.3-2.el7.noarch
> beets-plugins-1.4.3-2.el7.noarch
> bionetgen-2.2.5-2.el7.x86_64
> blender-2.68a-6.el7.x86_64
> ceph-0.80.7-0.8.el7.x86_64
> ceph-0.80.7-0.9.el7.x86_64
> ceph-common-0.80.7-0.8.el7.x86_64
> ceph-common-0.80.7-0.9.el7.x86_64
> ceph-devel-compat-0.80.7-0.8.el7.x86_64
> ceph-devel-compat-0.80.7-0.9.el7.x86_64
> claws-mail-plugins-vcalendar-3.11.1-5.el7.x86_64
> dragonegg-3.4-5.el7.x86_64
> golang-github-aws-aws-sdk-go-devel-1.4.22-0.1.git6c577e9.el7.noarch
> golang-github-cockroachdb-cmux-devel-0-0.4.git112f050.el7.noarch
> golang-github-cockroachdb-cmux-unit-test-devel-0-0.4.git112f050.el7.x86_64
> golang-github-golang-appengine-devel-0-0.9.git6a43653.el7.noarch
> golang-github-grpc-ecosystem-grpc-gateway-devel-1.0.0-0.2.gitf52d055.el7.noarch
> golang-github-grpc-grpc-go-devel-1.0.0-0.2.git231b4cf.el7.noarch
> golang-github-hashicorp-go-sockaddr-devel-0-0.2.gitaf174a6.el7.noarch
> golang-github-jmespath-go-jmespath-unit-test-devel-0.2.2-0.1.gitbd40a43.el7.x86_64
> golang-github-lsegal-gucumber-devel-0-0.5.git71608e2.el7.noarch
> golang-github-smartystreets-assertions-devel-1.6.0-0.3.git287b434.el7.noarch
> golang-github-spf13-cast-unit-test-0-0.6.gite31f36f.el7.x86_64
> golang-github-spf13-jWalterWeatherman-unit-test-0-0.6.git33c24e7.el7.x86_64
> golang-github-spf13-viper-devel-0-0.7.git1699063.el7.noarch
> golang-github-spf13-viper-unit-test-0-0.7.git1699063.el7.x86_64
> golang-github-stretchr-objx-devel-0-0.8.gitcbeaeb1.el7.noarch
> golang-github-xeipuuv-gojsonschema-unit-test-devel-0-0.1.gitd5336c7.el7.x86_64
> golang-golangorg-crypto-devel-0-0.13.git81372b2.el7.noarch
> golang-golangorg-oauth2-devel-0-0.18.git1364adb.el7.noarch
> golang-google-golang-api-devel-0-0.16.gite6294e6.el7.noarch
> golang-google-golangorg-cloud-devel-0-0.10.git872c736.el7.noarch
> golang-googlecode-go-crypto-devel-0-0.13.git81372b2.el7.noarch
> gramps-3.4.8-1.el7.noarch
> hdf5-mpich-devel-1.8.12-9.el7.x86_64
> jabber-roster-0.1.1-7.el7.noarch
> libcephfs1-devel-0.80.7-0.8.el7.x86_64
> libcephfs1-devel-0.80.7-0.9.el7.x86_64
> libxfcegui4-4.10.0-5.el7.x86_64
> mod_cluster-java-tomcat8-1.3.3-10.el7.noarch
> modularity-testing-framework-0.5.1-2.el7.noarch
> nodejs-bson-0.2.9-1.el7.x86_64
> nodejs-follow-0.11.4-2.el7.noarch
> nodejs-fs-ext-0.4.2-2.el7.x86_64
> nodejs-i18n-transform-2.1.3-1.el7.noarch
> nodejs-i2c-0.1.4-9.el7.x86_64
> nodejs-libxmljs-0.9.0-1.el7.x86_64
> nodejs-node-expat-2.1.4-5.el7.x86_64
> nodejs-node-stringprep-0.2.3-5.el7.x86_64
> nodejs-pg-0.12.3-2.el7.x86_64
> notify-sharp3-3.0.3-2.el7.x86_64
> psad-2.4.3-4.el7.x86_64
> python-atomic-reactor-1.6.17-1.el7.noarch
> python-atomic-reactor-1.6.23.2-1.el7.noarch
> python-ceph-compat-0.80.7-0.8.el7.x86_64
> python-ceph-compat-0.80.7-0.9.el7.x86_64
> python-cephfs-0.80.7-0.8.el7.x86_64
> python-cephfs-0.80.7-0.9.el7.x86_64
> python-moksha-wsgi-1.2.2-2.el7.noarch
> python-oslo-concurrency-1.4.1-2.el7.noarch
> python-proliantutils-2.1.0-1.el7.noarch
> python-pylons-1.0.1-2.el7.noarch
> python-tahrir-0.8.2-1.el7.noarch
> python-tahrir-0.9.0-1.el7.noarch
> python-tooz-0.9-1.el7.noarch
> python2-abclient-0.2.3-4.el7.noarch
> python2-cotyledon-tests-1.2.7-2.el7.noarch
> python2-pyfakefs-3.1-1.el7.noarch
> python2-staplelib-0.3.3-8.el7.noarch
> 

[EPEL-devel] Re: nodejs broken

[Peter Robinson]

On Wed, Aug 23, 2017 at 4:52 PM, Stephen Gallagher <sgall...@redhat.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson <pbrobin...@gmail.com>
> wrote:
>>
>> > It turns out there's an additional issue; it appears that Node.js 6.11.2
>> > with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
>> > EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
>> > upgraded to OpenSSL 1.0.2).
>> >
>> > I'm trying to figure out what to do here. We can't just put back the
>> > http-parser in EPEL unfortunately because the RHEL folks unintentionally
>> > released a lower NVR for the official package. If we put ours back, it
>> > would
>> > supersede RHEL and take them out of support on any package linking
>> > against
>> > it (which now includes parts of SSSD).
>>
>> > I'm going to spend a little time today trying to figure out if I can fix
>> > the
>> > OpenSSL 1.0.1 compatibility patch and push out an update that will work
>> > with
>> > the bundled http-parser for now.
>>
>> Can you not just rebuild nodejs, which will rebuild the bundled
>> http-parser, against the new 1.0.2 build in 7.4?
>
>
> The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
> requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.

Yep, but then also is a bunch of other stuff due to the fact things
were bumped in RHEL, sadly without forking of each el7 dot release
there's not much can be done about that and the consensus (right or
wrong) has been to build for RHEL and when CentOS catches up they'll
be OK.

You could do a whole bunch of work here  to find CentOS is out before
the fix hits stable, if you've got that amount of time go for it.

> I'm trying right now to figure out if I build it for 1.0.1 functionality if
> 1.0.2 is sufficiently backwards-compatible. Because my initial glance
> suggests that it might not be and so I would have to choose between whether
> it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks CentOS
> 7.3 users.
>
> For the record, this is irrespective of the http-parser issue. That one at
> least is solved just by carrying the bundled copy for a short time. But I
> can't do the same with OpenSSL because the Node.js bundled copy of OpenSSL
> is known to have encumbered codecs and I see no value in duplicating the
> effort of stripping them out.

Sure, I don't know the whole problem, I was just going on the snippets
of info you provided.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

[Peter Robinson]

On Wed, Aug 23, 2017 at 4:38 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 23 August 2017 at 10:01, Peter Robinson <pbrobin...@gmail.com> wrote:
>>> On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger <grain...@gmail.com> wrote:
>
>>> I'm trying to figure out what to do here. We can't just put back the
>>> http-parser in EPEL unfortunately because the RHEL folks unintentionally
>>> released a lower NVR for the official package. If we put ours back, it would
>>> supersede RHEL and take them out of support on any package linking against
>>> it (which now includes parts of SSSD).
>>
>> We should really be bumping and pushing an errata if RHEL picked up
>
> I am not sure who the we here is. I am guessing Red Hat but it could
> also be EPEL. If there is something we can do inside of EPEL, I will
> try to get it done this week.

We is Red Hat EL platform engineering, nothing EPEL can do.

>> the EPEL package and pulled it into core RHEL anyway because if people
>> had been previously using it in EPEL for other reasons (and 100s of
>> enterprises do sync EPEL) they would already be in a situation where
>> they're running an unsupported version, there is no other fix to that
>> and Red Hat engineering needs to improve their processes in this
>> regard because there is a number of these issues each el7 cycle.
>>
>
> The usual issue is the following:
>
> 1. The package gets pulled into RHEL-7-next by whatever arcane
> processes does that.
> 2. The owner usually fixes some problem and thinks that the version
> they are pushing with the fix will be accepted internally.
> 3. The fix is too late in the arcane processes and RHEL ships with an
> older version.
> 4. Everyone points fingers at each other for a couple of months after
> a release. Someone tries to iron out problems.
> 5. We have a good release cycle next time.
> 6. Some arcane process changes
> 7. Goto 1.
>
> I think we have done this dance every other minor release since 5.1
>
> I have some ideas on how we can try to 'fix' this from now on that I
> will be presenting at FLOCK next week so that releng and related
> groups can fix/kill.

Sure, but it's a Red Hat not a Fedora/EPEL problem so I don't actually
see how a Flock presentation can fix it, it needs internal product
management etc to put together a process to deal.

>>> I'm going to spend a little time today trying to figure out if I can fix the
>>> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
>>> the bundled http-parser for now.
>>
>> Can you not just rebuild nodejs, which will rebuild the bundled
>> http-parser, against the new 1.0.2 build in 7.4?
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

[Peter Robinson]

> On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:
>>
>> OK, thanks,
>>
>> On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson  wrote:
>>>
>>> Anssi Johansson kirjoitti 23.8.2017 klo 13.31:

 Richard Grainger kirjoitti 23.8.2017 klo 11.55:
>
> yum install nodejs


 Try with this:

 yum install nodejs --enablerepo=epel-testing

 This will install nodejs with http-parser bundled in. http-parser was
 removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship
 packages that are also in RHEL. http-parser will be in CentOS 7.4 once it 
 is
 released.
>>>
>>>
>>> I forgot to mention that this is only a temporary workaround. Once CentOS
>>> 7.4 is released, nodejs will revert back to depending on http-parser from
>>> RHEL/CentOS.
>>
>>
>
>
> It turns out there's an additional issue; it appears that Node.js 6.11.2
> with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
> EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
> upgraded to OpenSSL 1.0.2).
>
> I'm trying to figure out what to do here. We can't just put back the
> http-parser in EPEL unfortunately because the RHEL folks unintentionally
> released a lower NVR for the official package. If we put ours back, it would
> supersede RHEL and take them out of support on any package linking against
> it (which now includes parts of SSSD).

We should really be bumping and pushing an errata if RHEL picked up
the EPEL package and pulled it into core RHEL anyway because if people
had been previously using it in EPEL for other reasons (and 100s of
enterprises do sync EPEL) they would already be in a situation where
they're running an unsupported version, there is no other fix to that
and Red Hat engineering needs to improve their processes in this
regard because there is a number of these issues each el7 cycle.

> I'm going to spend a little time today trying to figure out if I can fix the
> OpenSSL 1.0.1 compatibility patch and push out an update that will work with
> the bundled http-parser for now.

Can you not just rebuild nodejs, which will rebuild the bundled
http-parser, against the new 1.0.2 build in 7.4?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: xmlsec-devel missing from EPEL

[Peter Robinson]

On Mon, Aug 14, 2017 at 3:35 PM, Boaz Ackerman <boa...@gmail.com> wrote:
> We are trying to figure out what happened to the xmlsec-devel package for 
> RHEL.
>
> I was told by list owner (which was super helpful!) that:
>
> It seems it's now included in RHEL 7.4 (and upcoming centos 7.4):
> https://src.fedoraproject.org/rpms/xmlsec1/c/c43df4c1915e1003a9197737cdb8bbd1a7e844d9?branch=epel7
>
> The question is - what do I do with my customers that require me to work on 
> require RHEL 7.2 or 7.3?

EPEL doesn't have the resources to be able to maintain every branch
for various LTS releases of RHEL. This is the same as CentOS. This is
especially the case with el7 where there's more active rebasing of
libraries and various other bits of the distribution than previously.
I've known some EPEL consumers to snapshot a copy of a reposynced repo
at the time of a new el7 release to assist with the process of having
a working EPEL for each of LTS RHEL releases they consume.

Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: RHEL-7.4 is released (build roots updating)

[Peter Robinson]

On Fri, Aug 4, 2017 at 12:04 AM, Yaakov Selkowitz <yselk...@redhat.com> wrote:
> On 2017-08-03 16:35, Kevin Fenzi wrote:
>> On 08/02/2017 05:51 AM, Peter Robinson wrote:
>>> On Wed, Aug 2, 2017 at 5:42 AM, Yaakov Selkowitz <yselk...@redhat.com> 
>>> wrote:
>>>> On 2017-08-01 16:24, Stephen John Smoogen wrote:
>>>>> RHEL-7.4 was released today and so the build roots for EPEL packages
>>>>> will be updated as soon as the automatic reposync is done.
>>>>
>>>> Unfortunately not for aarch64:  https://pagure.io/releng/issue/6926
>>>
>>> I was informed it was pushed to the CDN, smooge what's the status on this?
>>
>> I think it's synced as of last night.
>
> Unfortunately not:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21026971
>
>> What package(s) were you waiting for?

I'm still not sure this is correct, I did a scratch build of dtc and
aarch64 failed to find python2-setuptools where all other
architectures did:

https://koji.fedoraproject.org/koji/taskinfo?taskID=21099618
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: RHEL-7.4 is released (build roots updating)

[Peter Robinson]

On Wed, Aug 2, 2017 at 5:42 AM, Yaakov Selkowitz  wrote:
> On 2017-08-01 16:24, Stephen John Smoogen wrote:
>> RHEL-7.4 was released today and so the build roots for EPEL packages
>> will be updated as soon as the automatic reposync is done.
>
> Unfortunately not for aarch64:  https://pagure.io/releng/issue/6926

I was informed it was pushed to the CDN, smooge what's the status on this?
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Would like to contribute to EPEL-7-ARM

[Peter Robinson]

On Wed, Apr 19, 2017 at 6:51 PM, Kevin Fenzi  wrote:
> On 04/14/2017 07:25 AM, rosedov...@protonmail.com wrote:
>> Hello, I'd like to contribute to the EPEL-7 repo for ARM systems,
> can you please point me to where this is being developed/talked about?
> I'm not seeing any talk about it here.
>
> Well, EPEL is add on packages for Enterprise Linux and there is not a
> armv7 RHEL.

Unless by ARM he means aarch64 at which case it's all there like the
other primary EPEL arches.

> There has been talk in the past about building other arches against
> CentOS, but I am not sure what state the CentOS armv7 efforts are. Are
> they fully built and released? Until then I would say help them out in
> their efforts. Once they are fully released we just need to figure out
> how we can build just armv7 stuff against CentOS.

There's a lot of discussion about ARMv7 over the last 2 odd years so I
would also suggest reading the mailing list and meeting logs.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Package cinamon epel/7/x86_64

[Peter Robinson]

On Mon, Mar 13, 2017 at 10:18 AM,   wrote:
> Hello
>
> I can't find the package cinnamon-2.8.8-2.el7.x86_64 in epel repo
>
> https://dl.fedoraproject.org/pub/epel/7/x86_64/c/
>
> Is it normal ?

Yes, because it was never pushed as an update. In koji it's completely untagged.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: NOTCE: Red Hat Enterprise Linux 5 Three-Month Retirement Notice

[Peter Robinson]

On Fri, Mar 3, 2017 at 11:44 AM, James Hogarth <james.hoga...@gmail.com> wrote:
> On 23 December 2016 at 17:41, Neal Gompa <ngomp...@gmail.com> wrote:
>> On Fri, Dec 23, 2016 at 11:28 AM, Jason L Tibbitts III
>> <ti...@math.uh.edu> wrote:
>>>>>>>> "PR" == Peter Robinson <pbrobin...@gmail.com> writes:
>>>
>>> PR> Reminder that RHEL 5 and hence EPEL 5 has got 3 months until EOL.
>>> PR> Packages now should really just be in bugfix and security fix only
>>> PR> mode.
>>>
>>> Should we be preventing the branching of new packages for EPEL5 at this
>>> point?  We can probably get that switch thrown in phgdb.  It would be
>>> analogous to the month of "updates but no new packages" in the (current
>>> - 2) Fedora release.
>>>
>>>  - J<
>>
>> It's probably a good idea to do that. I'd probably hazard to guess
>> that the flow of new packages going into EL5 target has already
>> slowed, and formally stopping the addition of new packages would
>> merely enforce the policy that Peter mentioned at the beginning of the
>> thread.
>>
>>
>>
>
> So this is pretty imminent now.
>
> Is the plan to drop EPEL5 packages entirely or to archive the last
> status of the repo like old fedora releases get archived?

They'll get archived as a snapshot of how it stands at EOL just like
previous EPEL releases:
http://archive.fedoraproject.org/pub/epel/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Repo for armhf?

[Peter]

On 16/01/17 06:00, reedych wrote:
> Has EPEL a repo for armhf? Or any unnoficial builds? If nobody wants
> to maintain it, how I can to autobuild all repo locally? Thanks!

It looks like CentOS did a build for it:
http://buildlogs.centos.org/c7-epel.a32/

It's a few months old, though.


Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] NOTCE: Red Hat Enterprise Linux 5 Three-Month Retirement Notice

[Peter Robinson]

Reminder that RHEL 5 and hence EPEL 5 has got 3 months until EOL.
Packages now should really just be in bugfix and security fix only
mode.

Details: https://rhn.redhat.com/errata/RHSA-2016-2997.html
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Heads up: haskell stack for aarch64/ppc64le on epel7

[Peter Robinson]

Hi All,

Haskell has been bootstrapped for aarch64/ppc64le on epel7.

Testing and karma very welcome on the following update (note it takes
a bit to load due to size of update).

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-25cbafa070

Thanks a lot to Jens the maintainer for the effort in getting this done!

Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: EPEL 7 for i386

[Peter Robinson]

On Fri, Dec 2, 2016 at 5:08 PM,  <cl...@redhat.com> wrote:
> Hello,
>
> Is there any plan to build EPEL 7 packages also for i386 to make them 
> available for i386 CentOS 7? A few people in COPR are quite interested in 
> building packages also for this target and I am curious if there could be 
> more reasons for doing it.
>

There's lots of details as to the issues that need to be dealt with in
the list archives.

Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: EPEL 7 for i386

[Peter]

On 04/12/16 05:36, Kevin Fenzi wrote:
> On Fri, 02 Dec 2016 17:08:09 -
> cl...@redhat.com wrote:
> 
>> Hello, 
>>
>> Is there any plan to build EPEL 7 packages also for i386 to make them
>> available for i386 CentOS 7? A few people in COPR are quite
>> interested in building packages also for this target and I am curious
>> if there could be more reasons for doing it.
> 
> It's been discussed in the past, but it's tricky to implement. 
> 
> We would have to build against centos (since there's no rhel7 i386),
> but yet build the rest of our arches against rhel7. I think last we
> talked about this we had come up with a way to do that, but no one yet
> has had the time to try and implement it. 
> 
> so, yes, we would like to, but not sure when it might happen. 

If you need it in the meantime there is this, but it's a couple months old:
http://buildlogs.centos.org/c7-epel/


Peter



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Report: Package conflicts between EPEL and RHEL-7.3

[Peter Robinson]

On Fri, Nov 18, 2016 at 5:09 PM, Stephen John Smoogen  wrote:
> This is my first pass at finding the conflicts with between EPEL-7
> x86_64 and the RHEL repos 'rhel-7-server-extras-rpms',
> 'rhel-7-server-optional-rpms', 'rhel-7-server-rpms',
> 'rhel-ha-for-rhel-7-server-rpms'.
>
> There do not seem to be any places where EPEL packages would replace
> packages in those trees. The following packages are in EPEL and in
> those trees but the RHEL versions are greater:
>
> python-flask
> python-werkzeug

I think we might need those two on non x86_64 arches (we might be
getting extras on non x86 arches shortly too though)

P
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: EPEL-ANNOUNCE Major Mono update for EL7

[Peter Robinson]

On Tue, Nov 15, 2016 at 2:32 PM, Timotheus Pokorra
<timotheus.poko...@solidcharity.com> wrote:
>> I hope to push them to stable at around the time when CentOS 7.3 is released.
>
> I just wonder, what is the right time to push the mono packages to stable:
>
> https://fedoraproject.org/wiki/EPEL_Updates_Policy says:
> In cases of major disruption, EPEL updates will looked to be done
> along with Red Hat Enterprise Linux minor releases (6.1, 6.2, 6.3) so
> as to allow for longer testing or differing beta testing.
>
> As RHEL 7.3 has already been releasesd, should I already push the mono
> packages to stable, or wait as I originally announced for the CentOS
> 7.3 release?

Is it dependent on anything in the 7.3 release (bugfix or feature) to
be usable? Or is it just an arbitrary date that was chosen? If the
former I'd wait, if it's independent I'd push it.

Peter
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Reminder: Red Hat Enterprise Linux 5 Six-Month Retirement Notice

[Peter Robinson]

Just a reminder that there's 6 months left of the standard RHEL-5
life-cycle so 6 months left of EPEL-5.

https://rhn.redhat.com/errata/RHSA-2016-1990.html
___
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

[Peter Robinson]

On Wed, Sep 14, 2016 at 3:51 AM, Dennis Gilmore <den...@ausil.us> wrote:
> 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

There most definitely are, at least in what is shipped, it depends on
the arch and is lessening/changing with each dot release and is much
less of a problem with el7 than earlier releases. The big one that
comes to mind in extras is golang/docker stack.
___
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

[Peter Robinson]

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

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

> 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.org

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

[Peter]

On 16/08/16 06:24, Tom Callaway wrote:
> I'd like to propose that we enable the Developer Toolset repo in EPEL
> and allow packages to depend on it. Thoughts?

There is one issue with this that I don't think others have addressed
yet on this list.  EPEL 6 supports i686 as a build target, but
devtoolset for el6 is available for x86_64 only, so it would cause
problems with i686 builds.


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

[EPEL-devel] Re: nodejs update

[Peter Robinson]

On Mon, Aug 22, 2016 at 4:23 PM, Stephen Gallagher <sgall...@redhat.com> wrote:
> On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
>> On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
>>> Hi!
>>>
>>> As some of you may know, nodejs package that is present in
>>> EPEL is pretty outdated. The current v0.10 that we have will
>>> go EOL in October and npm (package manager) is already not
>>> maintained.
>>>
>>> Currently, upstreams' plan is to have two versions of Long
>>> Term Support (LTS) at once, one in active development and one
>>> in maintenance mode.
>>> Currently active is v4, which is switching to maintenance in
>>> April and v6 which is switching to LTS in October.
>>> This is also reason why we would like to skip v4, although
>>> both will get security updates. Nodejs v6 also comes with
>>> newer npm and v8 (which might best be bundled, as it is in
>>> Fedora and Software Collections) (v8 might concern ruby and
>>> database maintainers, but old v8 package still remains in
>>> the repo).
>>>
>>> There was also an idea to have both LTS versions in repo,
>>> but we're not quite sure, how we'd do it and if it's even a
>>> good idea.
>>>
>>> Also, another thing is, if it is worth of updating every year
>>> to new LTS or update only after the current one goes EOL.
>>> According to guidelines, I'd say it's the latter, but it's
>>> not exactly how node development works and some feedback from
>>> users on this would be nice, because I have none.
>>>
>>>
>>> tl;dr Need to update nodejs, but can't decide if v4 or v6,
>>> v4: will update sooner, shorter support (2018-04-01)
>>> v6: longer support (2019-04-01), *might* break more things,
>>> won't be in stable sooner than mid-October if everything
>>> goes well
>>
>> FYI, I think this tl;dr missed explaining why v6 won't be in stable until
>> mid-October. What Zuzana and I discussed on another list is that the Node.js 
>> v6
>> schedule has it going into LTS mode on the same day that 0.10.x reaches EOL.
>> However, v6 is already out and available. The major thing that changes at 
>> that
>> point is just that from then on, they commit to adding no more major features
>> (as I understand it). This is the best moment for us to switch over to it.
>>
>> However, in the meantime we will probably want to be carrying 6.x in
>> updates-testing for at least a month prior to declaring it stable (with
>> autokarma disabled) with wide announcements about the impending upgrade. This
>> will be safe to do since Node.js 6.x has already reached a point where no
>> backwards-incompatible changes are allowed in, so we can start the migration
>> process early.
>>
>
> OK, as we stated before, we really need to get Node.js 6.x into the
> updates-testing repository soon. We mentioned that we wanted it to sit there 
> for
> at least a month before we cut over, and "at least a month" means "by next 
> week"
> since the cut over is planned for 2016-10-01.
>
> I'm putting together a COPR right now as a first pass at this upgrade:

Let me (or open a rel-eng ticket) when you want a epel7-nodejs6 side
tag to build it into. Will make it easier so you don't need to deal
with a billion build overrides etc.

Peter


> https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
>
> I've run into the following blocker issues:
>
> * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream 
> strictly
> requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible
> to resolve this with SCLs, but I am no expert there. Zuzana?
>
> * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
> and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6
> and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL
> or otherwise) for linking EPEL to a newer version of OpenSSL.
>
> The OpenSSL 1.0.2 problem is a significant one; we cannot build against the
> bundled copy of OpenSSL because it includes patented algorithms that are not
> acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's
> OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the
> base RHEL/CentOS repositories.
>
>
> Right now, the only thing I can think of would be for someone to build a
> parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to 
> the
> openssl101e package available for EPEL 5) and patch our specfile to b

[EPEL-devel] Re: Epel arm

[Peter Robinson]

On Tue, May 24, 2016 at 12:52 AM, Manuel Wolfshant
 wrote:
> On 05/23/2016 07:43 AM, Nicolas Repentin wrote:
>>
>> Hello
>>
>> I'm not sure if it is the good place to ask, I think the question might
>> have been asked but not recently.
>>
>> Is there an epel repo for armv7 somewhere? Or is it planned to have one?
>>
>
> Not yet a repo but on its way: closest thing you can find is
> http://buildlogs.centos.org/c7-epel.a64/. There is an automated job which is
> still undergoing , trying to build everything from EPEL7

That's arm64, it's not the same thing.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Epel arm

[Peter Robinson]

On Mon, May 23, 2016 at 5:43 AM, Nicolas Repentin <nico...@shivaserv.fr> wrote:
> Hello
>
> I'm not sure if it is the good place to ask, I think the question might have
> been asked but not recently.
>
> Is there an epel repo for armv7 somewhere? Or is it planned to have one?

No plans at the moment. There's issues with non RHEL arches when it
comes to rebases. RHEL 7.x is moving quite quickly in terms of
dependency bumps and when the primary RHEL arches get rebuilt for a
new major 7.x bump there's no guarantee that the CentOS only arches
are in sync and no one has proposed a good way to deal with this as
yet.

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

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

[Peter Robinson]

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

This sounds very much like a software collection (SCL) and I don't
believe we have a agreed policy on how that is done for EPEL (see list
archives)
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

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

[Peter Loeffler]

sorry. i'm looking now and it's broken.
mine is working:
https://copr.fedorainfracloud.org/coprs/ploeffler/darktable2/

On 03/08/2016 08:34 AM, Germano Massullo wrote:

darktable 2.0.2 successfully built for EPEL 7 on my Copr repository:

https://copr.fedorainfracloud.org/coprs/germano/Darktable_2.0_release_candidate/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

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

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[LOEFFLER Peter]

yes, volume adjustemnts works fine with the plugin.
i installed pavucontrol from fedora 21. works fine.

you are also right with the icons.
no icon theme was selected.
i picked "Default GNOME Theme" and everything seems to be fine.

regards,
peter


From: Mukundan Ragavan <nonamed...@gmail.com>
Sent: Sunday, February 28, 2016 22:40
To: epel-devel@lists.fedoraproject.org
Subject: [EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/28/2016 07:34 AM, LOEFFLER Peter wrote:
> hi,
>
> xfce 4.12 in epel 7 would be perfect! i set up a fresh centos 7
> and did a "yum groups install xfce-desktop" even with a "yum
> install gnome-icon-theme gnome-icon-theme-symbolic
> gnome-icon-theme-extras gnome-icon-theme-legacy" many icons are
> missing. when i click on "Audio mixer..." in the PulesAudio plugin
> it cannot find pavucontrol. Looks like it is not available in
> centos7.
>
> thanks for doing this, peter
>


Thanks for testing.

I now realize pavucontrol is not available in Centos 7. But, the
volume adjustment itself does work with the plugin, correct?

As for the icons, can you go into Settings -> Appearance -> Icons and
check if one of the complete icon themes is selected?

Thanks again,
Mukundan.

- --
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJW02kxAAoJEHE/1K3lyLxnae8P/3ULOJ6GJISDXZOsQEQuxma+
yQL5BIvDnTzHuBPh7fpCT4SsOWL3W2Pw2nU2F4nlOiduEMFp63bt19uyGRQiXUtb
6iEW4+RY7a/VIvX3HUf1ikeUb2tkDL/07he75hBrAbNrbNZtZcR223PGKrqA4bod
pKi209JQuVmVRrky3nOLF9BcAYCnE6bV3+nI8nPSU1RBUWVPJk5k6m0G9PnwyS4s
rj4ehPMJiipOs+yqdpPACgtYJGeeL47KSFDfPsFaLs85EnZxqgZT2t6k2KQLybjS
hs3S59EvHkv4dHADVFxruYYVgYFTXsKUHK9rfCXeiv2DvHoUYfwZqcAFh7uaZh7A
UedV/88Y4tEqRVj4mQhHj9zBtmmklfupCX86OSPvrVQOnX2bRnXIxtQJkms6TPOc
vgy/OQ80oozHk75ZGxzlWprv7nzN190ZizU+0/UiX+WTJjKtQ877HNOPx89HDdz0
m1teLxEHovVpYs8l68E3sggqXuemYvGhYfVZ6Ofx3dnZT7rcYIfln+x8+BZ8QCvg
Z3cCfbdtXv8pKzoNh7uDGyGxrxJOQ1PbF6xRsT2gR7hgwdGQUbvGzzxl7wPRjz0H
bDY+YRn8RyQLJ+GQx2WeK5Wq6EwjW+T8WlgDEr8Y69WfDE4eRPYyQqz05agDPuKu
FgzmNs9lhB1ePRju2Glo
=KXQU
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[http://www.herold.at/images/hbdat_logo.gif]<http://www.herold.at>

HEROLD Business Data GmbH
Guntramsdorfer Straße 105
A-2340 Mödling

FN 233171z
Landesgericht Wiener Neustadt

[http://www.herold.at/images/gptw2-email.gif]<http://www.greatplacetowork.at>



Besuchen Sie uns online und mobil auf www.herold.at<http://www.herold.at>!

Weitere Informationen zu unseren Produkten finden Sie unter:
http://www.herold.at/kundengewinnen/

oder auf YouTube:
https://www.youtube.com/user/HEROLDChannel

[http://www.herold.at/images/fb_icon_mail.gif]<http://www.facebook.at/derherold>Werden
 Sie Fan von HEROLD auf Facebook<http://www.facebook.at/derherold>!

Bleiben Sie top informiert mit den HEROLD Blogs:
http://www.herold.at/blog/
http://www.herold.at/blog/heroldforbusiness/

Bitte beachten Sie auch:
http://www.website-design.at
http://www.arztsuche24.at
http://www.bauwohnwelt.at
http://www.immoversum.com
http://www.tupalo.com
http://www.urlauburlaub.at



Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Please test Xfce 4.12 for inclusion in EPEL - 7

[LOEFFLER Peter]

hi,

xfce 4.12 in epel 7 would be perfect!
i set up a fresh centos 7 and did a "yum groups install xfce-desktop"
even with a "yum install gnome-icon-theme gnome-icon-theme-symbolic 
gnome-icon-theme-extras gnome-icon-theme-legacy" many icons are missing.
when i click on "Audio mixer..." in the PulesAudio plugin it cannot find 
pavucontrol. Looks like it is not available in centos7.

thanks for doing this,
peter


From: Mukundan Ragavan <nonamed...@gmail.com>
Sent: Thursday, February 25, 2016 02:35
To: epel-devel@lists.fedoraproject.org
Subject: [EPEL-devel] Please test Xfce 4.12 for inclusion in EPEL - 7

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



All,

I have built Xfce 4.12 packages for EL-7 on COPR. The link for the
repo is

https://copr.fedorainfracloud.org/coprs/nonamedotc/xfce412-epel7/

I would appreciate it if people can install the packages and give it a
spin. Please report any issues directly to  me (and not in bugzilla)
as these are not official packages.

Many thanks for testing.
Mukundan.

- --
GPG Key - E5C8BC67
- ---


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWzlpcAAoJEHE/1K3lyLxniE8QALXgsIfRuGltpv+gZwvorJsu
KpOQDgif2qtJwcMik6NCxGE33o6RgK6puboEk2e4iSrjil/iWL9dFstKU9zbfq5O
pUMIeD1zx/AFaw+9XhjK90rZbOEGx+AzknBwy6xwy+hlIHt8MN4C6HKd/+t55uFb
49ik/L4MRD/09fY5cjqZE9ook8frDXmsaFKyWMZOsvBqdoEasuzmrZum1QppS0Br
cdiw0MGqGza5avfyVdoj/stpc2fcOz4OHaaRnWmfdf5lQ9ezN/eMP1xFIM1bJ9eU
8ynGSAwybZsEdxJMkkjWkrN/kvK4ZwGTtbUELJ576Ll88BbFPQagMhCn0fz8UZX4
Vo9tYzS8E0z0uGpg3Z4L1dCtf/ueback5nUFMLC55KV6wTpK2QZPbxPXzEiksNi8
WgfbcA1amOfSVBjBwXXEs5q6DmVHC4jIwO5DLEX39dmmJKFhvajIvofkgAJzUZUy
W5pYkhF6ntP2VCiaGomwAAGrQMeyopGbEJ347eeRNfJvNiWmn2yTb9AUvjqEv38t
WlV1KfEIA/SQjo2lhhC8mo8jO7PSdM9Knz2GU45BBSsZnRNp8HyoGDeoZVJ/bsHI
YLVxdfwfvHPH5LWHFpSqSs4IUZs+dH4AMwwFiMqaTZJkxHBRv+Fs2IgMy9IN2WJL
v5XR7kkMxQ2WMor34szA
=5sOk
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[http://www.herold.at/images/hbdat_logo.gif]<http://www.herold.at>

HEROLD Business Data GmbH
Guntramsdorfer Straße 105
A-2340 Mödling

FN 233171z
Landesgericht Wiener Neustadt

[http://www.herold.at/images/gptw2-email.gif]<http://www.greatplacetowork.at>



Besuchen Sie uns online und mobil auf www.herold.at<http://www.herold.at>!

Weitere Informationen zu unseren Produkten finden Sie unter:
http://www.herold.at/kundengewinnen/

oder auf YouTube:
https://www.youtube.com/user/HEROLDChannel

[http://www.herold.at/images/fb_icon_mail.gif]<http://www.facebook.at/derherold>Werden
 Sie Fan von HEROLD auf Facebook<http://www.facebook.at/derherold>!

Bleiben Sie top informiert mit den HEROLD Blogs:
http://www.herold.at/blog/
http://www.herold.at/blog/heroldforbusiness/

Bitte beachten Sie auch:
http://www.website-design.at
http://www.arztsuche24.at
http://www.bauwohnwelt.at
http://www.immoversum.com
http://www.tupalo.com
http://www.urlauburlaub.at



Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Virtual packages providing python2-*

[Peter]

On 24/02/16 13:41, Peter wrote:
> Maybe I missed something here.

I just realized I completely missed the point of this, never mind my
post above it's based on a complete mis-understanding.


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

[EPEL-devel] Re: Virtual packages providing python2-*

[Peter]

On 24/02/16 13:09, Jason L Tibbitts III wrote:
> JH> How should this be maintained going forward into 7.3+ in case RH
> JH> bring more into base...
> 
> They would be removed.  If we set the version of the dummy package to
> zero, they won't even get in the way if a RHEL package does start
> providing python2-whatever, since the RHEL version would then always
> take precedence.

I would be worried, though, that you'll have packages that were built
against python that are now trying to pull in and possibly run on
python2 unnecessarily, and possibly detrimentally if Red Hat suddenly
decides to push python2 packages out.

It seems to me that if the package is going to be built against pythin
then it should require python, if it has to be built against python2
then it should require python2.  In neither case does it seem prudent to
be tricking packages into thinking that python is actually python2.

Maybe I missed something here.


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

[EPEL-devel] Re: How to go on with unmaintainable package?

[Peter]

On 24/02/16 10:40, Jason L Tibbitts III wrote:
> It should be quite possible to have a newer compiler in EPEL6 that's
> parallel-installable, but someone would have to actually do the work to
> make that happen.  At least I don't think that violates any EPEL rules.

Devtoolset 3 has gcc 4.9.2, not sure what the policy is on using
devtoolset for building packages that require it in epel.  It is
parrallel installable, though, and I'm sure can be rebuilt for epel if
need be.

Perhaps the usage of devtoolset for building epel packages should be
visited (if it hasn't been already).  Normally these are only required
for the build phase and not needed as a binary dependency.


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

[EPEL-devel] Re: related question / off topic - EPEL Proposal #1: Rechartering

[Peter]

On 19/02/16 15:16, ~Stack~ wrote:
> Thanks for replying. Makes sense. But what would the harm be to move a
> package into a separate "retired" repo? Community would know that it
> isn't maintained and yet the package wouldn't just disappear completely.
> I guess the difficult question would then be, how long is the package
> kept till it needs to be pruned? 1yr? 6mo? Still, it would be nice to
> give the user base the option to pull the packages they need out on a
> long enough scale that they have time to discover it with new builds.

My suggestion would be for the life of the point release of the repos
that's built against.  Since the package is not going to be built
against newer point releases of RHEL it is less likely to continue to
work after RHEL moves to a new point release (say from 7.2 to 7.3).  We
could have an individual "retired" repo for each point release that
would see the packages built against that release moved there.  We would
not necessarily need get rid of older retired repos, but just maintain a
symbolic link to the latest one.

So for example if package foo was last built against RHEL 7.2 before it
was retired, we could move it to the repo "epel-retired-7.2" and there
would be a symbolic link for "epel-retired" that points to
epel-retired-7.2 until RHEL 7.3 is released.


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

[EPEL-devel] Re: The %license property is now supported in EPEL6

[Peter Lemenkov]

Hello All!

2016-01-20 22:03 GMT+01:00 Jason L Tibbitts III <ti...@math.uh.edu>:
> Just a note that it EPEL6 no longer requires you to include the
> definition of %license property; you can use it freely in your %files
> list as you would in EPEL7 or Fedora.  It simply maps to %doc as it
> would if you had included the magic line noise manually.  This works for
> me in koji; if it doesn't work in your local mock instance, it's
> possible that the mirrors still need to catch up with the change to
> comps.

Great news! Thanks everyone involved!

-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Upgrading Mono in Epel7

[Peter Robinson]

> we are discussing in this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1220138 the work that
> would be required to upgrade Mono in Epel.
>
> I am aware that this is a major upgrade, and according to [1] it
> should be avoided.
> But Mono is that old in Epel7 already, so the discussion currently
> goes into the direction that an upgrade is better than nobody using
> Mono in Epel at all.

It either needs to be upgraded or retired, I have no issues with it
being upgraded.

> I would like to upgrade to the latest stable Mono version, which is
> 4.2 at the moment. That is in rawhide already, F23 has Mono 4.0.

Is there a LTS release in the mono 4.x release?

> What do people think on this list?

What's the future of Mono with an open source MS .Net core?

> Do I need to create a Fesco ticket to request permission to upgrade
> Mono in Epel7, and to do a bootstrap similar to Mono 4 in Fedora [2]?

Well it would be Eesco, but personally I don't believe it's needed, it
just needs to be properly co-ordinated.

> Thanks for any hints and suggestions,
>   Timotheus
>
> [1] 
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_update
> [2] https://fedorahosted.org/fpc/ticket/528
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: execstack on epel 7 ppc64le?

[Peter Robinson]

> I'm trying to build the ppc64le branch of OpenBLAS on EPEL7. But, I get the
> following error message in the setup phase:
>
> DEBUG util.py:393:  Error: No Package found for /usr/bin/execstack
>
> Why would this binary not exist on ppc64le?

Because originally it was part of prelink, which was never supported
on aarch64/ppc64le, in RHEL it's shipped as part of that package, it
was dropped in F-23 and the useful execstack binary was split out into
it's own package. It shouldn't be built in EPEL as it'll conflict with
core RHEL packages.

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

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

[Peter Robinson]

>> You are kindly invited to the meeting:
>>EPSCo weekly meeting on 2015-12-18 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/
>
> So, we haven't been meeting too much lately with everyone traveling,
> etc.
>
> Also, Starting in january, FESCo is going to be meeting on Fridays at
> this slot. :)
>
> So, how about we pick another day/time and see if we can get more folks
> involved?
>
> thoughts?

Yes please! When I'm in the UK Friday 5pm is a terrible time as
generally the pub wins ;-)
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Peter Robinson]

On Mon, Dec 14, 2015 at 3:16 AM, Ken Dreyer <ktdre...@ktdreyer.com> wrote:
> On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson <pbrobin...@gmail.com> wrote:
>> 2) Automatic unpushing of updates that haven't gone stable after X
>> time (I propose 3 months/90 days here). That should be ample time to
>> know if it's good/bad.
>
> Could we make it go the other way, and submit the update to stable if
> it's received no feedback for 90 days?

No, because on two of the 3 I referenced there was bad karma and no
response from the "maintainer" to the feedback.

> Often I'll let my update sit in epel-testing for a long time because I
> want to give users a large window of opportunity to test the update.
> It's not that it's abandoned, it's just that it's not an urgent
> update, so why rush it? If the update hits the karma threshold earlier
> than I expected, so much the better.

I think 90 days is enough to let people test it, ultimately the
maintainer should have done the testing and know the vast majority of
it is good, it should be more to get non standard use cases, corner
cases etc.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Peter Robinson]

>> So one thing I noticed when doing the ppc64le bootstrap is that
>> there's a bunch of updates that are a bit of a mess and there's a
>> whole bunch of run and dump in updates. There's everything from
>> updates with CVEs that are broken for a a long time [2], updates there
>> for 11+ months with missing deps (build or otherwise) [1], or just
>> sitting there for ever [3]. I have cleaned up a bunch of stuff in
>> epel7 around tagging too but not looked at the others.
>>
>> I know Kevin had a bit of a look at this [4] and I think I've fixed up
>> a bunch of the issues in the process of the arch bringup which should
>> settle a little once those updates go stable but I think we could do
>> better to keep this cleaner with some of the tools we already use in
>> Fedora.
>>
>> So some ideas to try and improve this, without a bunch of manual work,
>> in no particular order:
>> 1) Enable task-o-tron dep checking on updates in bodhi with aim to not
>> push broken updates (EPEL is suppose to be more stable)
>> 2) Automatic unpushing of updates that haven't gone stable after X
>> time (I propose 3 months/90 days here). That should be ample time to
>> know if it's good/bad.
>> 3) Some sort of dep check spam-o-matic (daily branched/rawhide) style
>> weekly report (might not be needed if we never break stuff)
>>
>> I was a bit shocked to see the state of EPEL7, I sort of expected it
>> to be better than Fedora due to the more stable nature but it was,
>> even this early in the el7 cycle, a bit of a mess!
>>
>> Anyone else have some thoughts and ideas for improving this?
>>
>
> One part of this is that not a lot of people are using 7 compared to
> 6. This was sort of the case for EL-6 that didn't see a huge jump in
> growth until CentOS had EL-6.3 .  Second of all there isn't a lot of
> people active in packaging stuff in EPEL as have been in the past
> versus the number of people wanting things. If people have ideas and
> will be at FOSDEM I would love to talk with you.

To some degree you are correct, but there is someone pushing these
updates, if they're not going to maintain them they should think twice
before pushing them!
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Improving EPEL updates process

[Peter Robinson]

Hi All,

So one thing I noticed when doing the ppc64le bootstrap is that
there's a bunch of updates that are a bit of a mess and there's a
whole bunch of run and dump in updates. There's everything from
updates with CVEs that are broken for a a long time [2], updates there
for 11+ months with missing deps (build or otherwise) [1], or just
sitting there for ever [3]. I have cleaned up a bunch of stuff in
epel7 around tagging too but not looked at the others.

I know Kevin had a bit of a look at this [4] and I think I've fixed up
a bunch of the issues in the process of the arch bringup which should
settle a little once those updates go stable but I think we could do
better to keep this cleaner with some of the tools we already use in
Fedora.

So some ideas to try and improve this, without a bunch of manual work,
in no particular order:
1) Enable task-o-tron dep checking on updates in bodhi with aim to not
push broken updates (EPEL is suppose to be more stable)
2) Automatic unpushing of updates that haven't gone stable after X
time (I propose 3 months/90 days here). That should be ample time to
know if it's good/bad.
3) Some sort of dep check spam-o-matic (daily branched/rawhide) style
weekly report (might not be needed if we never break stuff)

I was a bit shocked to see the state of EPEL7, I sort of expected it
to be better than Fedora due to the more stable nature but it was,
even this early in the el7 cycle, a bit of a mess!

Anyone else have some thoughts and ideas for improving this?

Peter

[1] https://bodhi.fedoraproject.org/updates/python-flask-assets-0.10-2.el7
[2] https://bodhi.fedoraproject.org/updates/dokuwiki-0-0.24.20140929c.el7
[3] https://bodhi.fedoraproject.org/updates/389-admin-console-1.1.10-1.el7
[4] 
https://lists.fedoraproject.org/archives/list/epel-devel%40lists.fedoraproject.org/message/KZ4NRQLPNRWSJNJDMGKMYBC3E57X74TZ/
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] HEADS UP: ppc64le is now enabled in epel7

[Peter Robinson]

Hi All,

The vast majority of builds are now done, imported and signed for
ppc64le in epel7 so the architecture is now enabled in koji.

TL;DR: If you have issues ask on this thread or on IRC in #epel or #fedora-ppc

We ran into a bunch of build issues (even on x86_64/ppc64) and have
submitted fixes for builds with issues, some of these are still
filtering through bodhi so please add karma in bodhi.

The major bits that are missing are:
* Globus stack - I'll this up in the next couple of days, any help and
direction appreciated, ping me on IRC.
* Haskell bootstrap - I'm working with the maintainer to bootstrap
this on the arch
* cross* - the maintainer is working with the Fedora secondary team to
complete this.

The above are relatively self contained so won't impact the vast
majority of people.

There's also no mono/golang/nodejs for ppc64le currently, in the case
of mono/noejs that should be fixed once the stacks rebase to their
respective 4.x releases. I know there was discussions in both cases to
do that outside of the ppc64le support.

Once everything has settled down, and the few missing bits mentioned
above are in place, I'll enable bodhi/mash for it next week and it'll
head out to the mirrors.

I don't expect any major issues in terms of builds, we obviously
already have ppc64 and ppc64le is Little Endian like x86_64, RHEL
Server for ppc64le is also much closer to x86_64 in terms of
packages/features than it's big endian sibling and I've noticed in
checking all the builds we already have a bunch more EPEL packages for
ppc64le than ppc64.

It's possible that a ppc64le build for a particular NVR might have
slipped through the cracks, if so let me know and I'll ensure I get it
in place.

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

[EPEL-devel]Re: Any news on alternative arch support?

[Peter Robinson]

>> I'm the secondary architecture release engineering lead. I've not yet
>> decided how to proceed with s390 support in EPEL. I've got a couple of
>> ideas but nothing that is final. In the next few weeks we'll be
>> building and importing ppc64le and once that is complete, as it's the
>> first new EPEL arch added in some time, I'll have a better idea how
>> best to proceed.
>>
>> I've got grave concerns about remote builder capability. We would need
>> to use the internal Red Hat mainframe but the remote ppc64le builders
>> for COPR have been less that stellar causing consistent issues for the
>> infrastructure team so to say I'm cautious in this regard doesn't even
>> come close. I have another idea but I need to find some time to test
>> that option to see if it's feasible.
>
> Hi Peter, thanks for the update. Does the internal Red Hat mainframe
> count as a remote builder as well? Presumably it wouldn't have the
> same reliability issues that plague the remote ppc64le builders. For
> COPR are you looking for additional hardware or will you use the internal
> Red Hat mainframe as well?

If it's not in the same physical datacentre it's classed as remote. So
yes, it's remote. I can't say anymore about Red Hat's infrastructure.

The COPR infrastructure is a completely unrelated set of
infrastructure, it was used as an example of how problematic remote
infrastructure can be.

These are all considered production because a lot of people rely on
it. People get woken up in the night and on the weekends if things are
unavailable. This is a problem for me even if it's not me that's being
woken up, we need to ensure there's escalation paths, means of
mitigation etc. I'm not currently got time to deal with that. It's on
my todo list, no I don't have a ETA.

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

[EPEL-devel]Boostrapping a new architecture for EPEL

[Peter Robinson]

Hi All,

So it's been discussed a little about doing a EPEL bootstrap for new
architectures. We have a number of arches wanting to do this (ppc64le,
aarch64, i686, s390x). So ppc64le will be our first and this is an
overview of the process I'll be using to do it. Once it's complete
I'll do a better write up as I suspect some things will evolve as we
go on down the path.

So the general overview of the process is:

1) add new builders to koji (ppc64le complete)
2) create separate inherited build target and tag
(epel7-archbootstrap) with associated architecture
3) run scratch builds in that target using the git commit hashes from
the latest builds in the epel7, epel7-testing and epel7-candidate tags
4) For each scratch build completed, run mergeScratch(task_id)
5) when all builds are complete enable the arch on the main epel7 target
6) sign all new packages
7) update bodhi, pkgdb, mash configs
7) mirror out

I have some scripts to do the above which I'll publish for reference
once I've cleaned them up a little.

This process isn't perfect. The new arch builds may not have the exact
same build dependency NVRs because, at least in the case of ppc64le,
the first EL7 release with .el7 distags is 7.2 and obviously most of
epel7 is built against < 7.2. The mergeScratch koji API call imports
all the build logs which helps mitigate this from a debug PoV. There's
not really a good way to deal with this, and obviously once the new
arch is enabled they'll be the same moving forward. I don't see it as
an issue really, just making note of it here for reference.

Looking at the current stable epel7 builds, as of a couple of days
ago, we have around 4763 source packages, of which 2686 are noarch
(and hence don't need to be rebuilt) and a touch under 2077 (2077 at
time of check) are arch dependent.

Let me know of any queries, questions, concerns etc

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

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

[Peter Robinson]

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

Good question. Shortly after I hit send on the email I realised I
missed that and one other point.

On packages that need a bootstrap they'll be handled on a case by case
manner as I suspect in each case there's some specific procedure.

The other issue was packages with dependencies in EPEL itself like a
toolchain stack or a desktop environment. Similar to the first we
might need a couple of passes of builds here.

I'm going to do an initial dry run to see how we stand for both of the
above to get a better idea where we stand.

The other issue we'll likely have, as bought up on the list earlier
today is EPEL packages that are FTBFS against 7.2. We had a similar
issue actually doing the initial arch bringup of ppc64le internally
and it was a process of actually fixing the failures on the primary
arches at the same time. Again I'll deal with this on a case by case
basis.

As mentioned in my original email the above process isn't perfect and
it'll be adjusted as necessary as we go, it's not something we're
really done before mid rhel cycle.

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

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

[Peter Robinson]

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

Sorry, that's not going to happen, but if you've got a list of package
sets that need specific bootstrapping that would be useful.

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

[EPEL-devel]Re: Is that EPEL 7 support ppc64 little endian

[Peter Robinson]

On Wed, Nov 25, 2015 at 5:14 AM, Gang U Xu <xugan...@cn.ibm.com> wrote:

> Hi all,
>
> Our HW is P8.
> Do you know if EPEL 7 support ppc6e little endian?
>
> I can find some packages with ppc64.
> For example, https://dl.fedoraproject.org/pub/epel/7/ppc64/
> I guess it is big endian but not sure.
>
> Could anyone confirm?
> Or could anyone help to guide me where I can find repo with ppc64 little
> endian?
>

It doesn't currently, but it will soon. I'm currently working out all the
details for the bootstrap, once I have a complete process an overview will
be posted here, one it's complete, signed and on the mirrors there will be
an announcement sent.

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

[EPEL-devel]Re: repoclosure/broken deps for RHEL7.2

[Peter Robinson]

On Wed, Nov 25, 2015 at 2:32 AM, Orion Poplawski  wrote:
> Could some please run a repoclosure/broken deps report for EPEL7 with
> RHEL7.2?  I tried, but I only have rhel7 server which is missing some
> components in the EPEL7 buildroot.  So I think this will have to be done by
> releng.  It seems that there are some soname bumps in RHEL7.2:
>
> libvala-0.20.so.0 -> libvala-0.26.so.0
> libical.so.0()(64bit) -> libical.so.1()(64bit)  (this seems to have the
> biggest impact)

The gnome desktop was rebased to 3.14, I know there was a bunch of
compat packages introduced but I've not looked at the exact details.

> Also, openmpi was bumped from 1.6.4 to 1.10.0, but there is a
> compat-openpi164 package so no dep breakage.  But it probably makes sense to
> rebuild openmpi packages.

Possibly.

> Plus I think there are a fair number of other broken deps in EPEL that have
> gone unnoticed for a while.

I'll have a look, I'm outlining a means of bootstrapping new
architectures so I'll have a look.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel]New EPEL PPC builders in koji

[Peter Robinson]

Hi All,

Just to give a heads up we now have some shiny new builders VMs for
PPC in EPEL. They should be at least as fast as the x86_64 builders.
We've also  doubled the amount to four.

They're currently running Fedora 21 as I will need to very shortly
rebuild the underlying hypervisors but once that is done they'll all
be shiny Fedora 23. This will probably be next week some time.

In the interim let me know if  you see any issues with builds etc so I
can investigate.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

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

[Peter Robinson]

On Fri, Nov 20, 2015 at 5:09 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Fri, 20 Nov 2015 10:50:31 -
> zika...@yahoo.com wrote:
>
>> Hi everybody
>>
>> Now that Fedora 23 is out, do you have some precision for If/when
>> EPEL packages will be out for Centos 7 32 bits ?
>
> Not really. I think the next plan was to look at enabling ppc64le and
> see how that goes, then take what we have learned from that and do
> i686.

And I'm dealing with the process and write up of the general direction
of that at the moment, was planning on sending out an email outline
the initial rough plan this evening.

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

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

[Peter]

On 10/16/2015 02:54 PM, Stephen John Smoogen wrote:
> soon will be a while. There needs to be testing and possible changes
> to koji to support the issue of dealing with one build root coming
> from one source (RHEL) and another one coming from another (CentOS).
> The build infrastructure is under a freeze until Fedora 23 is released
> sometime this month and then work on this can hopefully. This may end
> up being a "oh look it already works! just add this config" or it
> could be a "OMG my eyes are melting". IN either case, I would not
> expect it til November/December.

Let's really hope for the former.  From experience I can say that most
of the packages build without any changes and a small number require a
minor tweak in the spec file.

Anyways, thanks for the definitive answer Stephen, I look forward to
being able to use epel on my 32 bit laptops without having to rebuild
half the repo myself.


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

Re: [EPEL-devel] epel CD

[Peter]

On 10/16/2015 07:19 AM, Stephen John Smoogen wrote:
> [smooge@batcave01 epel]$ du -shc ./5 ./6 ./7
> 22G ./5
> 50G ./6
> 32G ./7
> 103G total
> 
> That is several (hundred) cdroms of data.

Just out of curiosity, what is the space for 7/x86_64 ?  I'm guessing
this would be small enough to fit onto a double-layer DVD.  If you then
donk the debug tree from there you could probably fit the rest onto a
single layer DVD, the vast majority of people would not care for more
than a single arch of binary-only packages from a single release and
have no need for -debuginfo packages.  I'm not saying that epel should
release this, but it would be much more reasonable for an individual to
burn this subset to a DVD for their own use.


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

Re: [EPEL-devel] epel CD

[Peter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/17/2015 03:44 AM, Kevin Fenzi wrote:
> We provide a handy way to answer this sort of question:
> 
> http://dl.fedoraproject.org/pub/DIRECTORY_SIZES.txt

Oh cool, I had no idea about that.

> 15G   /pub/epel/7/x86_64 8.7G /pub/epel/7/x86_64/debug

So you'd need 6.3G for all the binary epel7 x86_64 packages, they'd
fit on a double-layer DVD but not a cheaper single-layer one.

Similarly you'd need 11.4 for epel 6 x86_64 so that won't work unless
you donk some packages first, but it'd be fine on a 16G USB stick,
similar for i386.  epel 5 is smaller but would still need a
double-layer disk for x86_64, i386 is only 4.6G, though, so it would
barely fit on a single-layer disk.

It is possible that compression might be able to help with these as
well but I think that the rpms are already compressed.


Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWIa/KAAoJEAUijw0EjkDvYL4IALV+UDRxvA0PxfAIawatOvq6
4kuc9Hbl1b6l6JYyre4Gn37aHgfDr0kwbLqHOKYIyu7PCDgR04+Jy93zuLYMPRTi
IB+naF6Glv/ymoUSkTSPUCLpunH+cQ2u7nA+eU4uLdNuPTOcOvX/Dk7LxlmqzSKD
c0fAQE5pQ3PR3i4KGLoEL3f6dKNGXJPI2ZAOGsPwEce4ftUzVPrRKfAu4hxoVxE1
vdUMQU4gnQLX0erpaxp2JsaEHIULiXB09a4uTjOxAwlqK8gUEif8nkUvgmvsVbbE
EwopNDK6C82kLL2MCLEpo3VKFrhVAELMJBBM6SkDHeN3HEHaCcJ0KI82mSR3fQw=
=L19F
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

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

[Peter Robinson]

Hi,

 I would like to suggest a great addition to the EPEL, the z Systems
 architecture (s390x).
 I have seem a great number of requests around EPEL for z Systems, its
 definitely a growing platform around Linux as IBM keeps offering better and
 more efficient servers that are basically a datacenter in a box - which is a
 great way for customers to reduce costs by consolidating Linux workloads.
 EPEL repository to s390x can be a great way to allow customers to try an
 unsupported package that still not available to RHEL on z Systems - that can
 in time mature, and can skip some of the processes to make into the RHEL for
 z Systems distro.

Thanks for the sales pitch... please check your sales hat at the EPEL door :)

Where is the great number of requests for EPEL for system-Z? Can you
quantify the demand?

 The idea is to offer more technology options (Fedora Packages) to customers
 using RHEL on z Systems - this can flag us what packages are customers
 really interested into for RHEL on z Systems that are still not available in
 the Enterprise distro.
 Please let’s brainstorm this suggestion here, IBMers, community members,
 Fedora members, RedHatter, you are all welcome to join this discussion.

So the concerns I have regarding this that I've not really yet seen
addressed on this thread are:
1) who's going to do this work? Setting up a new EPEL architecture
isn't an insignificant amount of work (like a new arch in Fedora).
There's an expectation of people to be around to assist in problems
with package builds etc
2) even with the free emulators mentioned in the thread how would
people test this on those. I don't believe there's CentOS for 390x yet
3) what RHEL releases do you expect to support?

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

[EPEL-devel] EPEL 7 i386

[Peter]

Any plans for EPEL 7 i386 now that there is a beta out for CentOS 7 i386?


Peter
___
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

[Peter Robinson]

 Peter Robinson pbrobin...@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

 From an infrastructure PoV the advantage that Power8 hardware has is
 that it's much closer to x86 in a number of ways and it'll enable us
 to mimic the deployment of things like virt builders in a single
 contiguous manner across all architectures to enable more simplified
 standardised manner to ease burden and increase automation from an
 infra PoV

 Thats good.

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

Re: EPEL noip and pnp4nagios epel7 availibility

[LOEFFLER Peter]

I reported the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1135766
Notice that there was already one for fedora 19: 
https://bugzilla.redhat.com/show_bug.cgi?id=914952


From: Christopher Meng [cicku...@gmail.com]
Sent: Sunday, August 31, 2014 1:42 AM
To: LOEFFLER Peter
Cc: EPEL Development List
Subject: Re: EPEL noip and pnp4nagios epel7 availibility

On Sat, Aug 30, 2014 at 7:55 PM, LOEFFLER Peter
peter.loeff...@herold.at wrote:

 I think it's a good idea to switch to systemd.
 Did i get it right that i shoud report a bug that a systemd script is missing 
 and you will offer it at bugzilla?

You can report a bug first, I will arrive there then. The systemd
script problem should be fixed on all branches.
[http://www.herold.at/images/hbdat_logo.gif]http://www.herold.at

HEROLD Business Data GmbH
Guntramsdorfer Straße 105
2340 Mödling

FN 233171z
Landesgericht Wiener Neustadt

Besuchen Sie uns online und mobil www.herold.at!

Weitere Informationen zu unseren Produkten finden Sie unter:
http://ichbinderherold.at
Oder in unserem Video auf YouTube.http://www.youtube.com/watch?v=i--5-weI7Ck

[http://www.herold.at/images/fb_icon_mail.gif]http://www.facebook.at/derheroldWerden
 Sie Fan von HEROLD auf Facebook!


Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

EPEL noip and pnp4nagios epel7 availibility

[LOEFFLER Peter]

Hi,

Will the packages noip and pnp4nagios be available in the final epel7 
repository?

Regards,
Peter

[http://www.herold.at/images/hbdat_logo.gif]http://www.herold.at

HEROLD Business Data GmbH
Guntramsdorfer Straße 105
2340 Mödling

FN 233171z
Landesgericht Wiener Neustadt

Besuchen Sie uns online und mobil www.herold.at!

Weitere Informationen zu unseren Produkten finden Sie unter:
http://ichbinderherold.at
Oder in unserem Video auf YouTube.http://www.youtube.com/watch?v=i--5-weI7Ck

[http://www.herold.at/images/fb_icon_mail.gif]http://www.facebook.at/derheroldWerden
 Sie Fan von HEROLD auf Facebook!


Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Updating llvm/clang?

[Peter Lemenkov]

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

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


-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Retire from maintainership duties

[Peter Lemenkov]

2013/11/7 Sam Kottler skott...@redhat.com:

 I'll take over nagios-plugins, nagios-plugins-check_sip, and nrpe.

 Can you orphan those packages so I can become the owner?

Done.

-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Retire from maintainership duties

[Peter Lemenkov]

2013/11/7 Ken Dreyer ktdre...@ktdreyer.com:
 On Wed, Nov 6, 2013 at 8:54 AM, Peter Lemenkov lemen...@gmail.com wrote:

 Thanks a lot for maintaining ejabberd. I actually just set this
 service up last week on a CentOS 6 server, and my co-workers are
 benefitting from the work that you've done to make it a smooth
 experience in EPEL.

Unless you have a RHEL license, consider using Debian or Ubuntu LTS
for that. They have a sane model of updating packages and picking up
from testing branches. Also I'd recommend packages from the upstream
vendor:

http://www.process-one.net/en/ejabberd/archive/

Although they stopped building rpms but anyway their packages are more
up-to-date and not very different from Fedora/EPEl ones (missing parts
are systemd integration, polkit, preliminary kerberos support and few
more - nothing really serious).
-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL installing erlang on RHEL6

[Peter Lemenkov]

2013/9/2 Vadakkeveedu, Thara thara.vadakkeve...@kronos.com:

 I tried yum install erlang with the –disablerepo=repo*  option
 I still get the same errors:
...
 --- Package wxGTK.x86_64 0:2.8.12-1.el6.rf will be installed

This package doesn't belong to EPEL or RHEL (CentOS). So rpmforge is
still active.

http://paste.fedoraproject.org/36544/81401271

-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel