A coordinated plan for ansible-collection updates in EPEL?
by Orion Poplawski
So, I'm wondering if we should have some kind of (at least
semi-)coordinated plan for updating ansible collections in EPEL?
My initial thought is we would sort of piggy back on to what the
"ansible" community collection bundles on top of the ansible-core
package provided by RedHat. So, currently in EL8.7 we have:
ansible-core-2.13.3
and EPEL ships:
ansible-6.3.0 - which corresponds to the ansible community package that
ships with ansible-2.13.3.
Then we would endeavor to ship the individual package collection
versions that are contained in that package, .e.g: (taken from the
MANIFEST.json files):
ansible.posix 1.4.0
ansible.utils 2.6.1
chocolatey.chocolatey 1.3.0
community.docker 2.7.1
community.general 5.5.0
community.libvirt 1.2.0
community.mysql 3.4.0
community.rabbitmq 1.2.2
containers.podman 1.9.4
netbox.netbox 3.7.1
For reference, currently in epel we have:
ansible-collection-ansible-posix.noarch 1.4.0-1.el8 epel
ansible-collection-ansible-utils.noarch 2.6.1-1.el8 epel
ansible-collection-chocolatey-chocolatey.noarch 1.4.0-1.el8 epel
ansible-collection-community-docker.noarch 2.6.0-1.el8 epel
ansible-collection-community-general.noarch 3.8.9-1.el8 epel
ansible-collection-community-libvirt.noarch 1.1.0-3.el8 epel
ansible-collection-community-mysql.noarch 3.5.1-1.el8 epel
ansible-collection-community-rabbitmq.noarch 1.2.3-1.el8 epel
ansible-collection-containers-podman.noarch 1.10.1-1.el8 epel
ansible-collection-netbox-netbox.noarch 3.7.1-1.el8 epel
However, it's hard for me to resist the allure of the shiny and new, so
I've updated chocolatey. Similarly some others have been updated to
later versions.
The other interesting case here is community.general - ansible has it at
5.5.0, but it looks like Maxwell G has taken the generally preferred
course for EPEL of sticking with the stable release track of 3.X.
Although I suspect very few collections maintain multiple release tracks
(no idea).
I don't really have a particular agenda here, just trying to solicit
people's thoughts. Personally I like minimal installs so I have been
only using ansible-core + collections on the systems I maintain and
would like to continue to see them be usable together.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
1 year, 3 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Paul Howarth
On Mon, 30 Jan 2023 21:13:11 -0700
Orion Poplawski <orion(a)nwra.com> wrote:
> So, I'm wondering if we should have some kind of (at least
> semi-)coordinated plan for updating ansible collections in EPEL?
>
> My initial thought is we would sort of piggy back on to what the
> "ansible" community collection bundles on top of the ansible-core
> package provided by RedHat. So, currently in EL8.7 we have:
>
> ansible-core-2.13.3
>
> and EPEL ships:
>
> ansible-6.3.0 - which corresponds to the ansible community package
> that ships with ansible-2.13.3.
>
> Then we would endeavor to ship the individual package collection
> versions that are contained in that package, .e.g: (taken from the
> MANIFEST.json files):
>
> ansible.posix 1.4.0
> ansible.utils 2.6.1
> chocolatey.chocolatey 1.3.0
> community.docker 2.7.1
> community.general 5.5.0
> community.libvirt 1.2.0
> community.mysql 3.4.0
> community.rabbitmq 1.2.2
> containers.podman 1.9.4
> netbox.netbox 3.7.1
Sounds like a reasonable plan to me.
> For reference, currently in epel we have:
...
> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
> epel
I updated ansible-collection-community-libvirt to 1.2.0:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
> I don't really have a particular agenda here, just trying to solicit
> people's thoughts. Personally I like minimal installs so I have been
> only using ansible-core + collections on the systems I maintain and
> would like to continue to see them be usable together.
I too just use ansible-core + collections on the systems I maintain.
Regards, Paul.
1 year, 3 months
Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
2023-01-31T13:02:09Z Sagi Shnaidman <sshnaidm(a)redhat.com>:
Hi, Orion
Thanks for raising this question.
I use both ways - either ansible distro with all-inclusive, or ansible
(distro or "core") with specific collection installed separately when I
need a newer version of collection, for example. I wonder if it's
possible to continue to update collections to the newest versions anyway.
If someone wants to use the collection version provided in "big ansible",
they would use ansible 6.3.0 with all included. If they want a newer
collection, they can install a separate newest RPM.
But not sure if dependencies can be a problem here, like which collection
version depends on other collection versions (for example ansible.utils,
which is part of multiple collection dependencies).
Let me know what you think.
Thanks
On Tue, Jan 31, 2023 at 2:14 PM Paul Howarth <paul(a)city-fan.org> wrote:
> On Mon, 30 Jan 2023 21:13:11 -0700
> Orion Poplawski <orion(a)nwra.com> wrote:
>
>> So, I'm wondering if we should have some kind of (at least
>> semi-)coordinated plan for updating ansible collections in EPEL?
>>
>> My initial thought is we would sort of piggy back on to what the
>> "ansible" community collection bundles on top of the ansible-core
>> package provided by RedHat. So, currently in EL8.7 we have:
>>
>> ansible-core-2.13.3
>>
>> and EPEL ships:
>>
>> ansible-6.3.0 - which corresponds to the ansible community package
>> that ships with ansible-2.13.3.
>>
>> Then we would endeavor to ship the individual package collection
>> versions that are contained in that package, .e.g: (taken from the
>> MANIFEST.json files):
>>
>> ansible.posix 1.4.0
>> ansible.utils 2.6.1
>> chocolatey.chocolatey 1.3.0
>> community.docker 2.7.1
>> community.general 5.5.0
>> community.libvirt 1.2.0
>> community.mysql 3.4.0
>> community.rabbitmq 1.2.2
>> containers.podman 1.9.4
>> netbox.netbox 3.7.1
>
> Sounds like a reasonable plan to me.
>
>> For reference, currently in epel we have:
> ...
>> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
>> epel
>
> I updated ansible-collection-community-libvirt to 1.2.0:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
>
>> I don't really have a particular agenda here, just trying to solicit
>> people's thoughts. Personally I like minimal installs so I have been
>> only using ansible-core + collections on the systems I maintain and
>> would like to continue to see them be usable together.
>
> I too just use ansible-core + collections on the systems I maintain.
>
> Regards, Paul.
>
--
Best regards
Sagi Shnaidman
1 year, 3 months
Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
2023-01-31T14:05:11Z David Moreau-Simard <moi(a)dmsimard.com>:
Hi,
Answer in-line but I also want to extend an invititation to everyone here
to join #ansible-packaging on libera.chat (or #packaging:ansible.com on
Matrix) which is a low signal-to-noise ratio channel to talk about
Ansible packaging things such as this one :)
------- Original Message -------
On Tuesday, January 31st, 2023 at 8:01 AM, Sagi Shnaidman
<sshnaidm(a)redhat.com> wrote:
> Hi, Orion
> Thanks for raising this question.
>
> I use both ways - either ansible distro with all-inclusive, or ansible
> (distro or "core") with specific collection installed separately when I
> need a newer version of collection, for example. I wonder if it's
> possible to continue to update collections to the newest versions
> anyway. If someone wants to use the collection version provided in "big
> ansible", they would use ansible 6.3.0 with all included. If they want
> a newer collection, they can install a separate newest RPM.
>
> But not sure if dependencies can be a problem here, like which
> collection version depends on other collection versions (for example
> ansible.utils, which is part of multiple collection dependencies).
We took this use case into account when we refacoted the Fedora ansible
package to match the "post ansible 2.9 era", see:
* https://fedoraproject.org/wiki/Changes/Ansible5
*
https://src.fedoraproject.org/rpms/ansible/blob/rawhide/f/ansible.spec#_207
TL;DR:
* The ansible package installs collections to the python site-lib
* The ansible collections packages should (generally?) install to
/usr/share
* Installing manually from galaxy installs to ~/.ansible
The order of precedence makes it so galaxy-installed collections will
have priority over those installed by the collection packages which have
precedence over those installed by the ansible package.
There may be edge cases where mismatched dependencies could lead to
issues but I'm not sure we can do much about that.
> Let me know what you think.
>
> Thanks
>
> On Tue, Jan 31, 2023 at 2:14 PM Paul Howarth <paul(a)city-fan.org> wrote:
>> On Mon, 30 Jan 2023 21:13:11 -0700
>> Orion Poplawski <orion(a)nwra.com> wrote:
>>
>>> So, I'm wondering if we should have some kind of (at least
>>> semi-)coordinated plan for updating ansible collections in EPEL?
>>>
>>> My initial thought is we would sort of piggy back on to what the
>>> "ansible" community collection bundles on top of the ansible-core
>>> package provided by RedHat. So, currently in EL8.7 we have:
>>>
>>> ansible-core-2.13.3
>>>
>>> and EPEL ships:
>>>
>>> ansible-6.3.0 - which corresponds to the ansible community package
>>> that ships with ansible-2.13.3.
>>>
>>> Then we would endeavor to ship the individual package collection
>>> versions that are contained in that package, .e.g: (taken from the
>>> MANIFEST.json files):
>>>
>>> ansible.posix 1.4.0
>>> ansible.utils 2.6.1
>>> chocolatey.chocolatey 1.3.0
>>> community.docker 2.7.1
>>> community.general 5.5.0
>>> community.libvirt 1.2.0
>>> community.mysql 3.4.0
>>> community.rabbitmq 1.2.2
>>> containers.podman 1.9.4
>>> netbox.netbox 3.7.1
>>
>> Sounds like a reasonable plan to me.
>>
>>> For reference, currently in epel we have:
>> ...
>>> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
>>> epel
>>
>> I updated ansible-collection-community-libvirt to 1.2.0:
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
>>
>>> I don't really have a particular agenda here, just trying to solicit
>>> people's thoughts. Personally I like minimal installs so I have been
>>> only using ansible-core + collections on the systems I maintain and
>>> would like to continue to see them be usable together.
>>
>> I too just use ansible-core + collections on the systems I maintain.
>>
>> Regards, Paul.
>>
>
>
> --
> Best regards
> Sagi Shnaidman
1 year, 3 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Kevin Fenzi
On Tue, Jan 31, 2023 at 06:03:48PM +0000, Maxwell G wrote:
> On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
> Hi all,
Note that some folks cc'ed are not subscribed to epel-devel, so it
probibly rejected their posts. :(
>
> > Hi, Orion
> > Thanks for raising this question.
>
> Indeed!
>
> > I wonder if it's possible to continue to update collections to the
> > newest versions anyway. If someone wants to use the collection version
> > provided in "big ansible", they would use ansible 6.3.0 with all
> > included. If they want a newer collection, they can install a separate
> > newest RPM.
>
> I agree. I think we should update collections to the next major version
> (if it exists) after each RHEL minor release and then keep them updated
> with point releases in between. We update the ansible bundle to the next
> major version that corresponds to RHEL's ansible-core version at each
> RHEL minor release, so it makes to do the same with the standalone
> collection packages. Collection versions that are EOL upstream won't be
> tested with newer ansible-core versions.
Yes, when we first started to package collections we made sure (although
I have not checked if anything changed) that the seperately packaged
collections would override the bundled ones in the ansible package.
So, while the ansible collection of collections and ansible-core are
(and should be) closely tied together, the seperately packaged ansible
collections should be free to update as long as they continue to work ok
with ansible-core thats provided/etc.
So, in practice I personally have been thinking of 'ansible' as the
stable collection of collections, and the seperately packaged
collections as 'next' or 'fast moving' channel.
Just my 2cents.
kevin
1 year, 3 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Kevin Fenzi
On Tue, Jan 31, 2023 at 07:21:03PM -0700, Orion Poplawski wrote:
> On 1/31/23 11:03, Maxwell G wrote:
> > On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
> > Hi all,
> >
> > > Hi, Orion
> > > Thanks for raising this question.
> >
> > Indeed!
> >
> > > I wonder if it's possible to continue to update collections to the
> > > newest versions anyway. If someone wants to use the collection version
> > > provided in "big ansible", they would use ansible 6.3.0 with all
> > > included. If they want a newer collection, they can install a separate
> > > newest RPM.
> >
> > I agree. I think we should update collections to the next major version
> > (if it exists) after each RHEL minor release and then keep them updated
> > with point releases in between. We update the ansible bundle to the next
> > major version that corresponds to RHEL's ansible-core version at each
> > RHEL minor release, so it makes to do the same with the standalone
> > collection packages. Collection versions that are EOL upstream won't be
> > tested with newer ansible-core versions.
>
> Does this capture the general sentiment?
>
> - ansible is the static/stable collection of collections paired with the
> provided ansible-core for the life of the point release
>
> - ansible-collection-* packages will be at least the version of the
> collection in ansible, and optionally higher while giving due diligence to
> avoiding breaking changes.
That sounds mostly reasonable. I guess I could come up with a crazy case
like 'the version in ansible has some problem that wasn't noticed, so I
want to keep the seperate collection on a older version until it's
fixed' though.
kevin
1 year, 3 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Orion Poplawski
On 1/31/23 11:03, Maxwell G wrote:
> On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
> Hi all,
>
>> Hi, Orion
>> Thanks for raising this question.
>
> Indeed!
>
>> I wonder if it's possible to continue to update collections to the
>> newest versions anyway. If someone wants to use the collection version
>> provided in "big ansible", they would use ansible 6.3.0 with all
>> included. If they want a newer collection, they can install a separate
>> newest RPM.
>
> I agree. I think we should update collections to the next major version
> (if it exists) after each RHEL minor release and then keep them updated
> with point releases in between. We update the ansible bundle to the next
> major version that corresponds to RHEL's ansible-core version at each
> RHEL minor release, so it makes to do the same with the standalone
> collection packages. Collection versions that are EOL upstream won't be
> tested with newer ansible-core versions.
Does this capture the general sentiment?
- ansible is the static/stable collection of collections paired with the
provided ansible-core for the life of the point release
- ansible-collection-* packages will be at least the version of the
collection in ansible, and optionally higher while giving due diligence
to avoiding breaking changes.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
1 year, 3 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
Hi all,
> Hi, Orion
> Thanks for raising this question.
Indeed!
> I wonder if it's possible to continue to update collections to the
> newest versions anyway. If someone wants to use the collection version
> provided in "big ansible", they would use ansible 6.3.0 with all
> included. If they want a newer collection, they can install a separate
> newest RPM.
I agree. I think we should update collections to the next major version
(if it exists) after each RHEL minor release and then keep them updated
with point releases in between. We update the ansible bundle to the next
major version that corresponds to RHEL's ansible-core version at each
RHEL minor release, so it makes to do the same with the standalone
collection packages. Collection versions that are EOL upstream won't be
tested with newer ansible-core versions.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/They
1 year, 3 months
Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org
The following Fedora EPEL 8 Security updates need testing:
Age URL
62 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1f39b04ca0 kitty-0.26.5-7.el8
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9191f31d36 python-waitress-1.4.3-1.el8
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-80ad867af8 chromium-113.0.5672.92-1.el8
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-29e8ff9273 osslsigncode-2.5-3.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
R-qtl-1.60-1.el8
ansible-7.2.0-1.el8
ansible-collection-community-general-7.0.0-1.el8
dropbear-2019.78-5.el8
editorconfig-0.12.6-1.el8
fedora-license-data-1.21-1.el8
nickle-2.91-1.el8
python-pystemd-0.13.1-1.el8
xrdp-0.9.22-4.el8
Details about builds:
================================================================================
R-qtl-1.60-1.el8 (FEDORA-EPEL-2023-6bceedbc89)
Tools for analyzing QTL experiments
--------------------------------------------------------------------------------
Update Information:
R qtl 1.60
--------------------------------------------------------------------------------
ChangeLog:
* Tue May 16 2023 Mattias Ellert <mattias.ellert(a)physics.uu.se> - 1.60-1
- Update to 1.60
- Drop workaround for broken openblas on aarch64 in RHEL 8 and 9
Fixed in RHEL 8.8 and 9.2 respectively
--------------------------------------------------------------------------------
================================================================================
ansible-7.2.0-1.el8 (FEDORA-EPEL-2023-ca07fe358c)
Curated set of Ansible collections included in addition to ansible-core
--------------------------------------------------------------------------------
Update Information:
Update to ansible 7.2.0 in EPEL 8. We're updating community.general to the
latest version at the same as per <https://lists.fedoraproject.org/archives/sear
ch?q=A+coordinated+plan+for+ansible-
collection+updates+in+EPEL%3F&page=1&mlist=epel-
devel%40lists.fedoraproject.org&sort=date-asc>.
--------------------------------------------------------------------------------
ChangeLog:
* Fri Feb 10 2023 Maxwell G <gotmax(a)e.email> - 7.2.0-1
- Update to 7.2.0.
* Thu Feb 2 2023 Maxwell G <gotmax(a)e.email> - 7.1.0-1
- Update to 7.1.0.
--------------------------------------------------------------------------------
================================================================================
ansible-collection-community-general-7.0.0-1.el8 (FEDORA-EPEL-2023-ca07fe358c)
Modules and plugins supported by Ansible community
--------------------------------------------------------------------------------
Update Information:
Update to ansible 7.2.0 in EPEL 8. We're updating community.general to the
latest version at the same as per <https://lists.fedoraproject.org/archives/sear
ch?q=A+coordinated+plan+for+ansible-
collection+updates+in+EPEL%3F&page=1&mlist=epel-
devel%40lists.fedoraproject.org&sort=date-asc>.
--------------------------------------------------------------------------------
ChangeLog:
--------------------------------------------------------------------------------
================================================================================
dropbear-2019.78-5.el8 (FEDORA-EPEL-2023-78e9d2e031)
Lightweight SSH server and client
--------------------------------------------------------------------------------
Update Information:
This update is a backport of the upstream fix for CVE-2021-36369.
--------------------------------------------------------------------------------
ChangeLog:
* Wed May 17 2023 Carl George <carl(a)george.computer> - 2019.78-5
- Backport fix for CVE-2021-36369, resolves rhbz#2135231
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #2135231 - CVE-2021-36369 dropbear: <net-misc/dropbear-2022.82: forwarded agent abuse [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2135231
--------------------------------------------------------------------------------
================================================================================
editorconfig-0.12.6-1.el8 (FEDORA-EPEL-2023-9f9a39afa5)
Parser for EditorConfig files written in C
--------------------------------------------------------------------------------
Update Information:
Security fix for CVE-2023-0341: update to 0.12.6 (close RHBZ#2162811)
--------------------------------------------------------------------------------
ChangeLog:
* Sun Jan 22 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> - 0.12.6-1
- Update to 0.12.6 (close RHBZ#2162811)
- Update License to SPDX
- Document and/or unbundle all bundled libraries
* Thu Jan 19 2023 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.12.5-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Thu Jul 21 2022 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.12.5-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Thu Jan 20 2022 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.12.5-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Wed Jul 21 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 0.12.5-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #2193152 - CVE-2023-0341 editorconfig-core-c:arbitrary stack write
https://bugzilla.redhat.com/show_bug.cgi?id=2193152
--------------------------------------------------------------------------------
================================================================================
fedora-license-data-1.21-1.el8 (FEDORA-EPEL-2023-717c0c9d8c)
Fedora Linux license data
--------------------------------------------------------------------------------
Update Information:
- Ensure all text files end with newlines - Add GPL-2.0-only WITH libpri-
OpenH323-exception as allowed - Consolidate text in public-domain-text.txt - Add
LicenseRef-LDP-1 as not-allowed
--------------------------------------------------------------------------------
ChangeLog:
* Wed May 17 2023 Miroslav Such�� <msuchy(a)redhat.com> 1.21-1
- Ensure all text files end with newlines
- Add GPL-2.0-only WITH libpri-OpenH323-exception as allowed
- Consolidate text in public-domain-text.txt
- Add LicenseRef-LDP-1 as not-allowed
--------------------------------------------------------------------------------
================================================================================
nickle-2.91-1.el8 (FEDORA-EPEL-2023-91f34e8867)
A programming language-based prototyping environment
--------------------------------------------------------------------------------
Update Information:
* Make randint produce evenly distributed values * Use asprintf in Command::edit
to avoid buffer overflow. Closes: #992413.
--------------------------------------------------------------------------------
ChangeLog:
* Wed May 17 2023 Michel Alexandre Salim <salimma(a)fedoraproject.org> - 2.91-1
- Update to 2.91
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #2187832 - nickle-2.91 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2187832
--------------------------------------------------------------------------------
================================================================================
python-pystemd-0.13.1-1.el8 (FEDORA-EPEL-2023-329e3e97bd)
A thin Cython-based wrapper on top of libsystemd
--------------------------------------------------------------------------------
Update Information:
Update to 0.13.1; Fixes: RHBZ#2207826
--------------------------------------------------------------------------------
ChangeLog:
* Wed May 17 2023 Davide Cavalca <dcavalca(a)fedoraproject.org> - 0.13.1-1
- Update to 0.13.1; Fixes: RHBZ#2207826
- Drop some unnecessary logic from the spec
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #2207826 - python-pystemd-0.13.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2207826
--------------------------------------------------------------------------------
================================================================================
xrdp-0.9.22-4.el8 (FEDORA-EPEL-2023-e2f52e4c98)
Open source remote desktop protocol (RDP) server
--------------------------------------------------------------------------------
Update Information:
Fix the breakage I caused with the latest update (i.e. -3 package), by
mistakenly omitting required .so files from %_libdir/xrdp directory.
Unfortunately, F36 has just gone EOL, so this will never be fixed there. Upgrade
to F37 or better, F38.
--------------------------------------------------------------------------------
ChangeLog:
* Wed May 17 2023 Bojan Smojver <bojan(a)rexursive.com> - 1:0.9.22-4
- Put back .so files into %libdir/xrdp directory
- Bug #2207733
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #2207733 - xrdp-0.9.22-3 is missing libxup.so and libvnc.so, breaking package
https://bugzilla.redhat.com/show_bug.cgi?id=2207733
[ 2 ] Bug #2207769 - xrdp xrdp-0.9.22-3 missing libvnc.so
https://bugzilla.redhat.com/show_bug.cgi?id=2207769
[ 3 ] Bug #2207839 - xrdp - shared lib /usr/lib64/xrdp/libvnc.so is missing
https://bugzilla.redhat.com/show_bug.cgi?id=2207839
--------------------------------------------------------------------------------
11 months, 3 weeks
Ansible in EPEL 8
by Maxwell G
Hello EPEL users and developers,
RHEL 8.8 was released yesterday,
so I have updated ansible in EPEL 8 from 6.3.0 to 7.2.0 to match RHEL
8.8's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible-core, and we keep them in sync.
Along with this change, RHEL 8.8 builds ansible-core for the python3.11
stack instead of the python39 stack that it was previously built for.
Therefore, ansible in EPEL 8 is now built for python3.11 as well.
I also updated ansible-collection-community-general to 7.0.0 as per the
discussions in [1].
Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ca07fe358c
Please help test and give karma.
Until this update is pushed to stable, you may receive an error like
this when running dnf upgrade
```
Error:
Problem: package ansible-6.3.0-2.el8.1.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed
- cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-2.el8_7.x86_64
- cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-1.el8.x86_64
- cannot install the best update candidate for package ansible-core-2.13.3-2.el8_7.x86_64
- cannot install the best update candidate for package ansible-6.3.0-2.el8.1.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
```
There are a couple potential solutions:
1. Run
$ dnf upgrade --exclude ansible-core
to skip ansible-core and upgrade everything else.
2. Later today or tomorrow, you'll be able to install
ansible 7.2.0 from testing with
$ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
and then run a plain `dnf upgrade` as usual.
Note that EPEL tracks RHEL and not rebuilds. Some rebuilds may lag
behind RHEL and not yet have 8.8 content. Our goal is to get packages
out as soon as possible so we don't break updates for RHEL users.
[1] https://lists.fedoraproject.org/archives/search?q=A+coordinated+plan+for+...
--
Happy automating,
Maxwell G (@gotmax23)
Pronouns: He/They
11 months, 3 weeks