[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ea01d505c9 pdns-4.1.14-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a37e7c643e xawtv-3.107-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-98b234afda libuv-1.40.0-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bd6a96cd24 python34-3.4.10-7.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9eaf8d2e11 prosody-0.11.7-1.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-50425dd33f rubygem-kramdown-1.9.0-2.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1eeb530261 python3-urllib3-1.25.6-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nordugrid-arc-5.4.4-4.el7 nordugrid-arc6-6.7.0-2.el7 root-6.22.02-3.el7 xrdcl-http-5.0.2-1.el7 xrootd-5.0.2-1.el7 xrootd-compat-4.12.4-1.el7 Details about builds: nordugrid-arc-5.4.4-4.el7 (FEDORA-EPEL-2020-44ad46e846) Advanced Resource Connector Grid Middleware Update Information: xrootd 5 ChangeLog: * Fri Aug 28 2020 Mattias Ellert - 5.4.4-4 - xrootd 5 compatibility nordugrid-arc6-6.7.0-2.el7 (FEDORA-EPEL-2020-44ad46e846) Advanced Resource Connector Middleware Update Information: xrootd 5 ChangeLog: * Fri Aug 28 2020 Mattias Ellert - 6.7.0-2 - xrootd 5 compatibility root-6.22.02-3.el7 (FEDORA-EPEL-2020-44ad46e846) Numerical data analysis framework Update Information: xrootd 5 ChangeLog: * Fri Oct 2 2020 Mattias Ellert - 6.22.02-3 - Drop obsolete patch root-add-flexiblas-detection.patch (cmake's FindBLAS.cmake supports flexiblas now) - Drop the workaround for the bug in doxygen causing different results on 32 and 64 bit architectures (use doxygen < 1.8.17 or >= 1.8.20-3) - Build require xrootd 5 (Fedora 33+, EPEL 7+) * Sun Aug 30 2020 Mattias Ellert - 6.22.02-2 - Adapt to xrootd 5 (Fedora 33+, EPEL 7+) - Don't build the old proof client (xproofd) - Don't build the old NetX module xrdcl-http-5.0.2-1.el7 (FEDORA-EPEL-2020-44ad46e846) HTTP client plug-in for XRootD Update Information: xrootd 5 ChangeLog: * Fri Sep 18 2020 Mattias Ellert - 5.0.2-1 - Update to version 5.0.2 - Drop patches (accepted upstream or previously backported) * Thu Aug 27 2020 Mattias Ellert - 5.0.1-1 - Update to version 5.0.1 - Don't use versioned plugin names in configuration - Backport plugin version change from git master * Sat Aug 1 2020 Fedora Release Engineering - 4.12.2-3 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Jul 29 2020 Fedora Release Engineering - 4.12.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild xrootd-5.0.2-1.el7 (FEDORA-EPEL-2020-44ad46e846) Extended ROOT file server Update Information: xrootd 5 ChangeLog: * Fri Sep 18 2020 Mattias Ellert - 1:5.0.2-1 - Update to version 5.0.2 - Drop patches (accepted upstream or previously backported) - Obsolete xrdhttpvoms in xrootd-voms package * Thu Aug 27 2020 Mattias Ellert - 1:5.0.1-1 - Update to version 5.0.1 - Remove conditionals for building on EPEL 6 - Drop patches (accepted upstream or previously backported) - Fix 32 bit compilation (format error) - Fix compilation on ARM, PPC and S390X (char is unsigned) ==
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing:
Age URL
8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1790461e43
chromium-85.0.4183.121-1.el8
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f2bfced63
prosody-0.11.7-1.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
darktable-3.2.1-7.el8
nordugrid-arc-6.7.0-4.el8
root-6.22.02-3.el8
xrdcl-http-5.0.2-1.el8
xrootd-5.0.2-1.el8
Details about builds:
darktable-3.2.1-7.el8 (FEDORA-EPEL-2020-9b6ed35a25)
Utility to organize and develop raw images
Update Information:
Enabled bundled Lua. 3.2.1 release resumed OpenMP on ppc64le aarch64
resumed OpenCL on ppc64le 3.2.1 release Feedback concerning following
ticket would be appreciated https://github.com/darktable-
org/darktable/issues/5916
ChangeLog:
* Sat Oct 3 2020 Germano Massullo - 3.2.1-7
- enabled bundled Lua, because darktable does not support Lua 5.4 that is
shipped in Fedora and EPEL 8
* Sat Oct 3 2020 Germano Massullo - 3.2.1-6
- Added BuildRequires: perl-lib for Fedora > 32 and EL > 8
* Fri Oct 2 2020 Germano Massullo - 3.2.1-5
- Fixed Lua macros
- Fixed errors of new cmake macros
* Sat Sep 26 2020 Andreas Schneider - 3.2.1-4
- Fix build with new cmake macros
* Fri Sep 25 2020 Germano Massullo - 3.2.1-3
- resumed OpenMP on ppc64le aarch64
- resumed OpenCL on ppc64le
- added 0001.patch
- removed %ifnarch ppc64le %{_bindir}/darktable-cltest
* Fri Sep 25 2020 Germano Massullo - 3.2.1-2
- Introduced new cmake macros for Fedora >= 33 and EL >= 9
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
- Added BuildRequires: perl(FindBin)
- Added BuildRequires: cmake(libavif) for Fedora >= 33 and EL >= 9
* Mon Aug 10 2020 Germano Massullo - 3.2.1-1
- 3.2.1 release
* Sat Aug 1 2020 Fedora Release Engineering -
3.0.2-3
- Second attempt - Rebuilt for
https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jul 27 2020 Fedora Release Engineering -
3.0.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
References:
[ 1 ] Bug #1884581 - darktable lacks lua support (therefore: no extensions
work)
https://bugzilla.redhat.com/show_bug.cgi?id=1884581
nordugrid-arc-6.7.0-4.el8 (FEDORA-EPEL-2020-296f3d7907)
Advanced Resource Connector Middleware
Update Information:
xrootd 5
ChangeLog:
* Fri Aug 28 2020 Mattias Ellert - 6.7.0-4
- xrootd 5 compatibility
* Tue Jul 28 2020 Fedora Release Engineering -
6.7.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jul 27 2020 Jeff Law - 6.7.0-2
- Always specify C++11 or C++14 rather than using the default
(which will be C++17 in the near future and this code is not C++17
ready).
root-6.22.02-3.el8 (FEDORA-EPEL-2020-296f3d7907)
Numerical data analysis framework
Update Information:
xrootd 5
ChangeLog:
* Fri Oct 2 2020 Mattias Ellert - 6.22.02-3
- Drop obsolete patch root-add-flexiblas-detection.patch (cmake's
FindBLAS.cmake supports flexiblas now)
- Drop the workaround for the bug in doxygen causing different results
on 32 and 64 bit architectures (use doxygen < 1.8.17 or >= 1.8.20-3)
- Build require xrootd 5 (Fedora 33+, EPEL 7+)
* Sun Aug 30 2020 Mattias Ellert - 6.22.02-2
- Adapt to xrootd 5 (Fedora 33+, EPEL 7+)
- Don't build the old proof client (xproofd)
- Don't build the old NetX module
xrdcl-http-5.0.2-1.el8 (FEDORA-EPEL-2020-296f3d7907)
HTTP client plug-in for XRootD
Update Information:
xrootd 5
ChangeLog:
* Fri Sep 18 2020 Mattias Ellert - 5.0.2-1
- Update to version 5.0.2
- Drop patches (accepted upstream or previously backported)
* Thu Aug 27 2020 Mattias E
[EPEL-devel] Re: proposal: EPEL 8 Next
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote: > Here is my rough outline of the steps required to implement this proposal. > I imagine things would happen roughly in this order, but some things could > probably take place in parallel. > > 1. EPEL Steering Committee approves the proposal > 2. koji changes: > - create CentOS Stream 8 external repo > - create epel8-next build target (inheriting from epel8) > - dist macro override for that target > 3. create PDC entries > 4. update fedscm-admin with branch SLAs > 5. configure dist-git to allow branch name > 6. update pungi config > 7. add epel-next-repo subpackage to epel-release > 8. add epel8-next release in bodhi > 9. document in the wiki > 10. announcement email > > Please let me know if I'm missing anything. Looks pretty good to me, but two things: 1. I assume (but good to ask) that we are not going to change anything in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there? 2. We are heading into final freeze for Fedora 33 next tuesday, so not sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over? Thanks much for putting this together! kevin -- > > On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > > > I agree, using .el8.next for the dist macro makes the most sense. This will > > enable maintainers to use a similar workflow to Fedora branches, where older > > branches can be fast forwarded, and the same commit can be built for > > different targets but still have different NVRs in Koji. Here is an example > > workflow for a fictional foo package that already exists in Fedora. > > > > - request epel8 branch > > - merge master branch to epel8 branch > > - build epel8 branch, resulting in foo-1-1.el8 > > - realize it won't install on CentOS Stream due to a library difference > > - request epel8-next branch > > - merge epel8 branch to epel8-next branch > > - build epel8-next branch, resulting in foo-1-1.el8.next > > > > After the next RHEL 8 minor release (when that library difference affects > > everyone), the maintainer can increment the release on the epel8 branch and > > proceed as usual. > > > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > > At the EPEL Steering Committee last week, we had an extensive > > > > discussion of > > > > this proposal, specifically focused on how to handle the dist macro. I > > > > believe these are the possible choices. > > > > > > > > * keep dist the same as epel8 (.el8) > > > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using > > > > .el8 for > > > > dist. It would make sense to continue using the same dist for EPEL > > > > Next. > > > > However, this would put a little more work on packagers. They would > > > > not be > > > > able to build the same commit for both EPEL and EPEL Next because the > > > > NVR > > > > will conflict in Koji. In simple rebuild situations, this is not a > > > > problem > > > > because at a minimum the release will be higher. But if a packager > > > > wanted > > > > to update the package in both EPEL and EPEL Next, they will need to > > > > first > > > > update and build it in EPEL, then bump the release and build it in EPEL > > > > Next. This isn't ideal, but isn't terrible either, and can be partially > > > > mitigated by good documentation around EPEL Next workflows. > > > > > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > > > > > In EPEL Next we could define dist to a string that RPM evaluates higher > > > > than > > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches > > > > to be > > > > in sync and the same commit could be built for both targets. The higher > > > > dist would ensure the upgrade path works. > > > > > > I think this makes the most sense and will help packages workflows the > > > best. > > > > > > kevin > > > ___ > > > 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 > > > > > > > > -- > > Carl George > > > > -- > Carl George > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send
