Short answer: Yes
Longer Answer:
epel9 currently has what is going to be in RHEL 9.0.
CentOS Stream 9 (what you get with local mock) has several updated packages that will be in RHEL 9.1
If you find that your packages will only build on the current CentOS STream 9, then you should build them in epel9-next.
epel9-next builds off the current CentOS Stream 9.
Troy
On Fri, Apr 22, 2022 at 11:22 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
Hello,
I've been trying to debug a segfault during %check that only occurs in epel9
Koji, but not in mock.
At the end, I compared the list of packages with:
$ koji list-buildroot 34845388 | sort > koji
$ mock -r centos-stream+epel-9-x86_64 shell -- rpm -qa | sort > mock
$ diff -u koji mock | grep -v ' '
+acl-2.3.1-3.el9.x86_64
-audit-libs-3.0.7-101.el9.x86_64
+audit-libs-3.0.7-102.el9.x86_64
-binutils-gold-2.35.2-17.el9.x86_64
-binutils-2.35.2-17.el9.x86_64
+binutils-gold-2.35.2-19.el9.x86_64
+binutils-2.35.2-19.el9.x86_64
-centos-gpg-keys-9.0-9.el9.noarch
-centos-stream-release-9.0-9.el9.noarch
-centos-stream-repos-9.0-9.el9.noarch
+centos-gpg-keys-9.0-12.el9.noarch
+centos-stream-release-9.0-12.el9.noarch
+centos-stream-repos-9.0-12.el9.noarch
-crypto-policies-20220203-1.gitf03e75e.el9.noarch
+crypto-policies-20220404-1.git845c0c1.el9.noarch
+cryptsetup-libs-2.4.3-4.el9.x86_64
-cyrus-sasl-lib-2.1.27-19.el9.x86_64
+cyrus-sasl-lib-2.1.27-20.el9.x86_64
+dbus-broker-28-5.el9.x86_64
+dbus-common-1.12.20-5.el9.noarch
+dbus-1.12.20-5.el9.x86_64
+device-mapper-libs-1.02.183-4.el9.x86_64
+device-mapper-1.02.183-4.el9.x86_64
-elfutils-debuginfod-client-0.186-1.el9.x86_64
-elfutils-default-yama-scope-0.186-1.el9.noarch
-elfutils-libelf-0.186-1.el9.x86_64
-elfutils-libs-0.186-1.el9.x86_64
-elfutils-0.186-1.el9.x86_64
-epel-release-9-2.el9.noarch
+elfutils-debuginfod-client-0.186-3.el9.x86_64
+elfutils-default-yama-scope-0.186-3.el9.noarch
+elfutils-libelf-0.186-3.el9.x86_64
+elfutils-libs-0.186-3.el9.x86_64
+elfutils-0.186-3.el9.x86_64
-expat-2.2.10-9.el9.x86_64
-fedpkg-minimal-1.2.0-4.el9.noarch
+expat-2.2.10-10.el9.x86_64
-flexiblas-netlib-3.0.4-7.el9.x86_64
-flexiblas-openblas-openmp-3.0.4-7.el9.x86_64
-flexiblas-3.0.4-7.el9.x86_64
+flexiblas-netlib-3.0.4-8.el9.x86_64
+flexiblas-openblas-openmp-3.0.4-8.el9.x86_64
+flexiblas-3.0.4-8.el9.x86_64
-glibc-common-2.34-25.el9.x86_64
-glibc-gconv-extra-2.34-25.el9.x86_64
-glibc-minimal-langpack-2.34-25.el9.x86_64
-glibc-2.34-25.el9.x86_64
+glibc-common-2.34-29.el9.x86_64
+glibc-gconv-extra-2.34-29.el9.x86_64
+glibc-minimal-langpack-2.34-29.el9.x86_64
+glibc-2.34-29.el9.x86_64
-gnutls-3.7.3-6.el9.x86_64
+gnutls-3.7.3-9.el9.x86_64
+gpg-pubkey-3228467c-613798eb
+gpg-pubkey-8483c65d-5ccc5b19
-krb5-libs-1.19.1-13.el9.x86_64
+kmod-libs-28-7.el9.x86_64
+krb5-libs-1.19.1-15.el9.x86_64
-libgcc-11.2.1-9.4.el9.x86_64
-libgcrypt-1.10.0-2.el9.x86_64
-libgfortran-11.2.1-9.4.el9.x86_64
-libgomp-11.2.1-9.4.el9.x86_64
+libgcc-11.2.1-10.el9.x86_64
+libgcrypt-1.10.0-3.el9.x86_64
+libgfortran-11.2.1-10.el9.x86_64
+libgomp-11.2.1-10.el9.x86_64
-libquadmath-11.2.1-9.4.el9.x86_64
+libquadmath-11.2.1-10.el9.x86_64
+libseccomp-2.5.2-2.el9.x86_64
-libstdc++-11.2.1-9.4.el9.x86_64
+libstdc++-11.2.1-10.el9.x86_64
-libxml2-2.9.12-4.el9.x86_64
+libxml2-2.9.13-1.el9.x86_64
-openblas-openmp-0.3.15-2.el9.x86_64
+openblas-openmp-0.3.15-3.el9.x86_64
-openblas-0.3.15-2.el9.x86_64
-openldap-2.4.59-3.el9.x86_64
-openssl-libs-3.0.1-12.el9.x86_64
-openssl-3.0.1-12.el9.x86_64
+openblas-0.3.15-3.el9.x86_64
+openldap-2.4.59-4.el9.x86_64
+openssl-libs-3.0.1-18.el9.x86_64
+openssl-3.0.1-18.el9.x86_64
-pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch
+pyproject-rpm-macros-1.0.1-1.el9.noarch
-systemd-libs-250-3.el9.x86_64
+systemd-libs-250-4.el9.x86_64
+systemd-pam-250-4.el9.x86_64
+systemd-rpm-macros-250-4.el9.noarch
+systemd-250-4.el9.x86_64
-tpm2-tss-3.0.3-7.el9.x86_64
-zlib-1.2.11-31.el9.x86_64
+zlib-1.2.11-32.el9.x86_64
This seems like my local mock has newer c9s packages than the Koji build repo.
Is that expected, or is pulling c9s packages into the build repo stuck on Koji
side?
Actually, I got an idea that EPEL 9 Koji might already be using (internal?)
RHEL 9.0, possibly I have missed this switch... However, the
centos-stream-release package contraditcs taht idea :/
I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g.
pyproject-rpm-macros-1.0.1-1.el9.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
