Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org
The following Fedora EPEL 8 Security updates need testing:
Age URL
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce aom-3.1.1-1.el8
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-698907eb45 quassel-0.13.1-8.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
appliance-tools-011.1-4.el8
livecd-tools-28.2-1.el8
Details about builds:
================================================================================
appliance-tools-011.1-4.el8 (FEDORA-EPEL-2021-28a6b0ea69)
Tools for building Appliances
--------------------------------------------------------------------------------
Update Information:
Various fixes to make generated images bootable in both UEFI and legacy BIOS
environments
--------------------------------------------------------------------------------
ChangeLog:
* Sat Jun 26 2021 Neal Gompa <ngompa13(a)gmail.com> - 011.1-4
- Backport fix to deal with grub-install errors for UEFI
* Fri Jun 4 2021 Python Maint <python-maint(a)redhat.com> - 011.1-3
- Rebuilt for Python 3.10
* Tue Jan 26 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 011.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1942038 - livecd-creator fails with multiple problems here listed
https://bugzilla.redhat.com/show_bug.cgi?id=1942038
[ 2 ] Bug #1969562 - The created iso is not bootable
https://bugzilla.redhat.com/show_bug.cgi?id=1969562
[ 3 ] Bug #1971631 - livecd-creator builds unbootable iso's
https://bugzilla.redhat.com/show_bug.cgi?id=1971631
--------------------------------------------------------------------------------
================================================================================
livecd-tools-28.2-1.el8 (FEDORA-EPEL-2021-28a6b0ea69)
Tools for building live CDs
--------------------------------------------------------------------------------
Update Information:
Various fixes to make generated images bootable in both UEFI and legacy BIOS
environments
--------------------------------------------------------------------------------
ChangeLog:
* Sat Jun 26 2021 Neal Gompa <ngompa13(a)gmail.com> - 1:28.2-1
- Release 28.2 (ngompa13)
- rearrange xorrisofs options to make image efi bootable (sobjerke)
- place efiboot.img and macboot.img in /isolinux (sobjerke)
- Remove duplicate sentence (35056002+BessieTheCookie)
* Fri Jun 4 2021 Python Maint <python-maint(a)redhat.com> - 1:28.1-2
- Rebuilt for Python 3.10
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1942038 - livecd-creator fails with multiple problems here listed
https://bugzilla.redhat.com/show_bug.cgi?id=1942038
[ 2 ] Bug #1969562 - The created iso is not bootable
https://bugzilla.redhat.com/show_bug.cgi?id=1969562
[ 3 ] Bug #1971631 - livecd-creator builds unbootable iso's
https://bugzilla.redhat.com/show_bug.cgi?id=1971631
--------------------------------------------------------------------------------
10 months, 4 weeks
Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org
The following Fedora EPEL 8 Security updates need testing:
Age URL
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a6e2c9bc8c radare2-5.3.1-1.el8
12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce aom-3.1.1-1.el8
4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-698907eb45 quassel-0.13.1-8.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
openbgpd-7.1-1.el8
Details about builds:
================================================================================
openbgpd-7.1-1.el8 (FEDORA-EPEL-2021-d70d94d1f8)
OpenBGPD Routing Daemon
--------------------------------------------------------------------------------
Update Information:
OpenBGPD 7.1 ============ This release includes the following changes to the
previous release: * OpenBSD 6.9 errata 009 During `bgpd(8)` config
reloads prefixes of the wrong address family could leak to peers resulting in
session resets. * Support for RFC 7313 - Enhanced Route Refresh Disabled
by default, to enable use `announce enhanced refresh yes`. * Improve output
of Adj-RIB-Out by updating nexthop and `ASPATH` before adding the prefix to the
RIB. This improves `bgpctl show rib out` output. * Add command line option to
show the version
--------------------------------------------------------------------------------
ChangeLog:
* Fri Jun 25 2021 Robert Scheck <robert(a)fedoraproject.org> 7.1-1
- Upgrade to 7.1 (#1976160)
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1976160 - openbgpd-7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1976160
--------------------------------------------------------------------------------
10 months, 4 weeks
Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
by Troy Dawson
On Fri, Jun 25, 2021 at 2:02 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
> On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson <tdawson(a)redhat.com> wrote:
> >
> > During our last round of proposals for solutions to missing devel
> packages, it was noted that EPEL and CentOS has very different
> documentation for requesting a package be put into RHEL 8.[1][2]
> >
> > I am betting that CentOS's documentation is correct. It was written
> after ours.
> >
> > When I was talking to the Red Hat people who know, it was noted that Red
> Hat has much better communication with the Fedora and CentOS communities
> than the EPEL community.[3] They wanted to start fixing that communication
> gap, and figured this would be a good way to start. So I'm asking Josh
> Boyer to answer this question on behalf of Red Hat.
>
> Thanks, Troy!
>
> > How would Red Hat like us, EPEL maintainers and developers, to request
> missing devel packages? (devel packages that are built at the same time as
> a released library in RHEL8, but not released in RHEL8. Such as lmdb-devel)
>
> The process as documented on the CentOS wiki page is the best route.
> Filing a bug against the package in the Red Hat Enterprise Linux
> product family with the CentOS Stream version set will ensure that
> both the team maintaining the package in RHEL and some from the CentOS
> Stream team are looped in. Getting the request in front of the owning
> RHEL team is key, as they will need to evaluate the request and
> consider the implications of providing the devel package.
>
> I would like to make sure and clarify that this is the best approach
> for devel packages from SRPMs that are already part of RHEL.
> Completely new package requests for things that are not in RHEL at all
> are RFEs that should likely come through a case filed in the Customer
> Portal for those that have a valid subscription.
>
> > If we follow Red Hat's procedure, what are the odds that the package
> will make it into RHEL 8 CRB?
>
> This one is harder to answer in a general sense. I don't want to be
> misleading, so I won't give odds because it will vary depending on the
> package. I'll certainly say the odds are better if the requests are
> made than if they aren't :) We have grown the CRB content set by over
> 100 packages since the initial RHEL 8.0 release, and continue to add
> packages even today. I'd like to also describe some of the
> considerations at play as we work on this.
>
> Essentially, the team that owns the package will evaluate the request
> to ensure it's consistent with the manner in which the package is
> intended to be used as part of RHEL. Often enabling other software to
> build against a RHEL package, particularly for things like EPEL
> enablement, is a perfectly valid use case. Once a valid use case has
> been established the team will ensure they can meet any obligations
> required by adding it as part of the RHEL product and sign off. After
> the team has agreed, the package will first appear in CentOS Stream
> PowerTools (or occasionally AppStream), and then in a future RHEL
> minor release.
>
> At times, we have included a library or package as an internal
> implementation detail and do not encourage wider use of that package
> for other software. This is a relatively rare case. I can only think
> of one stand-out package that comes to mind thus far. If it does
> happen the team may decide not to provide the devel package. Filing
> the request is often the best way to begin that dialog. This helps us
> understand how a package is being used and take that into
> consideration for future RHEL releases, and also allows discussion and
> suggestions for alternative packages that may be more suitable in the
> long term.
>
> I'm sure there are many that would simply like all subpackages of all
> SRPMs to be shipped, however that is not the approach RHEL is taking
> from a product perspective. Blanket requests for everything are not
> likely to go far. It's simply not actionable at the same level as
> targeted requests.
>
> As an aside, I am particularly encouraged to see EPEL-Next come to
> fruition and combined with CentOS Stream and the broader set of
> packages available in that project buildroot I think there is a lot of
> potential to grow the overall ecosystem. I believe EPEL has discussed
> this recently with some hesitation, but I would encourage you to
> consider if and how EPEL-Next and CentOS Stream might be leveraged to
> help EPEL proper as well. From what I've seen, this community is
> amazing and I think there are opportunities there.
>
> Thanks again Troy, for giving me the opportunity to interact with the
> EPEL community. This is quite overdue.
>
> josh
>
>
Thank you Josh for your reply. This will help us as we move forward.
We have updated out EPEL FAQ concerning this.
Troy
[1] -
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_rel...
10 months, 4 weeks
Requesting missing devel packages: How to request one be put in RHEL 8 CRB
by Troy Dawson
During our last round of proposals for solutions to missing devel packages,
it was noted that EPEL and CentOS has very different documentation for
requesting a package be put into RHEL 8.[1][2]
I am betting that CentOS's documentation is correct. It was written after
ours.
When I was talking to the Red Hat people who know, it was noted that Red
Hat has much better communication with the Fedora and CentOS communities
than the EPEL community.[3] They wanted to start fixing that communication
gap, and figured this would be a good way to start. So I'm asking Josh
Boyer to answer this question on behalf of Red Hat.
How would Red Hat like us, EPEL maintainers and developers, to request
missing devel packages? (devel packages that are built at the same time as
a released library in RHEL8, but not released in RHEL8. Such as lmdb-devel)
If we follow Red Hat's procedure, what are the odds that the package will
make it into RHEL 8 CRB?
Thanks
Troy Dawson
[1] -
https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_rel...
[2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages
[3] - Yes, I write my emails here from my redhat email address, but I do
not represent Red Hat in my EPEL capacities.
10 months, 4 weeks
help request: libksysguard build failure on Stream 8
by Troy Dawson
I'm updating/ rebuilding KDE Plasma Desktop on CentOS Stream 8, for the
updated qt5 that is there. I am using what is in F34 for the update.
I've got all the qt5 5.15.2 and kf5 5.83.0 packages built and in the
buildroot.
For libksysguard I believe I have all other dependencies built and in the
buildroot.
But it just keeps failing, despite everything I've tried.[1][2]
I get the same error on all arches. The same error on version 5.22.1,
5.22.2 and even 5.21.4.
I've tried passing build parameters that I thought went along with the
error, but nothing changed.
I think this is the critical error, but it's possible I'm wrong
CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
`KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
.localalias.209]':
/usr/include/c++/8/bits/fs_path.h:185: undefined reference to
`std::filesystem::__cxx11::path::_M_split_cmpts()'
CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
`KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
.localalias.209]':
/usr/include/c++/8/bits/fs_dir.h:371: undefined reference to
`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&, std::filesystem::directory_options, std::error_code*)'
CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
`KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*)':
/builddir/build/BUILD/libksysguard-5.22.2.1/processcore/cgroup_data_model.cpp:447:
undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator*() const'
/builddir/build/BUILD/libksysguard-5.22.2.1/processcore/cgroup_data_model.cpp:447:
undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator++()'
CMakeFiles/processcore.dir/cgroup_data_model.cpp.o: In function
`KSysGuard::CGroupDataModel::update(KSysGuard::CGroup*) [clone
.localalias.209]':
/usr/include/c++/8/bits/fs_dir.h:260: undefined reference to
`std::filesystem::status(std::filesystem::__cxx11::path const&)'
collect2: error: ld returned 1 exit status
Any help would be appreciated.
Troy
[1] - https://koji.fedoraproject.org/koji/taskinfo?taskID=70653878
[2] - https://kojipkgs.fedoraproject.org//work/tasks/3890/70653890/build.log
10 months, 4 weeks
EPEL 8 Next is now available
by Carl George
Howdy folks,
On behalf of the EPEL Steering Committee, I'm happy to announce the
availability of EPEL 8 Next. This is an additional repository that allows
package maintainers to build against CentOS Stream 8 instead of RHEL 8.
This is sometimes necessary when CentOS Stream contains an upcoming RHEL
library rebase, or if an EPEL package has a minimum version build
requirement that is already in CentOS Stream but not yet in RHEL. You can
read more about it in the wiki [0]. Special thanks goes out to the Fedora
Release Engineering team for their help implementing this.
[0] https://fedoraproject.org/wiki/EPEL_Next
--
Carl George
11 months
Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org
The following Fedora EPEL 8 Security updates need testing:
Age URL
12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a6e2c9bc8c radare2-5.3.1-1.el8
10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce aom-3.1.1-1.el8
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-698907eb45 quassel-0.13.1-8.el8
0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5cd3c9b775 ansible-2.9.23-1.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
jsonnet-0.17.0-1.el8
unrealircd-5.2.0.1-1.el8
Details about builds:
================================================================================
jsonnet-0.17.0-1.el8 (FEDORA-EPEL-2021-51a6f8e50d)
Diff JSON and JSON-like structures
--------------------------------------------------------------------------------
Update Information:
Initial build
--------------------------------------------------------------------------------
ChangeLog:
--------------------------------------------------------------------------------
================================================================================
unrealircd-5.2.0.1-1.el8 (FEDORA-EPEL-2021-a5237ecf48)
Open Source IRC server
--------------------------------------------------------------------------------
Update Information:
UnrealIRCd 5.2.0.1 ================== This is a small update for the 5.2.0
release. In channels, spamfilters of type `p` were run instead of type `c`.
Although this is not a major issue for many, as spamfilter are often placed on
both (`pc`), there is now this dot release to make sure new installs don't have
this bug.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jun 16 2021 Robert Scheck <robert(a)fedoraproject.org> 5.2.0.1-1
- Upgrade to 5.2.0.1 (#1972543)
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1972543 - unrealircd-5.2.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1972543
--------------------------------------------------------------------------------
11 months
