[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing:
Age URL
4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6395a45cb3
perl-Image-ExifTool-12.38-1.el7
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4069001f10
miniupnpc-2.0-3.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
epel-rpm-macros-7-34
nodejs-16.13.2-5.el7
php-phpseclib-2.0.36-1.el7
tcpreplay-4.4.0-1.el7
Details about builds:
epel-rpm-macros-7-34 (FEDORA-EPEL-2022-66d92f182c)
Extra Packages for Enterprise Linux RPM macros
Update Information:
Drop the `%{nodejs_arches}` override. The RHEL 7 version has been fixed.
ChangeLog:
* Mon Jan 31 2022 Stephen Gallagher - 7-34
- Drop nodejs_arches override. RHEL now provides all of the arches.
nodejs-16.13.2-5.el7 (FEDORA-EPEL-2022-b07aca13c8)
JavaScript runtime
Update Information:
Lighten some dependencies to make it easier to minimize container footprint
ChangeLog:
* Mon Jan 31 2022 Stephen Gallagher - 1:16.13.2-3
- Tweak some dependencies on EPEL 7 (bz2048589)
- Add (Provides: bundled(zlib))
References:
[ 1 ] Bug #2048589 - Update version of nodejs requires -devel and -docs and
can't be removed without all of nodejs.
https://bugzilla.redhat.com/show_bug.cgi?id=2048589
php-phpseclib-2.0.36-1.el7 (FEDORA-EPEL-2022-f414e23b48)
PHP Secure Communications Library
Update Information:
**Version 2.0.36** - 2022-01-30 - SSH2: make login() return false if no valid
auth methods are found (#1744) - SFTP: fix chgrp() for version < 4 (#1730) -
Crypt/Base: add OFB8 as a new mode (phpseclib/mcrypt_compat#33) - RSA &
BigInteger: check phpinfo() available before using it (#1726)
ChangeLog:
* Mon Jan 31 2022 Remi Collet - 2.0.36-1
- update to 2.0.36
tcpreplay-4.4.0-1.el7 (FEDORA-EPEL-2022-d421b6dfec)
Replay captured network traffic
Update Information:
Tcpreplay suite 4.4.0 changes: - Update strlcpy.c and strlcat.c by @guijan in
#656 - 4.3.4 by @fklassen in #636 - Apply #616 fix to flows.c, fix #665 by
@dumprop in #666 - Bug #670: update Travis CI to focal by @fklassen in #672 -
Bug #669: LINUX installed netmap auto detection by @fklassen in #673 - Feature
#626 - Support for Q-in-Q VLAN tags by @fklassen in #675 - Bug #677
skipbroadcast by @fklassen in #678 - Bug #689: add security policy document by
@fklassen in #691 - Directories of pcaps as arguments by @halver94 in #682 -
PR #682 stage PR from @halver94 by @fklassen in #692 - Bug #679 fix PPS calc
for long-running sessions by @fklassen in #693 - Bug #668 Improve SDK selection
by @fklassen in #694 - Bug #696 fix directory include feature by @fklassen in
#697 - Bug #695 mac os tests fail by @fklassen in #698 - Bug #674 - Revert
"send_packet: Avoid clock drift by using time since first packet" by @fklassen
in #699 - Feature #563 mac update on multicast by @fklassen in #700
ChangeLog:
* Mon Jan 31 2022 Bojan Smojver - 4.4.0-1
- bump up to 4.4.0
* Sat Jan 22 2022 Fedora Release Engineering -
4.3.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering -
4.3.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
___
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/archiv
[EPEL-devel] Re: Revisiting policy for limited arch packages?
On Mon, Jan 31, 2022 at 06:48:21PM +, Gary Buhrmaster wrote: > On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi wrote: > > > The limited arch policy we had for epel7 had a number of problems. > > At first we just said 'rebuild the exact rhel version' and then we > > switched to 'add a 0 to release so the rhel package always gets > > installed in favor of it'. > > It (probably?) would not hurt to have the epel > repos have a higher cost in the repo config > to discourage choosing the epel package over > the rhel package (if all things are equal, but > of course, they are not always equal). > > For some specific cases where I needed to > build the -devel package in a copr (until or > unless I can get the -devel packages shipped > in CRB (or equivalent)) I have manually set > the cost for the copr repos to be high so that > for a non -devel install I got the rhel versions. > I would love to know if there is a better way. > It all just seems so non-optimal. Sure, we could do that, but it's far from foolproof. Many people make their own repo files, or they might have their own weight schemes. It also doesn't help any building against things in koji. kevin signature.asc Description: PGP signature ___ 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] epel8-playground branch retires - happening now
Hello, I am currently in the middle of retiring all of the epel8-playground branches. I apologize for not sending an email ahead of time. For informations sake, I am retiring them with fedpkg retire "epel8-playground decommissioned : https://pagure.io/epel/issue/ 136" Just so people know where we are in the epel8-playground decommission steps. * block targets in koji - DONE * Update Documentation - DONE * Remove or fix package.cfg - DONE * Remove configs from epel-release -- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-bc95045a9e * Retire all epel8-playground branches -- Happening right now https://pagure.io/epel/issue/136#comment-774581 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
[EPEL-devel] Re: Revisiting policy for limited arch packages?
On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi wrote: > The limited arch policy we had for epel7 had a number of problems. > At first we just said 'rebuild the exact rhel version' and then we > switched to 'add a 0 to release so the rhel package always gets > installed in favor of it'. It (probably?) would not hurt to have the epel repos have a higher cost in the repo config to discourage choosing the epel package over the rhel package (if all things are equal, but of course, they are not always equal). For some specific cases where I needed to build the -devel package in a copr (until or unless I can get the -devel packages shipped in CRB (or equivalent)) I have manually set the cost for the copr repos to be high so that for a non -devel install I got the rhel versions. I would love to know if there is a better way. It all just seems so non-optimal. ___ 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: Revisiting policy for limited arch packages?
On Thu, Jan 27, 2022 at 09:35:27PM -0800, Michel Alexandre Salim wrote: > Hi all, > > I just filed https://pagure.io/epel/issue/152 to ask if we should > revisit the policy for > https://docs.fedoraproject.org/en-US/epel/epel-packaging/#limited_arch_packages > > This policy seems very similar to the policy we agreed on in > https://pagure.io/epel/issue/134 (but haven't documented yet) which > deals with missing subpackages of two kinds: > - built but not shipped > - disabled from building > > except this time it's architectures that are either excluded from build, > or excluded from being shipped. > > Neal is trying to package LibRaw, which is built on all arches but has > been shipped only for x86_64: > > review request: https://bugzilla.redhat.com/show_bug.cgi?id=2047560 > rejected RHEL 8 request to ship LibRaw: > https://bugzilla.redhat.com/show_bug.cgi?id=1956029 > rejected RHEL 9 request: https://bugzilla.redhat.com/show_bug.cgi?id=2012272 The limited arch policy we had for epel7 had a number of problems. At first we just said 'rebuild the exact rhel version' and then we switched to 'add a 0 to release so the rhel package always gets installed in favor of it'. We also didn't have any kind of record keeping or process, so we have no idea how many of these there were, and they continued to just surprise people over and over again. ;( > Details in the ticket, but TL;DR > - why is EPEL 8 excluded from the limited arch policy, and would the > recommendation in issue 134 to use a different srpm name resolve the > issues there? I think we didn't allow it for epel8 for the above reasons. A different name might make it easier for the packager, but not for tracking or visibility. > - assuming we still disallow EPEL 8, is EPEL 9 fine? I'd say no, until we approve a new policy. > - can we merge that policy with the policy we have to write for issue > 134 anyway? Perhaps. The difference here is that people will see a epel package 'newer' than the rhel one and get it installed (in cases where rhel does ship it). Thats what the 0 leading release was supposed to help with, but it adds a bunch of complexity. > - in case of limited arch packages, should the new srpm be `-epel` or > `-extras`? It's very lightly edited from the original (see Neal's > review request) as we don't even have to disable certain subpackages: > - rename %name > - rename back all the generated packages > - add changelog > but on the other hand, in this case it's very long lived as it's not > just a matter of "we can persuade RH to ship it in CRB, it's not > supported anyway" I personally don't much care, but we should pick one. ;) > - should we come up with review guidelines for this? fedora-review seems > overkill as in most cases we don't want to diverge from the CentOS > Stream upstream anyway. At the very least we should make a requirement to add a provides or something so we can find these and see them. kevin signature.asc Description: PGP signature ___ 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
