[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4add1d3059 needrestart-3.6-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d1317f7176 rubygem-git-1.3.0-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing rubygem-nokogiri-1.6.1-1.el7.2 Details about builds: rubygem-nokogiri-1.6.1-1.el7.2 (FEDORA-EPEL-2022-b3575fc91b) An HTML, XML, SAX, and Reader parser Update Information: Backport CVE-2022-24836 (#2074347), Backport CVE-2022-29181 (#2088685) ChangeLog: * Wed May 25 2022 Troy Dawson - 1.6.1-1.2 - Backport CVE-2022-24836 (#2074347) - Backport CVE-2022-29181 (#2088685) References: [ 1 ] Bug #2074347 - CVE-2022-24836 rubygem-nokogiri: nokogiri: ReDoS in HTML encoding detection [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2074347 [ 2 ] Bug #2088685 - CVE-2022-29181 rubygem-nokogiri: Improper Handling of Unexpected Data Type in Nokogiri [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2088685 ___ 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: python-passlib for python38 module
On Tuesday, May 24, 2022 12:53:36 PM CDT Maxwell G via epel-devel wrote:
> I think it's better to add `Requires:
> python%{python3_pkgversion}-rpm-macros`.
> To be fair, they both do effectively the same thing: set %__python3 to the
> correct value. In any case, I submitted
> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/44 so
> neither should be necessary.
* neither should be necessary once the PR is merged.
I should probably clarify, that PR hasn't been merged yet, so it's still
necessary to add `BuildRequires: python%{python3_pkgversion}-rpm-macros`.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
signature.asc
Description: This is a digitally signed message part.
___
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: python-passlib for python38 module
On 25. 05. 22 2:52, Maxwell G via epel-devel wrote:
On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote:
Sure, except I know nothing about how docs.fp.o works ;)
The source code for the EPEL docs page is here[1]. Honestly, I'm not super
familiar with it either :).
[1]: https://pagure.io/epel/tree/main
It looks like it's hard-coded to python3dist, so I think it has to
change to %{py38_dist}.
I looked at the macros file on Fedora and saw that it was dynamic, but I was
too lazy to look at an actual EL 8 system and notice it hadn't been backported
;(. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2090007. Let's see
what the RHEL Python maintainers have to say... As far as I know, `%
{py38_dist}` doesn't exist at all.
Just for the record. We can fix %{py3_dist} to include the 3.X part, but it
will only work when either %python3_pkgversion is redefined in the specfile or
python3X-rpm-macros are installed in the buildSRPM buildroot (and the latter is
not happening for Koji builds). I.e. doing just this:
BuildRequires: python38-rpm-macros
BuildRequires: %{py3_dist ...}
Will *not* work. That is a limitation we cannot workaround.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: SPDX identifiers in old branches?
Once upon a time, Gary Buhrmaster said: > The follow up suggested that the license > field be differently formatted. > > I disagree with such explanatory > prefixes, as it requires yet more apps > to parse/support various prefixes. No, my suggestion of using "License: SPDX:" would not require any additional changes. Anything that cares about the License field will already need changes to recongize the SPDX values; this would just remove any ambiguity. And as very little parses the License field, so there's not some big effort to update required in any case. I just made this suggestion as a way to avoid anything unclear in the License field, but it would also allow any future alternate license strings to be clearly used. -- Chris Adams ___ 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
