[EPEL-devel] Re: RHEL 7.5 fallout

[Kevin Fenzi]

On 04/11/2018 03:29 PM, Orion Poplawski wrote:
> These were koschei builds of my epel7 packages.  Seems to have cleared up now
> though so perhaps just an import issue.
> 
> On 04/10/2018 08:18 AM, Stephen John Smoogen wrote:
>> Do you have any information that htis is EPEL packages or just EL7.5 items?
>>
>> On 10 April 2018 at 09:57, Orion Poplawski  wrote:
>>> I'm seeing this in the root.log of some packages:
>>>
>>> DEBUG util.py:439:  Error: initscripts conflicts with
>>> 1:redhat-release-server-7.4-1.x86_64

This was caused by us not updating the local redhat-release-server
version we built in epel7. Why, you might ask did we do such a thing?
It's because aarch64 came in with a newer redhat-release-server that set
the dist tag to 'el7a'. Since we did not want all epel7 builds to be
el7a, we built a newer one in epel7-build with that set back.

Ideally we would come up with a better solution here, possibly in
epel-release so we don't need to rebuild this weird package every RHEL
release.

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1fbdf7f103   
chromium-65.0.3325.181-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2074629ed3   
drupal7-7.58-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e12bc7bed5   
nodejs-6.14.0-1.el7 libuv-1.19.2-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7c95e7ac21   
libofx-0.9.9-2.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-13062a4d15   
wordpress-4.9.5-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e56f478565   
koji-1.15.1-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9f8e93d154   
python-jwt-1.6.1-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2c81054303   
remctl-3.14-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

bindfs-1.13.9-1.el7
fleet-commander-admin-0.10.7-1.el7
fleet-commander-client-0.10.2-2.el7
gsi-openssh-7.4p1-2.el7
js-jsroot-5.4.1-1.el7
knot-2.6.6-1.el7
perl-DateTime-Format-Strptime-1.5400-2.el7
python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el7
rpkg-1.53-1.el7

Details about builds:



 bindfs-1.13.9-1.el7 (FEDORA-EPEL-2018-3ee539fee7)
 Fuse filesystem to mirror a directory

Update Information:

- update to new version 1.13.9 + spec cleanup / modernization




 fleet-commander-admin-0.10.7-1.el7 (FEDORA-EPEL-2018-fe7d422e12)
 Fleet Commander

Update Information:

Updated to release 0.10.7




 fleet-commander-client-0.10.2-2.el7 (FEDORA-EPEL-2018-ed3db39416)
 Fleet Commander Client

Update Information:

Fixed building dependencies




 gsi-openssh-7.4p1-2.el7 (FEDORA-EPEL-2018-4265d81756)
 An implementation of the SSH protocol with GSI authentication

Update Information:

Sync with openssh update.




 js-jsroot-5.4.1-1.el7 (FEDORA-EPEL-2018-7065dfe074)
 JavaScript ROOT - Interactive numerical data analysis graphics

Update Information:

