Hi,
FPC approved new fonts packaging guidelines in https://pagure.io/packaging-committee/pull-request/934
Then it came into f32+ to implement. I see advantages of this policy rewrite, so I started font spec file conversion for my packages in Fedora. It worked fine. I got very good help from @nim for this conversion work. Some of my packages are already converted which are going to be soon FTBFS when F33 mass-rebuild will happen because of this packaging policy coding become incompatible with new rpm-4.15.90 version. On F32 system with rpm-4.15.1, new fonts packaging working fine.
I think this incompatibility has been discussed in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83 but could not be concluded to some working fix by either side of discussion.
I am approaching FPC to guide me further. I do not like font packages in F33+ to be like some converted to use FPC mandated new fonts packaging guidelines and some still using old packaging.
Do FPC have some policy on such issues? What to do if policy once approved is not getting implemented in Fedora or policy suddenly becomes not working and there is no fix available.
I request FPC members to share their view on this issue. If they think some packages using new guidelines and some old is fine then please say so here.
So strictly speaking, this is bug in fonts-rpm-macros since https://pagure.io/fonts-rpm-macros/c/3e10c3a946507dbff047b4806470fb06a09aa3dc?branch=master commit which uses something which is not defined anywhere and even pushing then this update to Fedora to intentionally break packages before redhat-rpm-config maintainers were able to provide feedback on the new approach being proposed (https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42674).
I guess the fix would be to revert fonts-rpm-macros to 2.x to restore previous behavior.
I'm really not happy how these things are going on, so at some point I might propose to revert packaging to the pre-F32 and just wait until @nim and RPM maintainers will come to common point. As a bonus point, make it go through Change Process.
That means reverting font packages to pre-2007 state and the Go packages to pre-2017 state.
That’s how long Fedora macros have been using the coding patterns rpm casually broke.
Not to mention, none of those would work with the current state of the distro (both as deps and provides).
And, frankly, there’s been zero constructive comment from you in all those exchanges, and proposing to wipe out years of other Fedora contributions so you don’t have to think about the whole thing and read the actual PR that was coded on rpm maintainer suggestions to adapt things to the new rpm world order is yet another provocation.
Hopefully this ticket gets discussed in upcoming meeting of FPC. If it fails I may need to move forward to FESCo. We can't use Fedora with broken packaging macros.
Can we please revert Rawhide to fonts-rpm-macros version 2?
@petersen Sure you can revert all the work that went into fixing the macros to adapt to the unannounced rpm 4.15 parser changes .
If you do that you get to maintain the result. I won’t invest more time in maintenance just so my work gets reverted because others do not want to do their part. Which is just deciding on a macro name and merging. How hard is that?
Of course if there are problems in the code proposed for merge in redhat-rpm-config, I will look at them, but none of the armchair mudsliders actually looked at the code seriously enough to point at those.
Practically, I’m completely fed up with the toxic attitude of people that:
I had to push things in devel just to force people to look at the problem. That worked briefly, now they want to revert to doing nothing before the fix resulting from the look up is merged and we can move to other things. How sick is that?
If FPC also wants to cover up things by pretending nothing happened and removing contributor work to make the situation go away I won’t be there to rebuild once again.
¹ I looked at enough redhat-rpm-config and rpm macro code to know my code level is as good as the average “official” macro, a lot better than a lot of them, and miles ahead on the documentation front. Documentation that was not merged because the naysayers did not know what to do with documentation once it was provided on a platter, so used they were to their own undocumented tinkering.
Metadata Update from @ignatenkobrain: - Issue tagged with: meeting
As two members here suggested to use 2.x.x version, I picked the last build from this version 2 series -> https://koji.fedoraproject.org/koji/buildinfo?buildID=1488859
2.x.x
I added Epoch:1 and built new package https://copr.fedorainfracloud.org/coprs/pnemade/fontstest/build/1390978/
Epoch:1
Initially I built few packages easily because I had srpms available on my system but then I tried to build srpm on my system for already converted fonts packages in rawhide against fonts-rpm-macros-2.0.5-2 copr build. For that I first installed this new package's all binary rpms on the system. Then I tried to generate srpm and submit to copr repo but local srpm build failed.
rpm is giving me Unknown tag: %fontmeta on some packages where spec have %fontmeta macro used and not generating srpm thus no submission to copr build.
Unknown tag: %fontmeta
%fontmeta
if anyone want to try this failure then install fonts-rpm-macros-2.0.5-2 copr build and take dejavu-fonts to rebuild locally on your system. You will get Unknown tag: %fontmeta.
dejavu-fonts
So, maybe this helps:
%patch0 -p1
Patch0: %{name}-urn-dtd.patch
Name
dejavu-fonts built fine, even with a patch, until fonts-rpm-macros was was updated to 3.0.3 (which, as I understand, should address the Patch problem, but which was never a problem in the first place here?)
We talked about this ticket at today's meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-05-21/fpc.2020-05-21-16.00.txt):
Thank you very much FPC people who participated in yesterday's meeting and Nicolas also.
Let's hope to get some fix soon in Fedora for this issue.
Fonts (for ~ 13 years) and Go (for ~ 4 years) use automated package header generation.
That means they generate complete HEADER blocks in the preamble, that use indifferently Name: or %package
Name:
%package
Name: or %package -n Summary: … %description -n
There is no special-cased SRPM logic, naming the SRPM after the first generated package or not is a functional packager decision not a technical one, Fonts and Go spec files use both styles depending on upstream state.
From the start up this had to cope with rpm parser constrains. One of those constrains is that the parser is unable to close a %description in the preamble without starting a new block.
%description
Therefore it is not possible to do the natural
macro declaration & processing for first HEADER HEADER macro declaration & processing for second HEADER HEADER macro declaration & processing for third HEADER HEADER
Someone (probably one of the rpm maintainers) suggested early on to move all the parts that did HEADER-independant processing before the headers list to workaround this constrain.
macro declaration & processing for all HEADERS HEADERS
Practically that meant
macro declaration & processing for all HEADERS Sources and Patches HEADERS
Source and patch filenames consume part of the processing and they can not be injected between HEADER blocks because of the aforementionned %description limitation. A packager can not easily inject lines in the middle of a generated HEADER block and every spec needs sources so source declaration better be easy.
This is a key design decision. It was possible because the rpm parser was lenient and evaluated declarations in enough places declaration ordering did not matter.
That changed in rpm 4.15, rpm stoped being lenient. That manifests when building https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403021/ https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403020/
Copr succeeds building those so their basic structure is good, however, if you try to rebuild the second on a system where %sourcedir is set to a package-specific root in ~/.rpmmacros
%sourcedir
~/.rpmmacros
%_sourcedir %{_topdir}/SOURCES/%{name}
I will now fail with
$ rpmbuild -bs ~/rpmbuild/SPECS/sil-mondulkiri-extra-fonts.spec warning: undefined macro(s) in %{_sourcedir}: ~/rpmbuild/SOURCES/%{name} error: Bad source: ~/rpmbuild/SOURCES/%{name}/Mondulkiri-5.300.zip: No such file or directory
Which shows the rpm parser no longer copes reliably with such spec files.
This is hardly an exotic %_sourcedir construct. I’ve been using it continuously for 20+ years, and other Fedora packagers do too: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FE4V5MN667F24WA4AB34EETBWNFQGTFS/
%_sourcedir
Ironically you can check that the fully-automated package, sil-mondulkiri-fonts still works fine, it’s the one with traditional manual Name: declaration, sil-mondulkiri-extra-fonts, that breaks. Both sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts rpmspec -P to the same basic spec structure, because things are complex enough without supporting multiple Font and Go spec codeflows.
rpmspec -P
All this has been identified quite early https://bugzilla.redhat.com/show_bug.cgi?id=1820349#c6 (2020-04-03)
… except, without any productive resolution, because rpm maintainers made clear they had no intention of helping make those spec safe with the new rpm parser behavior.
It took quite a lot of heated exchanges, before @pmatilai recommended wrapping fully SRPM name processing, to make all affected packages behave like sil-mondulkiri-fonts:
Or if you want to use a macro for the project name then declare and use a macro for that, which is free of any rpm spec implied ordering. Which is basically what all these fontpackages do already for many, many things https://pagure.io/packaging-committee/issue/968#comment-641830
That is what would become %new_package in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
%new_package
And @pmatilai felt strongly enough about it he added a similar variable indirection in the rpm spec file itself https://src.fedoraproject.org/rpms/rpm/c/1b2c14f39a1c342d3e3ebde5f783bc974737e76a
(there would not be much point to define a macro for the srpm name without making sure it was used when package names are declared in Name:/%package, and I did not automate 1500+ Fedora packages to start declaring macros manually spec file by spec file)
However, %new_package alone would not work without heavy macro restructuring and packager discipline. I can do the macro restructuring (lots of work I could have done without, but I’d rather have solid macros that something rpm maintainers tell me is unsupported). Packager discipline is harder. I should know, I authored enough packaging guidelines.
Fortunately @ffesti provided the other half of the solution (thank you @ffesti, that was the trickiest part):
@nim Looking at the font example it seems like the new %sourcelist and %patchlist sections might be just doing what you need. They got added in 4.15 so they are still pretty recent. In my very preliminary testing they could easily be added to right before the %prep section. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42746
Switching the Go and Font templates and macros to use %sourcelist and %patchlist ensures that the packager can use all the preamble macros safely in his sources and patches.
%sourcelist
%patchlist
Thus:
%new_package makes sure macro sets play nice with one another without relying on %{name}
%{name}
changing the Fonts and Go packaging templates to use %sourcelist and %patchlist makes sure human packagers need not worry about all this. By the time the %sourcelist and %patchlist sections start in the spec file all of the above has been safely defined
To make this all end gracefully:
what you asked for as the "clean" solution, to add SourceName: or similar to rpm itself would render those specs incompatible for the rest of the world, for the sake of defining one macro that you can manually define in every single existing rpm version out there. That's simply a bad deal. As it is, you can backport this at your will. https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#comment-42261
Fonts and Go macros need to be updated to use %new_package
Fonts and Go packaging templates need to be updated to use the result
https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403021/
So I have tried to check this, but was not able to build it due to:
error: line 37: Unknown tag: %new_package -n %{currentfontpkgname}
Please fix this first so that we can deep dive into the issue.
As requested by FPC, this is an example before any of the devel changes. The copr is a vanilla F32 buildroot with no changes expect the two test builds.
You need to build it on a F32 system or downgrade your system to fonts-srpm-macros 2.x (the one that existed in Fedora before the work-arrounding began)
Except for the fact that the sil-mondulkiri packages are simpler and cleaner than dejavu, and permit testing both automated SRPM headers and non automates SRPM headers, all the rest is identical to the initial report in https://bugzilla.redhat.com/show_bug.cgi?id=1820349
Aside from all the font packages in devel which have been waiting for %new_package to be reviewed and merged to build for almost a month now,
https://src.fedoraproject.org/rpms/dejavu-fonts/c/e91ddfba9c9fc82b8f8e5a83a3db771354ebf91d
I've started on a new series that fully exploits @ffesti’s proposal to use %sourcelist. The package state in devel is an implementation of the first half of the solution, because at that time @ffesti had not made his suggestion.
https://copr.fedorainfracloud.org/coprs/nim/sourcelist-and-new_package/builds/
I'm not proposing it for inclusion yet because it requires more redhat-rpm-config changes than just %new_package, but it can give FPC an early idea of where this is all going. The second commit in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
is actually a backport of the changes made to %new_package in the new series, because the implementation here is more mature and better tested.
It’s a lot more ambitious than the early limited work-arounding in devel because it melds part of the coding I had already started to support Go modules (and that I had to give up on because of this issue) with taking full advantage of %new_package and %sourcelist to improve and simplify pre-existing spec structure.
So I took the same build from COPR (as mentioned in my previous comment), downgraded fonts-rpm-macros to 2.0.5-1.fc33 and tried to build it.
❯ rpmbuild --rebuild ./sil-mondulkiri-fonts-7.100-5.fc32.src.rpm 2>/dev/null | grep Wrote Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-all-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-doc-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-busra-fonts-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-7.100-5.fc33.noarch.rpm
Don't see any breakage with new RPM.
Did you have %sourcedir set to a package-specific root in ~/.rpmmacros
Or another variant such as the one José Abílio Matos mentioned on fedora-devel ?
✦ ❯ cat ~/.rpmmacros %_sourcedir %{_topdir}/SOURCES/%{name} ~/Downloads/tmp ✦ ❯ rpm -D "name foo" --eval "%{_sourcedir}" /home/brain/rpmbuild/SOURCES/foo ~/Downloads/tmp ✦ ❯ rpmbuild --rebuild ./sil-mondulkiri-fonts-7.100-5.fc32.src.rpm 2>/dev/null | grep Wrote Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-all-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-doc-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-busra-fonts-7.100-5.fc33.noarch.rpm Wrote: /home/brain/rpmbuild/RPMS/noarch/sil-mondulkiri-fonts-7.100-5.fc33.noarch.rpm ~/Downloads/tmp
With rpm-4.15.90-0.git14971.12.fc33.x86_64.
rpm-4.15.90-0.git14971.12.fc33.x86_64
Yes, this one works. To quote myself
Ironically you can check that the fully-automated package, sil-mondulkiri-fonts still works fine, it’s the one with traditional manual Name: declaration [sil-mondulkiri-extra-fonts] that breaks . It took quite a lot of heated exchanges, before @pmatilai recommended wrapping fully SRPM name processing, to make all affected packages behave like sil-mondulkiri-fonts: That is what would become %new_package in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83
Ironically you can check that the fully-automated package, sil-mondulkiri-fonts still works fine, it’s the one with traditional manual Name: declaration [sil-mondulkiri-extra-fonts] that breaks .
So we have asked you to provide a package that builds fine with RPM 4.14 and does not build with 4.15 / 4.16. I thought that COPR build you provided is supposed to demonstrate that.
Can you link the SRPM that IS broken with 4.15/4.16 but works with 4.14?
So FPC asked to provide an an example and to explain what %new_package was about, because “nobody else understands what it does” (direct FPC meeting quote).
I provided both the broken example and the one that still works, and lead to @pmatilai recommending wrapping the SRPM processing in what would become %new_package.
Could you please just read the report fully instead of skipping half of it?
https://copr.fedorainfracloud.org/coprs/nim/rpm-4.15-changes/build/1403020/
I tried to build this one with RPM 4.15, but it fails… with irrelevant problem to this ticket:
error: line 167: Bad Requirename: qualifiers: Requires(meta): sil-busra-dot-fonts = 5.300-6.fc33
So it definitely can't work with RPM 4.14
Yes Fedora 32 has Requires(meta) and previous releases did not
Requires(meta)
If you want to rewind rpm to rpm 4.15, you can use the F31 fonts-srpm-macros, it does not include F32 changes
@nim ok, can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15. What SRPM to use and what macros need to be set or not set. In a numbered list so that people can just go step-by-step and observe the issue. Ideally provide some minimal reproducer that does not involve debugging hundred lines of LUA and RPM macro to understand the issue.
Also from that COPR I see that you have:
Source0: https://scripts.sil.org/cms/scripts/render_download.php?format=file&media_id=%{archivename}&filename=%{archivename}.zip#/%{archivename}.zip … Patch0: %{name}-dummy.patch … Name: sil-mondulkiri-extra-fonts
RPM is parsing preamble line by line, then goes to the sections like %sourcelist and such. If you use %{name} in the %{_sourcedir}, you need to have all Sources / Patches defined AFTER Name. When RPM sees source (a Source or a Patch), it tries immediately to call rpmGetPath("%{_sourcedir}/", …) that of course fails because the macro can't be fully expanded at that time.
%{_sourcedir}
Source
Patch
rpmGetPath("%{_sourcedir}/", …)
This is a bug in the spec file combined with your configuration of %{_sourcedir} that uses %{name}. This does not break any single package in Fedora that are built in Fedora Infrastructure (Koji).
Anyhow, I've tried to reproduce the issue with some minimal spec file but can't which suggests to me that some of the macro (fontpkgnameX) are expanded too late (I guess that it expects files to be already unpacked, hence they depend on the Name and this thing just blows up).
fontpkgnameX
@ignatenkobrain so now you’ve finally reproduced what was in the original ticket. @pmatilai did more and traced it to the exact rpm 4.15 commit that made things break.
And, I won’t bother arguing here who is in the right and who is in the wrong. Probably, nobody.
Remember that the Fonts and Go macros were many years in the making, way before rpm 4.15 was on the roadmap, they only landed at about the same time because it took months to write the documentation FPC reviewed, and more months for this documentation to be reviewed and approved.
Also
This is not about how things ideally would be, this is about the existing spec reality. Which is that the spec is not a declarative language but a weird piece of script that executes from top down with multitude of arbitrary side-effects all along the way. https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610211002
Given that there is no wish rpm maintainer side to revert this commit, and unless you have some magic solution rpm side to keep things working, do you still not understand and disagree with the making things work plan outlined by @pmatilai and @ffesti. Namely:
@pmatilai: making sure the macro logic does not use %{name} directly, only a safe %{source_name} that does not suffer from rpm ordering constrains → that is the %new_package PR
%{source_name}
@ffesti: making sure human packagers declare sources and patches after all the preamble things that end in source and patch filenames are defined → that is switching the macros and templates to %sourcelist and %patchlist (which was not possible before rpm 4.15 since they were added in rpm 4.15)
@nim as you abstained from providing reproducer: do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?
@ignatenkobrain I don’t think anyone understands how deep the issue is. As @pmatilai wrote himself:
Much to my surprise, this used to work in rpm < 4.15. Bisecting shows it was broken by commit 93604e2 which claims to have no functional changes, but clearly it did as spec parse now fails with "error: Bad source: %{name}-urn-dtd.patch: No such file or directory" https://github.com/rpm-software-management/rpm/issues/1161#issue-593220447
That’s why, since no one claims to understand the extent of the damage, the two-part resolution plan proposed by @pmatilai and @ffesti is simple and brutal:
And please stop claiming there is not reproducer or information was not provided. You reproduced it. Panu reproduced it. Your attitude is quite tiring and unfriendly.
@nim
can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15. What SRPM to use and what macros need to be set or not set. In a numbered list so that people can just go step-by-step and observe the issue. Ideally provide some minimal reproducer that does not involve debugging hundred lines of LUA and RPM macro to understand the issue.
You did not provide this.
Hence I am once more asking:
do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec?
@nim Please answer this simple question as yes or no. In case of no, please provide how exactly to reproduce this.
yes
no
@nim I'm sorry, but I fail to follow your arguments / evidence.
What about:
PatchX
Would doing those two things solve the problem?
@decathorpe
sil-mondulkiri-fonts
sil-mondulkiri-extra-fonts
Frankly, it’s a lot easier to fix the implementation to be always correct, than to fix people, or convince them to be careful about weird special cases, or to have them play ordering roulette games with the rpm parser.
I do not especially like to write guidelines, you do not especially like to review them, and packagers do not especially like to read them. Better to have things that just work.
Did you take a look at the code in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/83#request_diff ? It is way simpler and easier to understand than all that has already been written here
moving Name above PatchX is not possible in all cases because of the structure of those spec files
That's why I made the case distinction in my comment.
not using %{name} macro in Patch file names goes against decades of Fedora packager conditioning
I only encounter Patches with such names in packages that are older than 10 years. But that's beside the point. Expanding %{name} or not using it at all would solve your problem, yes?
I only encounter Patches with such names in packages that are older than 10 years.
Panu actually counted %{name} use in Fedora Source names:
I could 13730 uses of %{name} in SourceX in Fedora as of a few days ago. https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610286641
That’s how deeply ingrained the practice is. And did not count use in Patch, which is the same as far as this issue is concerned. And no one knows if other parts of the preamble are now problematic, %{name} is just the most commonly used, and triggered the rpm issue first.
Using %sourcelist and %patchlist makes it impossible to trigger this kind of problem in Sources and Patches which is why I like @ffesti’s suggestion.
Expanding %{name} or not using it at all would solve your problem, yes?
No that would not. It would solve it in my spec files, not all the spec files that use my packaging templates and that Fedora packagers expect me to support (as I did for more than a decade now).
That’s how deeply ingrained the practice is.
Do I care about cruft? No.
Expanding %{name} or not using it at all would solve your problem, yes? No that would not. It would solve it in my spec files, not all the spec files that use my packaging templates and that Fedora packagers expect me to support (as I did for more than a decade now).
How can it solve it in your packages but not solve it for others?
Because solving it in other spec files implies writing documentation and answering the cries for help of packagers that hit the same problem for years, while changing the macros and templates to work in all cases is a one-time operation.
Alright, I give up. If you want to add another layer to your Rube Goldberg machine instead of doing those simple - possibly even scriptable - changes, then go ahead, but you won't get any support from me ...
/signing off
@nim please answer this question (try number 3). Just simple yes or no. In case of no - write more details.
@ignatenkobrain
can you please provide exact steps how to reproduce the issue: what versions of fonts-rpm-macros & co are needed for RPM 4.14 and then for RPM 4.15.
Just use the Fedora 31 fonts macros. Most of the code was written months before rpm 4.15 was released, I doubt they include anything 4.15 specific. If some late adjustment is 4.15 specific I will be happy to provide a backport.
The issue occurs with the spec and configuration provided as reproducer. It may occur in other cases but I do not know of them and do not know rpm internal code well enough to guess what they would be. I did not deliberately set up to trigger rpm breakage. I hit it as part of my everyday packager and macro maintainer activity.
do I understand correctly that issue happens only if you use %{name} in %{_sourcedir} and only if Sources / Patches that depend (directly or transitively) on %{name} are defined before Name tag in the spec? The issue occurs with the spec and configuration provided as reproducer
This is exactly what I was trying to get from you through all dozen of comments here.
Sorry, but this does not qualify as "breaking 1750 packages". It simply did not break any Fedora packages that are built in Fedora Infrastructure.
@pnemade @petersen I have reverted fonts-rpm-macros to 2.0.5 in Rawhide so that you can actually build fonts.
@nim Please continue discussion in a normal way with redhat-rpm-config maintainers and once you have agreement with them about %new_package and the PR is merged - feel free to update fonts-rpm-macros to the new version. Also avoid breaking fonts or any other macros before that.
:fire_engine: is not needed here, FPC can stop worrying now.
Metadata Update from @ignatenkobrain: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Thank you @ignatenkobrain for helping on this ticket. I confirm packages are built successfully with this revert of fonts-rpm-macros package.
Login to comment on this ticket.