[EPEL-devel] Re: Packages to be untagged from epel-next
On Sat, 18 Nov 2023 14:40:19 + Sérgio Basto wrote: > On Sat, 2023-11-18 at 09:35 +0200, Tuomo Soini wrote: > > On Fri, 17 Nov 2023 21:31:37 + > > Sérgio Basto wrote: > > > > > Hi, > > > Is not an negative feedback, is a side note but I realize some > > > time ago that version with next is bigger than version without > > > next [1] therefore we should find a way that the el8 version be > > > greater than the el8.next version. > > > > > > > > > [1] > > > > > > rpmdev-vercmp 1.el8.next 1.el8 > > > > > > 1.el8.next > 1.el8 > > > > > > > I already suggested adding requirement to do a release bump when > > building from epel-next to epel. > > > > https://pagure.io/epel/pull-request/259 > > > > I find it important that new, compatible with new rhel build has > > bigger > > version-release than epel-next build. > > > > I just tested > > rpmdev-vercmp 1.el8.next 1.el8 > 1.el8.next > 1.el8 > > rpmdev-vercmp 1.el8.next 1.el8.1 > 1.el8.next < 1.el8.1 > > > so rpmdev-bumpspec --rightmost is enough > Yes. If that would be required for epel-next build, building for epel later would automatically override .next release, even without any change to release. That is because: rpmdev-vercmp 1.el8.next.1 1.el8.1 1.el8.next.1 < 1.el8.1 -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Packages to be untagged from epel-next
On Fri, 17 Nov 2023 21:31:37 + Sérgio Basto wrote: > Hi, > Is not an negative feedback, is a side note but I realize some time > ago that version with next is bigger than version without next [1] > therefore we should find a way that the el8 version be greater than > the el8.next version. > > > [1] > > rpmdev-vercmp 1.el8.next 1.el8 > > 1.el8.next > 1.el8 > I already suggested adding requirement to do a release bump when building from epel-next to epel. https://pagure.io/epel/pull-request/259 I find it important that new, compatible with new rhel build has bigger version-release than epel-next build. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Are there any plans to rebuild ClamAV in EPEL7 following CVE-2022-37434?
On Tue, 1 Nov 2022 10:50:02 + Nick Howitt via epel-devel wrote: > Yesterday, ClamAV announced CVE-2022-37434 as critical > (https://blog.clamav.net/2022/10/new-packages-for-clamav-01037-01044.html). > Redhat only seem to classify the issue as Moderate in EL7 - > https://access.redhat.com/security/cve/cve-2022-37434. It looks like > that, unless Redhat classify it as Critical, zlib and zlib-devel > won't get updated so ClamAV can't be rebuilt against the updated > zlib-devel. What is the EPEL take on the issue? Question was about update of bundled libraries which are not used by epel package. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: modular libnghttp2 replaces package from RHEL base
On Mon, 29 Jun 2020 17:32:58 +0200 Leon Fauster wrote: > > For those that have an automated update process in place. > What steps are needed to revert this mistake? "dnf distro-sync" after issue has been corrected. Issue has been fixed but not applied yet. It only gets fixed after next module compose. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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
[EPEL-devel] Re: Software Collection packages for EPEL
On Fri, 24 Jan 2020 21:10:48 +0300 Dmitry Butskoy wrote: > Well, now I see the initial behaviour: > > DEBUG util.py:598: Package coreutils-8.22-24.el7.x86_64 is already > > installed. DEBUG util.py:596: No matching package to install: > > 'rust-toolset-1.35-rust' DEBUG util.py:596: No matching package to > > install: 'rust-toolset-1.35-cargo' DEBUG util.py:596: No matching > > package to install: 'llvm-toolset-7.0' DEBUG util.py:596: No > > matching package to install: 'llvm-toolset-7.0-llvm-devel' > ie. devtoolset-8 is present, others not. rust toolset is not needed. Rust is on epel7. And so is llvm7.0 so llvm-toolset is not needed. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Mon, 12 Aug 2019 10:52:34 +0200 Miro Hrončok wrote: > > python3_other is now defined to 3 in rhel7.7. > > By what? Do you mean python3_pkgversion? W can override that as well. Sorry. python3_pkgversion. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Sun, 11 Aug 2019 22:26:45 +0200
Miro Hrončok wrote:
> %python3_other_pkgversion 34
>
> I believe the easiest fix is to define that directly in
> epel-rpm-macros:
>
> https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5
Correct. That fixes this issue but not the huge issue we have now.
> Thanks for the report!
I agree. But we have much bigger problem with epel python naming.
python3_other is now defined to 3 in rhel7.7.
Because epel is supposed to add packages to rhel, we have now new
definition which is our master. That means with 7.7 system and mock,
there is no possibility to build python36 packages any more.
Because rhel selected python3 naming when inroduced python3 that gives
epel7 new baseline for naming standard for python3 packages which means
we should now follow that on epel7 post rhel7.7. Before python3 was
added to rhel we could play with python3x naming freely but not any
more.
We have two choises really, this suggestion of mine is based on the
expectation that rhel7 continues to have more python3 packages in
future with naming python3-.
Let's list some history, please notify if I forgot something important.
python3 packages were introduced to epel with python3x naming
originally, and unlike fedora naming, python3 was replaced on every
package with %python3_pkgversion and related macros. When python 3.6
was introduced to epel7 there was new macro %python3_other_pkgversion
and related to that macros added.
When python 3.4 got EOL, macros were switched and python36 naming was
set for %python3_pkgversion
rhel7.7 introduced python3 with fedora style python3 naming and
%python3_pkgversion set to 3.
Now systems using new python-rpm-macros from rhel7.7 can't any more
build any python3 package because all dependencies switch from
python36- to python3- so package builds will fail
inside mock. Because of koji still using old python*rpm-macros this is
not yet visible on fedora build system but I tested and verified this
with mock. Also these new macros cause all new python packages to be
named python3-.
There are two possibilities how to handle this:
Introduce conflicting %python3_pkgversion (and other related macros)
with 36 and 3.6 etc in them.
This would cause pain in every occasion when there is new python3
package added to rhel7 because rhel7 uses different naming. That
would mean we would need to manually patch dependencies on packages in
rhel7 because we don't have any guarantee that rhel packagers remember
epel when doing rhel packages. So we need to manually change
dependencies to rhel packages to be python3, not
python%{python3_pkgversion}.
My suggestion for this is to do big python3 rebuild again in epel7,
this time with python3_pkgversion from rhel7.7 and move clearly to
rhel7.7 python3 naming and obsolete pythn34 now, people have already
been notified that python34 is end of the life and not supported by
upstream.
Add epel specific python_provide macro which for python3-modname does:
normal provides as it did before.
Provides: python3- = %{version}-%{release}
Obsoletes: python36- < %{version}-%{release}
Obsoletes: python34- < %{version}-%{release}
Remove python3_other from epel7.
Only downside from this is that python3-modname source rpm naming won't
work any more because rpm doesn't allow python3-modname naming in
sub-package. My suggestion for that is to name these epel only
source packages with python3-epel-modname or python3-modname-epel
naming so that they can generate python3-modname.
--
Tuomo Soini
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
___
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
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On Fri, 9 Aug 2019 17:39:45 +0200
Miro Hrončok wrote:
> On 09. 08. 19 17:38, Stephen John Smoogen wrote:
> >
> >
> > I tested all three and gave karma.
>
> Thanks. I'll wait for the push and retire the old packages.
>
> I hope everything will work as expected.
>
I noticed a issue, python-pip-epel can't be build on up to date 7.7
system because python3_other srpm related macros are not provided by
any package. I guess python-epel-rpm-macros package should provide
python3-other-srpm-macros for python34 related bits. And these two new
packages python3-other-srpm-macros and python3-other-rpm-macros should
be added as dependency to epel-rpm-macros.
Issue caused by missing packages is %python3_other_pkgversion is unset,
in mock log:
DEBUG util.py:587: Error: No Package found for
python%{python3_other_pkgversion}-devel
DEBUG util.py:587: Error: No
Package found for python%{python3_other_pkgversion}-setuptools
--
Tuomo Soini
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
___
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
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36
On Thu, 28 Mar 2019 13:22:26 +0100 Miro Hrončok wrote: > > A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27 > I'm still not sure about how it will behave. We should probably test > it. https://bugzilla.redhat.com/show_bug.cgi?id=1687196 Check my bug report first. You only need obsoletes in one place and there was my suggested patch which was not good enough for some, but it i a lot better than suggested change from Conflicts to Obsoletes all over. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Moving EPEL7 to python3.6
On Fri, 19 Oct 2018 15:22:01 -0400 Stephen John Smoogen wrote: > However, this was decided a while ago and it may not be the best > convention to use or one that the current python sig would like us to > use. I would like to get a naming convention cleared up and documented > so when we do a mass rebuild that the packages come out with either a > python3- or python36- I'd very much prefer python3- naming just because it would make python3 packaging much more consistent with fedora. But I'd want to point out that add problem to all packages currently named as python3- (packages where python2 counterpart is part of rhel). Because python3- can't have sub-package named python3-. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: libbibutils 6.6 update with soname bump in epel7
On Sat, 28 Jul 2018 12:29:56 +0900 Jens-Ulrik Petersen wrote: > Vasiliy, I have decoupled ghc-hs-bibutils from bibutils in epel7 now > too, so you shouldn't need to worry about it anymore. Please, add ghc-rpm-macros to update too. That's build dependency of ghc-hs-bibutils. And while package is now in koji it's not in any update bodhi knows about. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy <https://foobar.fi/> ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DGQXIYBY5EIR6EP7324M6ZBKJ3PY5P2U/
[EPEL-devel] Problem with vulkan on epel7
Vulkan was retired at https://pagure.io/releng/issue/6948 But rpm is still in repo. All other packages retired on same ticket are gone but that one is still there. What's the issue with this retirement? According git repo it was retired ok. -- Tuomo Soini <t...@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Wrong mpich dependencies?
On Mon, 21 Nov 2016 12:52:12 +0100 Antonio Trande <anto.tra...@gmail.com> wrote: > Hi all. > > 'petsc' build is failing on epel7 because missing 'mpich-devel'; > however, devel package looks provides as > 'mpich-3.0-devel-3.0.4-10.el7.x86_64'. > > https://kojipkgs.fedoraproject.org//work/tasks/2209/16552209/root.log > Yes. 'hypre' needs fixing. -- Tuomo Soini <t...@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: cmake issues with epel7 build
On Thu, 01 Sep 2016 09:38:08 -0400 jason taylor <jtfa...@gmail.com> wrote: > Working on getting a bro build for epel7 and I am running into what > appears to be a provides bug with cmake3. That's correct analysis yes, cmake3 provides cmake which it shouldn't really do. -- Tuomo Soini <t...@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-de...@lists.fedoraproject.org
[EPEL-devel] epel7 comps.xml lists wrong package for util-linux
I noticed a issue in epel7 comps. buildsys-build group includes util-linux-ng while on rhel7 package is util-linux and util-linux doesn't even provide util-linux-ng - that causes packages requiring software from util-linux to fail in mock build. Could somebody with access fix this issue asap? -- Tuomo Soini <t...@foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/> ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
