Hi,
Dusty created a ticket on infra tracker about empty s390x repo for extras-common : https://pagure.io/centos-infra/issue/1635
For visibility/awareness I'd like to discuss that here and then work on ticket eventually, as it would involve other SIGs.
For a long time, we had no s390x arch support in CBS but it was finally available end of 2024 (https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/YW24Y...)
So, now the interesting question : what to do about s390x ? It's easy to just add it to the extras-common build tag (https://cbs.centos.org/koji/taginfo?tagID=2914), and it would start pushing centos-release* noarch pkgs out , and so available for s390x users (are there a lot of these ? )
But while it would "solve" the issue mentioned by Dusty above, it would be giving impression that there are SIG content s(like ceph/gluster/else, so content built by SIGs) available for s390x, while only NFV/Infra (for our own needs)/OKD started to build for s390x.
As a reminder, that extras-common repository is only used for SIGs to distribute their -release packages (containing .repo files and gpg pub key) so that it can be directly installed from a centos stream release (that's the only repo that is available by default, coming from CBS - community and so outside of stream repositories like BaseOS/AppStream/CRB/etc)
I'd like to have your opinion/thoughs/feedback about this .
Hi,
Since s390x was only recently added and most SIGs don't support s390x, we need a way to allow these SIGs to configure their release packages to not be published for s390x. It would be even better if the SIGs could set their release packages to be published for s390x, i.e., opt-in instead of opt-out.
On 05/04/2025 15.16, Fabian Arrotin wrote:
Hi,
Dusty created a ticket on infra tracker about empty s390x repo for extras-common : https://pagure.io/centos-infra/issue/1635
For visibility/awareness I'd like to discuss that here and then work on ticket eventually, as it would involve other SIGs.
For a long time, we had no s390x arch support in CBS but it was finally available end of 2024 (https://lists.centos.org/hyperkitty/list/ devel@lists.centos.org/thread/YW24YOCOSVFMZ5FLB3CMX2UXSUOFTVDF/)
So, now the interesting question : what to do about s390x ? It's easy to just add it to the extras-common build tag (https:// cbs.centos.org/koji/taginfo?tagID=2914), and it would start pushing centos-release* noarch pkgs out , and so available for s390x users (are there a lot of these ? )
But while it would "solve" the issue mentioned by Dusty above, it would be giving impression that there are SIG content s(like ceph/gluster/ else, so content built by SIGs) available for s390x, while only NFV/ Infra (for our own needs)/OKD started to build for s390x.
As a reminder, that extras-common repository is only used for SIGs to distribute their -release packages (containing .repo files and gpg pub key) so that it can be directly installed from a centos stream release (that's the only repo that is available by default, coming from CBS - community and so outside of stream repositories like BaseOS/AppStream/ CRB/etc)
I'd like to have your opinion/thoughs/feedback about this .
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
On Mon, Apr 7, 2025 at 1:26 AM Peter Georg < peter.georg@physik.uni-regensburg.de> wrote:
Hi,
Since s390x was only recently added and most SIGs don't support s390x, we need a way to allow these SIGs to configure their release packages to not be published for s390x. It would be even better if the SIGs could set their release packages to be published for s390x, i.e., opt-in instead of opt-out.
On 05/04/2025 15.16, Fabian Arrotin wrote:
Hi,
Dusty created a ticket on infra tracker about empty s390x repo for extras-common : https://pagure.io/centos-infra/issue/1635
For visibility/awareness I'd like to discuss that here and then work on ticket eventually, as it would involve other SIGs.
For a long time, we had no s390x arch support in CBS but it was finally available end of 2024 (https://lists.centos.org/hyperkitty/list/ devel@lists.centos.org/thread/YW24YOCOSVFMZ5FLB3CMX2UXSUOFTVDF/)
So, now the interesting question : what to do about s390x ? It's easy to just add it to the extras-common build tag (https:// cbs.centos.org/koji/taginfo?tagID=2914), and it would start pushing centos-release* noarch pkgs out , and so available for s390x users (are there a lot of these ? )
But while it would "solve" the issue mentioned by Dusty above, it would be giving impression that there are SIG content s(like ceph/gluster/ else, so content built by SIGs) available for s390x, while only NFV/ Infra (for our own needs)/OKD started to build for s390x.
As a reminder, that extras-common repository is only used for SIGs to distribute their -release packages (containing .repo files and gpg pub key) so that it can be directly installed from a centos stream release (that's the only repo that is available by default, coming from CBS - community and so outside of stream repositories like BaseOS/AppStream/ CRB/etc)
I'd like to have your opinion/thoughs/feedback about this .
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
-- 真実はいつも一つ！/ Always, there's only one truth!
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/<stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo from each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release-<name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/koji/taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Il giorno mar 8 apr 2025 alle ore 14:17 Fabian Arrotin arrfab@centos.org ha scritto:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages
built, and I didn't even think about our -release file being in other arches.
Plus, we're thinking of having SysV (is that the extension?) and
wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch,
and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/<stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo from
each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release-<name> pkg that doesn't have pkgs / repository
What about creating the s390x repo always and leaving it empty if no package is built for that arch? And let ExcludeArch deal with building on it or not.
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/koji/taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On Tue, Apr 8, 2025 at 2:17 PM Fabian Arrotin arrfab@centos.org wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages
built, and I didn't even think about our -release file being in other arches.
Plus, we're thinking of having SysV (is that the extension?) and
wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch,
and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/<stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo from
each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release-<name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/koji/taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
I'd vote to keep centos-release-* noarch as it's basically files, and set "skip_if_unavailable=True" as Neal is proposing. But I'm also open to other approaches, I don't have strong opinions TBH. Once agreed I'm willing to implement the required changes for the Cloud and NFV SIGs.
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo from
each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release-<name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.
On 09/04/2025 20:52, Peter Georg wrote:
On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo
from each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https://cbs.centos.org/ koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release-<name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.
I'd like to answer ticket https://pagure.io/centos-infra/issue/1635 and with a solution but still have hard time understanding what's the consensus from SIGs themselves. If no other reaction I intend to implement the following thing :
- add s390x arch to c9s/c10s extras-common build tags - noarch pkgs will land in s390x too (like for other architectures) - SIGs can then opt-in to just make their centos-release-<name> pkg a arch dependent pkg (and they can untag-build previous noarch pkg to remove any confusion)
PS: the noarch situation is already an issue for some SIGs not building for all architectures : for example Hyperscale only builds for x86_64 and aarch64 but a ppc64le user (if any ? ) can already "dnf install centos-release-hyperscale" and then encounter issue as there is no content built for such arch
On 16/04/2025 07:15, Fabian Arrotin wrote:
On 09/04/2025 20:52, Peter Georg wrote:
On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/ SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo
from each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https:// cbs.centos.org/ koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release- <name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.
I'd like to answer ticket https://pagure.io/centos-infra/issue/1635 and with a solution but still have hard time understanding what's the consensus from SIGs themselves. If no other reaction I intend to implement the following thing :
- add s390x arch to c9s/c10s extras-common build tags
- noarch pkgs will land in s390x too (like for other architectures)
- SIGs can then opt-in to just make their centos-release-<name> pkg a
arch dependent pkg (and they can untag-build previous noarch pkg to remove any confusion)
PS: the noarch situation is already an issue for some SIGs not building for all architectures : for example Hyperscale only builds for x86_64 and aarch64 but a ppc64le user (if any ? ) can already "dnf install centos-release-hyperscale" and then encounter issue as there is no content built for such arch
Just to let all SIG know that I just implemented what was described above (as there was no reaction/discussion in the thread after)
Thanks Fabian! As always you rock!
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc https://www.redhat.com/
amy@redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
On Tue, May 13, 2025 at 3:45 AM Fabian Arrotin arrfab@centos.org wrote:
On 16/04/2025 07:15, Fabian Arrotin wrote:
On 09/04/2025 20:52, Peter Georg wrote:
On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/ SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo
from each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https:// cbs.centos.org/ koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release- <name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.
I'd like to answer ticket https://pagure.io/centos-infra/issue/1635 and with a solution but still have hard time understanding what's the consensus from SIGs themselves. If no other reaction I intend to implement the following thing :
- add s390x arch to c9s/c10s extras-common build tags
- noarch pkgs will land in s390x too (like for other architectures)
- SIGs can then opt-in to just make their centos-release-<name> pkg a
arch dependent pkg (and they can untag-build previous noarch pkg to remove any confusion)
PS: the noarch situation is already an issue for some SIGs not building for all architectures : for example Hyperscale only builds for x86_64 and aarch64 but a ppc64le user (if any ? ) can already "dnf install centos-release-hyperscale" and then encounter issue as there is no content built for such arch
Just to let all SIG know that I just implemented what was described above (as there was no reaction/discussion in the thread after)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Can you enable s390x target for Virt SIG?
Il giorno mar 13 mag 2025 alle ore 10:45 Fabian Arrotin arrfab@centos.org ha scritto:
On 16/04/2025 07:15, Fabian Arrotin wrote:
On 09/04/2025 20:52, Peter Georg wrote:
On 08/04/2025 14.17, Fabian Arrotin wrote:
On 07/04/2025 17:26, Neal Gompa wrote:
On Mon, Apr 7, 2025 at 11:24 AM Troy Dawson via devel devel@lists.centos.org wrote:
Looking beyond s390x, can we have them set by arch in some way.
I'm thinking of the ISA SIG, we currently only have x86_64 packages built, and I didn't even think about our -release file being in other arches. Plus, we're thinking of having SysV (is that the extension?) and wouldn't want others to think we're doing support for other arches.
I guess we (ISA) could have our centos-release-isa rpm NOT be noarch, and specifically set the arch.
Do you mean RISC-V? But also you can just allow the repository to fail if it doesn't exist. Set "skip_if_unavailable=True" in the repo configs. The repositories already are set up to fetch archfully through repo variables.
Just as a summary, it seems we'd have two proposed approaches :
- Troy suggested modifying .spec for centos-release-<name> from
BuildArch: noarch to a list of supported architectures, that would (or not) then be available under https://mirror.stream.centos.org/ SIGs/ <stream-release>/extras/<arch>
- Neal proposed instead that can we keep it "noarch" but then .repo
from each SIG centos-release-<name> would need to be modified to ensure that skip_if_unavailable=True would be added, otherwise it would still block users from unsupported architecture if they install a centos-release- <name> pkg that doesn't have pkgs / repository
In all the cases, that would need something to be done. For option 1 I can change the build tag to add 's390x' (actually it only covers x85_64, ppc64le and aarch64 - example for 9s : https:// cbs.centos.org/ koji/ taginfo?tagID=2556). But if I only do that, the next time a pkg would be tagged, it would then import *all* existing noarch in the s390x repository
What would be the best approach ? I'd like to hear from all SIGs as it's about their packages in their repositories :)
Speaking for the Kmods SIG I'd prefer keeping the centos-release- <name> packages "noarch". However, this means finding some other way to handle this situation. Neal's suggestion to add skip_if_unavailable=True isn't a real solution in my opinion: It would have to be set conditionally only for arches for which no packages are actually provided, which, to my knowledge, isn't possible. Otherwise, it would also suppress any other error about why a repository can't be synchronized. In my opinion, this is an undesirable side effect that should not be underestimated. Another approach would be to always create a repository for every arch even if the arch is not enabled for the particular build target. This approach leads to the creation of unnecessary repositories and could give users the impression that a SIG supports an architecture but the provision of packages is, for example, only delayed, even though this is not the case.
Since I don't know of any sensible approach to solve this problem under the condition of keeping the packages as "noarch", Troy's approach is the most sensible in my opinion. SIGs that support all architectures can of course keep their centos-release-<name> packages as noarch.
I'd like to answer ticket https://pagure.io/centos-infra/issue/1635 and with a solution but still have hard time understanding what's the consensus from SIGs themselves. If no other reaction I intend to implement the following thing :
- add s390x arch to c9s/c10s extras-common build tags
- noarch pkgs will land in s390x too (like for other architectures)
- SIGs can then opt-in to just make their centos-release-<name> pkg a
arch dependent pkg (and they can untag-build previous noarch pkg to remove any confusion)
PS: the noarch situation is already an issue for some SIGs not building for all architectures : for example Hyperscale only builds for x86_64 and aarch64 but a ppc64le user (if any ? ) can already "dnf install centos-release-hyperscale" and then encounter issue as there is no content built for such arch
Just to let all SIG know that I just implemented what was described above (as there was no reaction/discussion in the thread after)
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
On 13/05/2025 15:59, Sandro Bonazzola via devel wrote:
Can you enable s390x target for Virt SIG?
Hi Sandro,
If you mean adding s390x as valid architecture for Virt SIG builds, it can be done but that's not what this thread was all about.
Please read again https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/message/YW24... (for whole context on how to add s390x as arch for interested SIGs) and then create infra tickets with details about which projects/tags would need to add s390x support for.
Watch out about the pkgs with same NVR that *can't* be simply rebuild (--scratch procedure is explained in thread above)
-
Amy Marrich -
Fabian Arrotin -
Joel Capitao -
Neal Gompa -
Peter Georg -
Sandro Bonazzola -
Troy Dawson