## Changes in 5.4.1 1. Fix - monitoring mode in draw.htm page 2. Fix - zooming
in colz palette 3. Fix - support both 9.x and 10.x jsdom version in Node.js
(#149) 4. Fix - draw axis main line with appropriate attributes (#150) 5. Fix -
use axis color when drawing grids lines (#150) 6. Fix - when set pad logx/logy,
reset existing user ranges in pad 7. Fix - avoid too deep calling stack when
drawing many graphs or histos (#154) 8. Fix - correctly (re)draw tooltips on
canvas with many subpads




 knot-2.6.6-1.el7 (FEDORA-EPEL-2018-a356b81e75)
 High-performance authoritative DNS server

Update Information:

Knot DNS 2.6.6 (2018-04-11) ===  Features: -  -
New EDNS option counters in the statistics module  - New '+orphan' filter for
the 'zone-purge' operation  Improvements: -  - Reduced memory
consuption of disabled statistics metrics  - Some spelling fixes (Thanks to
Daniel Kahn Gillmor)  - Server no longer fails to start if MODULE_DIR doesn't
exist  - Configuration include doesn't fail if empty wildcard match  - Added a
configuration check for a problematical option combination  Bugfixes: -
- NSEC3 chain not re-created when SOA minimum TTL changed  - Failed to start
server if no template is configured  - Possibly incorrect SOA serial upon
changed zone reload with DNSSEC signing  - Inaccurate outgoing zone transfer
size in the log message  - Invalid dname compression if empty question section
- Missing EDNS in EMALF responses

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e4e96fbf3f   
drupal7-7.58-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b5d9f8f571   
wordpress-4.9.5-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-870a92fcc5   
koji-1.15.1-1.el6
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5aca1d385d   
remctl-3.14-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-158680d651   
python-gunicorn-18.0-2.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd6e4a3f0b   
python34-3.4.8-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el6
rpkg-1.53-1.el6
voms-clients-java-3.3.0-2.el6

Details about builds:



 python-fedmsg-meta-fedora-infrastructure-0.24.1-1.el6 
(FEDORA-EPEL-2018-527225181e)
 Metadata providers for Fedora Infrastructure's fedmsg deployment

Update Information:

Update to 0.24.1  Changelog is at: https://github.com/fedora-
infra/fedmsg_meta_fedora_infrastructure/blob/develop/CHANGELOG.rst#0241




 rpkg-1.53-1.el6 (FEDORA-EPEL-2018-7f16b8d5df)
 Python library for interacting with rpm+git

Update Information:

- Use NSVs and not build IDs with module-build-local --add-local-build (mprahl)
- Fix docstring of test_module_build_local_with_skiptests (mprahl) - Add
long_description to package (cqi) - Support local module builds when there are
uncommitted changes (mprahl) - Fix clarifying error that occurs when mbs-manager
is not installed (mprahl) - Add support for Module Stream Expansion (MBS API v2)
(mprahl) - Show errors when a module build fails (mprahl) - Move full download
url construction to separate method (frostyx) - Fix compose related params for
container-build (lucarval) - Avoid calling /usr/bin/python in tests (miro) -
Change default rpmlint configuration file (athoscr) - Use
koji.grab_session_options() rather than opencoding it (cfergeau)




 voms-clients-java-3.3.0-2.el6 (FEDORA-EPEL-2018-01eb003c2c)
 Virtual Organization Membership Service Java clients

Update Information:

Add trigger scriptlet to put back alternatives when UMD voms-clients3 is
removed.

___
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.5 fallout

[Orion Poplawski]

These were koschei builds of my epel7 packages.  Seems to have cleared up now
though so perhaps just an import issue.

On 04/10/2018 08:18 AM, Stephen John Smoogen wrote:
> Do you have any information that htis is EPEL packages or just EL7.5 items?
> 
> On 10 April 2018 at 09:57, Orion Poplawski  wrote:
>> I'm seeing this in the root.log of some packages:
>>
>> DEBUG util.py:439:  Error: initscripts conflicts with
>> 1:redhat-release-server-7.4-1.x86_64
>>
>> --
>> Orion Poplawski
>> Manager of NWRA Technical Systems  720-772-5637
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane   or...@nwra.com
>> Boulder, CO 80301 https://www.nwra.com/
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 
> 
> 


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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

[James Hogarth]

On 11 April 2018 at 20:32, Dylan Silva  wrote:
> I am very afraid I am jumping into a lion's den here... However, I am going 
> to try to alleviate some concerns.
>
> Our move from EPEL to Extras was actually to solve for the needs of RHEL and 
> the RHEL System Roles.  We needed to be in a channel that customers could 
> consume from that wasn't EPEL.
>
> Upon our move to Extras, we immediately identified a problem.  That problem 
> was, we Ansible, were not able to release as often as we preferred/needed for 
> our customers.  We also were facing confusion about what did support mean 
> once a package was inside of Extras.
>
> As such, we made the decision to two things.
>
> 1. Deprecate Ansible from Extras.
> 2. Provide access to Ansible via a Red Hat trusted delivery mechanism.
>
> For #2, EPEL obviously is not the route to take for some customers.  So, we 
> decided that all RHEL customers would have full access to the Subscription 
> channel.  We also specified that if a customer wanted support, they would 
> still need to purchase a subscription.
>
> We had a very delicate situation here.  There were a lot of check and 
> balances that had to be met before we could make any announcement. So that's 
> why it has been "a little quiet."
>
> The security advisory link posted above, and this link 
>  attempt to cover the bulk of the 
> possible questions that may arise.
>
> That being said, we still aim to provide our customers/users the ability to 
> obtain Ansible any way they choose.  So if the user does not want to use the 
> channel or cannot use it for any reason, they still have the ability to pull 
> from EPEL or our releases.ansible.com pages. As far as we're concerned, it is 
> functionally the same application no matter where it comes from.. If a 
> customer has a subscription; they will be supported.
>
> I, the Product Manager of Ansible Engine, am staying on top of these concerns 
> as they come by.  So far, no huge customer/user concerns have caused any 
> alarm.  Most users have embraced the moves, and have continued to automate.

Thank you very much for joining the conversation.

It's a significant relief that from your point of view it doesn't
matter where it comes from.

For what it is worth we (speaking somewhat on behalf of my team but
not as a spokesperson of the company I'm presently contracted at)
prefer it to come from EPEL, and are grateful to see it return there
from extras for a variety of reasons.

We are also very grateful for your preview/nightly repositories and
plan in our CI environment to take advantage of these in a more
aggressive fashion to catch regressions early that may affect us so we
can report them upstream ASAP in future.

It's useful and refreshing to get some of the background of the
decisions made, and though communication wasn't great, it's all nice
and plain for people to find in the archives and we can move forward
in a positive fashion as a community :)

Now ... time to go through a few dozen roles switching out 'with_*'
for 'loop' and fixing up 'when' conditionals ... got to hurry before
2.9 appears :)
___
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

[Dylan Silva]

I am very afraid I am jumping into a lion's den here... However, I am going to 
try to alleviate some concerns.

Our move from EPEL to Extras was actually to solve for the needs of RHEL and 
the RHEL System Roles.  We needed to be in a channel that customers could 
consume from that wasn't EPEL. 

Upon our move to Extras, we immediately identified a problem.  That problem 
was, we Ansible, were not able to release as often as we preferred/needed for 
our customers.  We also were facing confusion about what did support mean once 
a package was inside of Extras.  

As such, we made the decision to two things. 

1. Deprecate Ansible from Extras.
2. Provide access to Ansible via a Red Hat trusted delivery mechanism. 

For #2, EPEL obviously is not the route to take for some customers.  So, we 
decided that all RHEL customers would have full access to the Subscription 
channel.  We also specified that if a customer wanted support, they would still 
need to purchase a subscription. 

We had a very delicate situation here.  There were a lot of check and balances 
that had to be met before we could make any announcement. So that's why it has 
been "a little quiet."

The security advisory link posted above, and this link 
 attempt to cover the bulk of the 
possible questions that may arise. 

That being said, we still aim to provide our customers/users the ability to 
obtain Ansible any way they choose.  So if the user does not want to use the 
channel or cannot use it for any reason, they still have the ability to pull 
from EPEL or our releases.ansible.com pages. As far as we're concerned, it is 
functionally the same application no matter where it comes from.. If a customer 
has a subscription; they will be supported. 

I, the Product Manager of Ansible Engine, am staying on top of these concerns 
as they come by.  So far, no huge customer/user concerns have caused any alarm. 
 Most users have embraced the moves, and have continued to automate. 
___
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

[Stephen John Smoogen]

On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy  
> wrote:
>
>> I'm not in Ansible engineering or product management so take this with a
>> grain of salt. My understanding is that cadence of Ansible releases and
>> its aggressiveness in API changes makes it a bit less suitable to follow
>> a traditional RHEL 7 release cadence. A separate product channel allows
>> them to update packages at own cadence.
>>
>> I wonder how re-packaging for CentOS targets could happen with this
>> approach and probably moving it back to EPEL7 is indeed something that
>> makes more sense.
>
> Wouldn't a separate RHEL channel for a separate product, such as
> ansible, mean a separate channel for CentOS to avoid precisely this
> confusion? Mixing it into EPEL and having it on a separate RHEL
> channel would be *bad* for anyone who activates that separate channel.
> They'd have to filter it out of EPEL to ensure that the streams don't
> get crossed on any updates from Red Hat. I understand that this is one
> of the main reasons EPEL never carries packages that overlap with RHEL
> published software.

It is a lot more nuanced than that. EPEL builds packages that do not
overlap with the following channels:


rhel-7-server-extras-rpms/
rhel-7-server-optional-rpms/
rhel-7-server-rpms/
rhel-ha-for-rhel-7-server-rpms/
rhel-server-rhscl-7-rpms/

These are chosen because they were the base set originally and other
channels which might be available can have items which conflict with
each other. This means that EPEL can conflict with somethings inside
of "RHEL" but so can things are in "RHEL".

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

[James Hogarth]

On 11 April 2018 at 14:30, Kevin Fenzi  wrote:
> On 04/11/2018 04:52 AM, James Hogarth wrote:
>
>>
>> Especially if EPEL7 now has a clash with an optional repo that is available
>> to all subscribers...
>>
>> There are priority or exclude filters people will need to add to their yum
>> repository configurations that they may not be otherwise aware of if they
>> want the "official Red Hat" build of it etc etc
>
> Well, it's available to all, but I would think you would have to enable
> it, but yes, an announcement would help people decide where to get
> ansible from.


Right ... but if someone wants to use the "supported" ansible as part
of their support contract, then given how common EPEL is on systems
they really do need to know that they must add an excludepkgs to their
EPEL yum configuration or alternatively alter priorities.

Otherwise it's going to be very "arbitrary" which ansible they get.
___
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

[Kevin Fenzi]

On 04/11/2018 04:52 AM, James Hogarth wrote:

> 
> Especially if EPEL7 now has a clash with an optional repo that is available
> to all subscribers...
> 
> There are priority or exclude filters people will need to add to their yum
> repository configurations that they may not be otherwise aware of if they
> want the "official Red Hat" build of it etc etc

Well, it's available to all, but I would think you would have to enable
it, but yes, an announcement would help people decide where to get
ansible from.

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

[Kevin Fenzi]

On 04/10/2018 11:05 PM, James Hogarth wrote:

> At this point, no offense to Nirik and the maintenance he does on the
> package, I'm actually tempted to just grab it from upstream directly at
> https://releases.ansible.com/ansible/rpm/

Feel free. Do whatever you feel is best for you.

> 
> At least then I can get consistency with selection of stable, preview or
> nightly ...

I don't really understand what you mean here... EPEL is going to pushing
stable releases... with 2 weeks in testing.

With 2.5.x upstream is going to try and do minor releases every 2-3weeks
with all bugfixes that are landed then. EPEL will package those.

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

[Kevin Fenzi]

On 04/11/2018 02:04 AM, Peter Robinson wrote:
> There probably should be an announcement sent to the epel announce
> list then it gets to a wider audience so more people know this.

Yep. But the RH announcement only went out monday, and I am at a
hackfest this week. I'll try and get something out this week or early next.

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

[James Hogarth]

On Wed, 11 Apr 2018, 10:05 Peter Robinson,  wrote:

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

Especially if EPEL7 now has a clash with an optional repo that is available
to all subscribers...

There are priority or exclude filters people will need to add to their yum
repository configurations that they may not be otherwise aware of if they
want the "official Red Hat" build of it etc etc

> 
>
___
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: Ansible in EL7

[James Hogarth]

On Wed, 11 Apr 2018, 01:26 Todd Zullinger,  wrote:

> James Hogarth wrote:
> > On Wed, 11 Apr 2018, 00:59 Todd Zullinger,  wrote:
> >> 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.
> >
> > Cheers for the info.
> >
> > It wasn't mentioned on the devel list, I didn't see it in the 7.5 release
> > notes and it was still in extras when I checked a short while ago.
> >
> > In that case yes I agree it makes total sense to return to epel7
> >
> > I wonder why they dropped it when the whole point of them bringing it in
> to
> > begin with was for Satellite and Tower to have it in the standard RHEL
> > repos.
> >
> > Seems so pointless to have only had one release there!
>
> Indeed, it was a bit strange.  Perhaps someone with more
> insight into the rationale can comment.  I have no
> particular knowledge of things, but maybe keeping a fast
> moving project like ansible in even the RHEL extras channel
> was a problem.
>
> Maybe the plan with the move to the "Ansible Engine" channel
> is to work closer with subscribers on migrating from version
> to version.  And non-subscribers can just follow it in EPEL.
>
> I'd be interested in hearing more about the change, though I
> suspect those who know more either aren't on these lists or
> can't say more than Red Hat's advisory has already.
>
>
At this point, no offense to Nirik and the maintenance he does on the
package, I'm actually tempted to just grab it from upstream directly at
https://releases.ansible.com/ansible/rpm/

At least then I can get consistency with selection of stable, preview or
nightly ...



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