This also needs the following macros too:

%with_asahi 1
%_with_asahi 1

* Checking distribution el10s configuration...
 -> Checking hyperscale config...
Using default options for hyperscale/packages
Creating tag  : hyperscale10s-packages-asahi-candidate
Creating tag  : hyperscale10s-packages-asahi-testing
Creating tag  : hyperscale10s-packages-asahi-release
 -> creating hyperscale10s-packages-asahi-el10s
Added external repo centos10s-baseos to tag hyperscale10s-packages-asahi-el10s-build (priority 5)
Added external repo centos10s-appstream to tag hyperscale10s-packages-asahi-el10s-build (priority 10)
Added external repo centos10s-crb to tag hyperscale10s-packages-asahi-el10s-build (priority 15)
Added external repo epel10 to tag hyperscale10s-packages-asahi-el10s-build (priority 20)
Added external repo centos10s-buildroot to tag hyperscale10s-packages-asahi-el10s-build (priority 25)

Macros should also be set correctly :

cbs taginfo hyperscale10s-packages-asahi-el10s-build|grep rpm.macro
  rpm.macro._with_asahi : 1
  rpm.macro.centos_hs : 1
  rpm.macro.distprefix : '.hs+asahi'
  rpm.macro.vendor : 'CentOS Hyperscale SIG'
  rpm.macro.with_asahi : 1

Can you verify and then close if working for you ?

The builds work and we're unblocked in the immediate, leaving open as the builds are coming out with the wrong disttag: https://cbs.centos.org/koji/taskinfo?taskID=4915351 yields asahi-scripts-20250426.1-1.el10s while we want asahi-scripts-20250426.1-1.hs+asahi.el10. This likely means distprefix isn't processed correctly.

interesting as it's set : https://cbs.centos.org/koji/taginfo?tagID=3124
and I see that @ngompa submitted a kernel build and it seems to be processed for the new distprefix tag ?
https://cbs.centos.org/koji/taskinfo?taskID=4915391
Some difference in your .spec for distprefix ?

I guess I can close this one ?

interesting as it's set : https://cbs.centos.org/koji/taginfo?tagID=3124
and I see that @ngompa submitted a kernel build and it seems to be processed for the new distprefix tag ?
https://cbs.centos.org/koji/taskinfo?taskID=4915391

This one actually hardcoded it in its spec: https://gitlab.com/CentOS/Hyperscale/rpms/kernel/-/blob/c10s-hs+asahi/kernel.spec?ref_type=heads#L171

Some difference in your .spec for distprefix ?

https://gitlab.com/CentOS/Hyperscale/rpms/redhat-rpm-config-hyperscale/-/blob/main/redhat-rpm-config-hyperscale.spec?ref_type=heads is the spec, I don't think it's doing anything special with distprefix.

well, never heard myself about distprefix so don't know how that would be parsed and if centos stream 10 rpm supports it.
Do you have pointers to doc about it ?
@tkopecek : ideas about that specific request ?

/usr/lib/rpm/macros.d/macros.dist defines %dist %{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,9999 do print("%{?distprefix" .. i .."}") end}}%{distcore}%{?distsuffix}%{?with_bootstrap:~bootstrap} so it should definitely be supported, and it seems to work fine when I test it in mock.

Yeah afaict this should just work:

$ mock -r centos-stream-10-x86_64 -D '%distprefix .hs+asahi' --shell 'rpm -E %dist'
INFO: mock.py version 6.1 starting (python version = 3.13.3, NVR = mock-6.1-1.fc42), args: /usr/libexec/mock/mock -r centos-stream-10-x86_64 -D '%distprefix .hs+asahi' --shell 'rpm -E %dist'
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: Package manager dnf4 detected and used (fallback)
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled ccache
INFO: enabled HW Info plugin
INFO: Package manager dnf4 detected and used (direct choice)
Finish: chroot init
Start: shell
.hs+asahi.el10
Finish: shell
Finish: run
$

Ok I think we figured it out. This tag (like all other tags) inherits buildsys10s-release which includes buildsys-macros-el10s which installs /etc/rpm/macros.disttag with

%rhel 10
%centos 10
%dist .el10s
%el10 1

Because this is clobbering %dist, the %distprefix set here is never parsed correctly. @ngompa and I were discussing this yesterday and think it's something that dates back to the CentOS Linux 8 / CentOS Stream 8 split. I'm pretty sure we can just drop the %dist definition here, and should just use the default one instead.

Yeah, actually that entire file can be dropped because it's already in centos-stream-release with its macros.dist file.

I suspect the entire package can be dropped actually, this is the full spec from the src.rpm:

%global _el_version el10s

Name:       buildsys-macros-el10s
Summary:    Macros for the Buildsystem
Version:    1.0
Release:    2%{dist}
License:    GPL
Group:      Development/Buildsystem
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:  noarch

%description
This particular package contains the macros needed for the buildsys for CentOS el9s.

%prep

