[EPEL-devel] Fedora EPEL 8 updates-testing report
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 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 ___ 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] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 29 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-9eaea6f65c audacious-plugins-4.0.5-4.el7 fluidsynth-2.1.8-4.el7 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-c4678a5e4b radare2-5.3.1-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-49226a1ff0 aom-3.1.1-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-92a8baa028 tor-0.3.5.15-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4d814b358 quassel-0.12.5-2.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1ad14f84b0 ansible-2.9.23-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing openbgpd-7.1-1.el7 Details about builds: openbgpd-7.1-1.el7 (FEDORA-EPEL-2021-f2f7cc64c9) 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 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 ___ 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: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
On Fri, Jun 25, 2021 at 2:02 PM Josh Boyer wrote: > On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson 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_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.
[EPEL-devel] Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson 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 > > Thanks > Troy Dawson > > [1] - > https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F > [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. ___ epel-devel mailing list -- epel-devel@li
[EPEL-devel] Re: help request: libksysguard build failure on Stream 8
On Thu, Jun 24, 2021 at 8:31 PM Yaakov Selkowitz wrote: > On Thu, 2021-06-24 at 15:40 -0700, Troy Dawson wrote: > > On Wed, Jun 23, 2021 at 9:25 AM Yaakov Selkowitz > > wrote: > > > > > On Wed, 2021-06-23 at 08:56 -0700, Troy Dawson wrote: > > > > 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::files > > > ys > > > > tem::__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 > > > > > > std::filesystem was originally added as an experimental extension to > C++, > > > and > > > at first required explicitly linking with -lstdc++fs. GCC 9 removed > the > > > requirement for the additional link library [1], but RHEL 8's default > > > compiler > > > is GCC 8. Therefore, for EPEL 8, you would have to create a patch > which > > > adds > > > stdc++fs to the target_link_libraries of the processcore target. > > > > > > [1] https://gcc.gnu.org/gcc-9/changes.html > > > > > > HTH, > > > > > > > My cmake skills are not up to snuff. A little more help is needed. > > I seems -lstdc++fs needs to be added at the end of the compile command > > /usr/bin/c++ -lstdc++fs > > instead of at the beginning or middle of the options > > /usr/bin/c++ -lstdc++fs > > > > I can do that manually, and it compiles correctly. > > > > But getting cmake to do it, I'm clearly missing something. > > Is there a cmake command line option to put -lstdc++fs at the end? > > There are several cmake and cmake.in files. Would I put it in one, and > if > > so, what is the syntax? > > Add stdc++fs to the end of this list: > > > https://github.com/KDE/libksysguard/blob/master/processcore/CMakeLists.txt#L29-L39 > That did it. Thank you very much. Not only am I unblocked, but my cmake skills are a little bit better. Troy ___ 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