%build

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}/etc/rpm/
VERSION=%{version}
printf %s%b "%" "rhel 10\n" >> %{buildroot}/etc/rpm/macros.disttag
printf %s%b "%" "centos 10\n" >> %{buildroot}/etc/rpm/macros.disttag
printf %s%b "%" "dist .%{_el_version}\n" >> %{buildroot}/etc/rpm/macros.disttag
printf %s%b "%" "el10 1\n" >> %{buildroot}/etc/rpm/macros.disttag
printf %s%b "%" "__arch_install_post /usr/lib/rpm/check-buildroot\n" >> %{buildroot}/etc/rpm/macros.checkbuild

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root)
/etc/rpm/macros.disttag
/etc/rpm/macros.checkbuild

%changelog
* Wed May 15 2024 Fabian Arrotin <arrfab@centos.org> - 1.0-2
- Inital version for el10s, based on el9s version

Oh yeah, we probably can just drop it.

That said, when we get around to being able to do secure boot signing, this package will wind up being useful for storing global signing macros for this sort of thing.

As discussed on Matrix, I thought that it would be easy to just remove buildsys-macros-el10s pkg from both build and srpm-build groups , defined on build tag .. but I was wrong :/

It seems one can use add-group-pkg to modify a group (created with add-group first) but can't find any command to remove a pkg from such group (?)

I even tried something like :
- remove-group (for both)
- confirmed with list-groups that there were none on build tag
- tried to add back all (except that pkg) into newly created groups .. and just adding group (without defining pkgs list) seems to bring all back directly, so something still in DB but that's not clear.

Maybe we should report upstream issue for that ?
/cc: @tkopecek ^

wondering if that's due to inheritance, so just adding similar group , existing in inherited tag, would explain why just pkg list is defined, even if nothing entered ?

Filed https://pagure.io/koji/issue/4393 as this looks like a koji bug to me

Another option I suppose could be to build a newer version of this package that drops those macro files, and then tag it in.

Another option I suppose could be to build a newer version of this package that drops those macro files, and then tag it in.

Not needed - see solution at https://pagure.io/koji/issue/4393#comment-972733

@dcavalca : see report in other ticket but applied that undocumented "call groupPackageListRemove" so can you give it a try ?
Still wondering about if blocking the pkg is the best way to do it (but not documented it either)

Yes, it's working now, thanks! https://cbs.centos.org/koji/taskinfo?taskID=4961204 is a scratch build, I'll test a real one in a minute.

Yup I think we're good: https://cbs.centos.org/koji/buildinfo?buildID=60648
Thanks again!

@dcavalca : if stream 9 and 10 (and equivalent RHEL versions) have proper tags by default, eventually we'd just have to bump that pkg and unset all these macros .. so pkg can still be used for something else, inherited if needed but we just need to ensure that macros set by that pkg are present and working in distro itself (like rhel , centos , el10 etc)

Those macros should all be already set by the release package: https://gitlab.com/redhat/centos-stream/rpms/centos-stream-release/-/blob/c10s/centos-stream-release.spec?ref_type=heads#L166-183 (c10s), https://gitlab.com/redhat/centos-stream/rpms/centos-stream-release/-/blob/c9s/centos-stream-release.spec?ref_type=heads#L156-172 (c9s)

I can't check the RHEL one myself but I assume it's doing the same.

yeah, so should be all good ..
Proposal (but I'll discuss that on devel list for awareness) :

• put buildys-macros on gitlab.com/CentOS/infra/rpms (for visibility as it wasn't anywhere but built from src.rpm directly on cbs.centos.org)
• bump version to remove some duplicates macros
• test on cbs.stg.centos.org that it still works
• announce the plan on devel list to just announce that some macros will disappear from buildsys-macros pkg (inherited for all SIGs build tags) but that it shouldn't have any impact as we're just removing dups

Does that sound like a plan ?

Yep that all sounds good to me.

@dcavalca :
- imported and modified buildsys-macros-el10s (inherited) : https://gitlab.com/CentOS/infra/rpms/buildsys-macros/-/commit/4fa11efa3d555d8d5d23984b1d2a047ded00ebc9
- submitted some test builds on https://cbs.stg.centos.org to see

While it builds, we initially enforced dist .el10s and now it defaults (per https://gitlab.com/redhat/centos-stream/rpms/centos-stream-release/-/blob/c10s/centos-stream-release.spec?ref_type=heads#L176) to el10 instead.

I don't mind that at all and we can still override in koji build tag with dist .el10s
I'll just start a thread on devel list to see what's the best option for SIGs

Yeah from some discussions it sounds like the .elXsdates back to CentOS Stream 8, when we needed to clearly differentiate it from CentOS Linux 8. This is no longer a concern, so I think we should just default to .elX for SIGs too, it'll avoid confusion and make things more consistent with CentOS Stream itself and EPEL.

well, some SIGs are relying on that as they build in parallel for Stream and RHEL and so the diff for .el10s vs .el10 (or .el9s vs .el9) .. otherwise koji would refuse to have same NVR in parallel ...
Let me still try to summarize this on a thread on devel list

I think that this one can be now closed, as it was working when we removed buildsys-macros pkg from inherited tags for this one, but it's now solved for all inherited tags (per #1681 ) so closing.
Feel free to reopen if needed