Bug 1925922
Summary: | dependency loop with harfbuzz confuses xorg-x11-fonts-ISO8859-1-100dpi installation?? | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mamoru TASAKA <mtasaka> | ||||||
Component: | xorg-x11-fonts | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 34 | CC: | airlied, ajax, awilliam, caillon+fedoraproject, caolanm, fedora, fonts-bugs, gnome-sig, grinnz, jglisse, kevin, lupinix.fedora, mclasen, mkasik, mtasaka, negativo17, peter.hutterer, rhughes, robatino, rstrode, sandmann, tagoh, xgl-maint | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2022-06-08 01:11:17 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Mamoru TASAKA
2021-02-07 12:04:06 UTC
Created attachment 1755466 [details]
Packages used for 20210205.n.0
Created attachment 1755467 [details]
And for 20210206.0
Some similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1837812 Is this still happening? At least 20210207.n.0 compose still sees this issue, e.g. * Fedora-Astronomy_KDE-Live-Rawhide-20210207.n.0 https://koji.fedoraproject.org/koji/taskinfo?taskID=61509420 * Fedora-Scientific_KDE-Live-Rawhide-20210207.n.0 https://koji.fedoraproject.org/koji/taskinfo?taskID=61509484 (Note: please see "anaconda-packaging.log") I can't reproduce in Fedora-Workstation-Live-x86_64-Rawhide-20210207.n.0.iso fwiw. I don't think there are something we can do in freetype package but we may need to change xorg-x11-fonts or xorg-x11-fonts-utils to break this chain with Requires(pre). Just note that 20210208.n.0 compose again sees this issue, so I guess this issue must be actually fixed somehow. https://koji.fedoraproject.org/koji/taskinfo?taskID=61577605 https://koji.fedoraproject.org/koji/taskinfo?taskID=61577635 (In reply to Akira TAGOH from comment #7) > I don't think there are something we can do in freetype package but we may > need to change xorg-x11-fonts or xorg-x11-fonts-utils to break this chain > with Requires(pre). But this means every freetype comsumers may have to add manual dependency for scriptlets? Looks like this is not a scalable solution... I tried to reproduce this on toolbox: $ toolbox create -r 34 $ toolbox enter -r 34 $ sudo dnf upgrade ... $ sudo dnf install xorg-x11-fonts-ISO8859-1-100dpi ... Dependencies resolved. ======================================================================================================================= Package Architecture Version Repository Size ======================================================================================================================= Installing: xorg-x11-fonts-ISO8859-1-100dpi noarch 7.5-27.fc34 rawhide 1.0 M Installing dependencies: freetype x86_64 2.10.4-3.fc34 rawhide 394 k graphite2 x86_64 1.3.14-7.fc34 rawhide 95 k harfbuzz x86_64 2.7.4-3.fc34 rawhide 634 k libfontenc x86_64 1.1.3-15.fc34 rawhide 31 k libpng x86_64 2:1.6.37-8.fc34 rawhide 119 k xorg-x11-font-utils x86_64 1:7.5-48.fc34 rawhide 101 k Transaction Summary ======================================================================================================================= Install 7 Packages Total download size: 2.4 M Installed size: 4.3 M Is this ok [y/N]: y Downloading Packages: (1/7): graphite2-1.3.14-7.fc34.x86_64.rpm 246 kB/s | 95 kB 00:00 (2/7): libfontenc-1.1.3-15.fc34.x86_64.rpm 1.4 MB/s | 31 kB 00:00 (3/7): freetype-2.10.4-3.fc34.x86_64.rpm 887 kB/s | 394 kB 00:00 (4/7): libpng-1.6.37-8.fc34.x86_64.rpm 3.1 MB/s | 119 kB 00:00 (5/7): xorg-x11-font-utils-7.5-48.fc34.x86_64.rpm 2.8 MB/s | 101 kB 00:00 (6/7): harfbuzz-2.7.4-3.fc34.x86_64.rpm 1.3 MB/s | 634 kB 00:00 (7/7): xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch.rpm 6.3 MB/s | 1.0 MB 00:00 ----------------------------------------------------------------------------------------------------------------------- Total 1.4 MB/s | 2.4 MB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : libpng-2:1.6.37-8.fc34.x86_64 1/7 Installing : libfontenc-1.1.3-15.fc34.x86_64 2/7 Installing : graphite2-1.3.14-7.fc34.x86_64 3/7 Installing : harfbuzz-2.7.4-3.fc34.x86_64 4/7 Installing : freetype-2.10.4-3.fc34.x86_64 5/7 Installing : xorg-x11-font-utils-1:7.5-48.fc34.x86_64 6/7 Installing : xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch 7/7 Running scriptlet: xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch 7/7 Verifying : freetype-2.10.4-3.fc34.x86_64 1/7 Verifying : graphite2-1.3.14-7.fc34.x86_64 2/7 Verifying : harfbuzz-2.7.4-3.fc34.x86_64 3/7 Verifying : libfontenc-1.1.3-15.fc34.x86_64 4/7 Verifying : libpng-2:1.6.37-8.fc34.x86_64 5/7 Verifying : xorg-x11-font-utils-1:7.5-48.fc34.x86_64 6/7 Verifying : xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch 7/7 Installed: freetype-2.10.4-3.fc34.x86_64 graphite2-1.3.14-7.fc34.x86_64 harfbuzz-2.7.4-3.fc34.x86_64 libfontenc-1.1.3-15.fc34.x86_64 libpng-2:1.6.37-8.fc34.x86_64 xorg-x11-font-utils-1:7.5-48.fc34.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch Complete! No errors. also is curious that it is apparently happening for KDE spins only. Just note that this is not KDE spin only, LXQT is also affected: https://koji.fedoraproject.org/koji/taskinfo?taskID=61577770 (In reply to Mamoru TASAKA from comment #8) > But this means every freetype comsumers may have to add manual dependency > for scriptlets? Looks like this is not a scalable solution... I don't know but xorg-x11-fonts-ISO8859-1-100dpi has a manual dependency for mkfontdir with Requires(post) and Requires(postun). that may also affect dependency calculation in dnf. Hmm, what happens if we just replace "Require(post): mkfontdir" and "Require(postun): mkfontdir" in xorg-x11-fonts.spec with "Require: mkfontdir"? There are no easier way to test this because apparently this seems only reproducible with kickstart. so I'm not confident if this will really fixes. I'll try to reproduce this with info at https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-installation-image/#proc_creating-and-using-live-cd. I'm able to reproduce this with: livecd-creator --verbose --config=./fedora-live-scientific_kde.ks --fslabel=Reproducer --cache=/var/cache/live where the ks file is from https://pagure.io/fedora-kickstarts. Note that the official compose uses livemedia-creator, not livecd-creator, so this happens both with livemedia-creator and livecd-creator. I've tried to set "Requires(pre): freetype" in the xorg-x11-font-utils but unfortunately it fails with missing harfbuzz this time. When I add "Requires(pre): harfbuzz" to freetype then it fails with missing glib2. I'll try the livemedia-creator yet. The livemedia-creator fails too. I'll try whether reverting the harfbuzz support fixes this so we are sure that it is the cause. Reverting the HarfBuzz support in freetype fixes this. This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. I'm not an expert of dnf and around. I'm not really sure how adding Require(pre) takes effect for packages which doesn't have any scriptlets. even now, xorg-x11-font-utils has a dep to freetype, but it wasn't installed somehow. Looking at the log, xorg-x11-font-utils surely got installed before installing xorg-x11-fonts-ISO8859-1-100dpi. and failing on running scriptlet for xorg-x11-fonts-ISO8859-1-100dpi. so if Requires(pre) do something, shouldn't it be added to xorg-x11-fonts-ISO8859-1-100dpi which has a scriptlet? I've added the "Requires(pre)" to assure that freetype is installed before installation of xorg-x11-font-utils. I believe that dependencies does not to be satisfied during one dnf "session". But since we need the dependencies complete for xorg-x11-font-utils to work during the installation I had to add it manually. But the list is growing and it could bring another dependency issue. I have to check whether there is not a bigger "cycle" involving these packages. I'm going to have a look whether debug log from dnf tells us more about the order. Mate-Compiz spin is also affected https://koji.fedoraproject.org/koji/taskinfo?taskID=61743325 I was not able to find how the order of packages is determined but it seems that adding freetype, harfbuzz and glib2 as %post scriptlet requirement to xorg-x11-font-utils solves the issue. The libraries are installed before xorg-x11-font-utils in both livecd-creator and livemedia-creator. The creation fails for me later but it is a failure in post_trans scriptlet of kernel-core which I believe is not connected to this. I've created pull requests adding the requirements to xorg-x11-font-utils: https://src.fedoraproject.org/rpms/xorg-x11-font-utils/pull-request/2 https://src.fedoraproject.org/rpms/xorg-x11-font-utils/pull-request/3 I'm reassigning this bug to xorg-x11-font-utils. It seems to me like a best place to fix this at right now. Also breaks Cinnamon Spin [1] , Astronomy Lab [2] and Security Spin [3]. As several editions are affected, I set severity to urgent now. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=62210964 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=62210916 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=62210916 AIUI this has been fixed with this commit: * Sun Feb 21 2021 Neal Gompa <...> - 1:7.5-49 - Add OrderWithRequires for freetype to ensure freetype is installed first - Move license files to license tag on file list Can anyone confirm this please? (In reply to Peter Hutterer from comment #26) > AIUI this has been fixed with this commit: > > * Sun Feb 21 2021 Neal Gompa <...> - 1:7.5-49 > - Add OrderWithRequires for freetype to ensure freetype is installed first > - Move license files to license tag on file list > > Can anyone confirm this please? As I've already posted on @devel, this did *NOT* solve this issue. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IMIDFCTQP7PU77U4IPPV2EZVXZSZJ6KS/ Proposed as a Blocker for 34-beta by Fedora user mtasaka using the blocker tracking app because: Although this does not affect "release blocking" live images, 6 (yes, affected images increased) live spin images fail to be created due to this bug, which is really unpleasant. Thanks, guess we'll need to find the real issue then. AIUI: - xorg-x11-fonts-ISO8859-1-100dpi has Requires(post): mkfontdir - mkfontdir is Provides: mkfontdir = %{mkfontscale} in xorg-x11-font-utils - xorg-x11-font-utils has BuildRequires: pkgconfig(freetype2) - rpm -q --requires xorg-x11-font-utils shows freetype.so.6 So it looks like the Requires dependency chain is set up correctly, the fact that an explicit Requires is missing is outside the scope of either xorg-x11-font package here. dnf should make sure that by the time we get to Requires(post): mkfontdir that all the dependencies of mkfontdir are installed. So unless there's a magic command that I'm missing here, the xorg package is just the symptom, not the cause. oh, I already ran across this independently and filed https://bugzilla.redhat.com/show_bug.cgi?id=1926533 , and today I just did this: https://src.fedoraproject.org/rpms/xorg-x11-fonts/c/9d77ebd0cbb25c5d8ac07d67af6af611de3154cd?branch=rawhide there's no need for the scriptlets to be failable, and by policy they should not be. If their dependencies aren't satisfied they should just exit 0 and let RPM carry on. This should let netinsts and image composes complete, at least. "So it looks like the Requires dependency chain is set up correctly, the fact that an explicit Requires is missing is outside the scope of either xorg-x11-font package here. dnf should make sure that by the time we get to Requires(post): mkfontdir that all the dependencies of mkfontdir are installed. So unless there's a magic command that I'm missing here, the xorg package is just the symptom, not the cause." What usually turns out to be the case in these situations is that dnf/rpm/libsolv is being asked to do the impossible. Consider this: X requires(pre) Y Y requires(pre) Z Z requires(pre) X if all of X, Y and Z are selected for installation, there is no possible way the solver can solve that requirement set satisfactorily. Something has to give. What it does in this situation is effectively - it shrugs its shoulders and picks one thing to disappoint. The details are available on request but not really that important; the problem is putting the solver in this situation in the first place, not whatever it does to break the loop. That's usually the situation we're in: no matter how hard Z claims to requires(pre) X, if X also requires(pre) Z - or some elongated version of the same situation - something has to give. Just note that Fedora-34-20210223.n.0 compose DOOMED: https://pagure.io/releng/failed-composes/issue/2280 So currently we cannot confirm if this issue is resolved or not. Another solution could be to go through the affected fonts and modify them to use %posttrans instead of the %post. Marek: that's probably a good idea, unless there's any reason it may need to be done before another action in the package transaction in any case. We're working on the compose fail, it was caused by systemd-udev accidentally dropping kernel-install. See https://bugzilla.redhat.com/show_bug.cgi?id=1931957 . I think %posttrans should work. Most of what the package does is putting the fonts.dir file into place, I don't think anything requires these at install time. Hard to say for sure though. So, in the last Rawhide compose, previously-affected images built successfully, and the KDE netinst test (which previously failed because of this) worked. So I'm fairly sure my change prevents this breaking composes and installs, at least, so I'm unproposing it as a blocker. We can leave the bug open as I didn't actually make it so the scripts *work*, just made it so them failing doesn't break everything else. I'm reassigning this to xorg-x11-fonts for consideration of moving the functionality of %post scriptlets to %posttrans scriptlets due to unsatisfied dependencies of required binaries. I'm also lowering priority of this bug since the failure does not stop the iso generation now. Now on Fedora-Comp_Neuro-Live-Rawhide-20210309.n.0 livespin creation: https://koji.fedoraproject.org/koji/taskinfo?taskID=63402437 urw-base35-fonts-legacy-20200910-3.fc34.noarch installation is failing in the same way, and Fedora-Comp_Neuro-Live-Rawhide-20210309.n.0 creation failed: 08:02:26,418 INF packaging: Installed: urw-base35-fonts-legacy-20200910-3.fc34.noarch 1611899143 61b7d937b3348234f503c881fc42e17780a05e2eeee497554adba39189be6995 08:02:26,453 INF packaging: Configuring (running scriptlet for): urw-base35-fonts-legacy-20200910-3.fc34.noarch 1611899143 61b7d937b3348234f503c881fc42e17780a05e2eeee497554adba39189be6995 08:02:26,471 INF dnf.rpm: /var/tmp/rpm-tmp.bg3CQF: line 1: mkfontscale: command not found /var/tmp/rpm-tmp.bg3CQF: line 2: mkfontdir: command not found warning: %post(urw-base35-fonts-legacy-20200910-3.fc34.noarch) scriptlet failed, exit status 127 So every package which calls mkfontscale on %post scriptlet may have to change somehow.... Fedora-Design_suite-Live-Rawhide-20210309.n.0 is also failing https://koji.fedoraproject.org/koji/taskinfo?taskID=63402500 (In reply to Mamoru TASAKA from comment #38) > Now on Fedora-Comp_Neuro-Live-Rawhide-20210309.n.0 livespin creation: > https://koji.fedoraproject.org/koji/taskinfo?taskID=63402437 > > urw-base35-fonts-legacy-20200910-3.fc34.noarch installation is failing in > the same way, and > Fedora-Comp_Neuro-Live-Rawhide-20210309.n.0 creation failed: > > 08:02:26,418 INF packaging: Installed: > urw-base35-fonts-legacy-20200910-3.fc34.noarch 1611899143 > 61b7d937b3348234f503c881fc42e17780a05e2eeee497554adba39189be6995 > 08:02:26,453 INF packaging: Configuring (running scriptlet for): > urw-base35-fonts-legacy-20200910-3.fc34.noarch 1611899143 > 61b7d937b3348234f503c881fc42e17780a05e2eeee497554adba39189be6995 > 08:02:26,471 INF dnf.rpm: /var/tmp/rpm-tmp.bg3CQF: line 1: mkfontscale: > command not found > /var/tmp/rpm-tmp.bg3CQF: line 2: mkfontdir: command not found > warning: %post(urw-base35-fonts-legacy-20200910-3.fc34.noarch) scriptlet > failed, exit status 127 > > So every package which calls mkfontscale on %post scriptlet may have to > change somehow.... Since morning I am facing this issue of missing mkfontscale binary on my Fedora 34 Silverblue system. I was trying to install some non-fedora package which need urw-base35-fonts-legacy. First I thought this is related to Silverblue only as my already installed rawhide VM did not show missing mkfontscale issue as that package was already installed. As I am not aware about silverblue compose process I could not track further this issue. But now I think issue is that Peter might have missed to update urw-base35-fonts package for the recent split of xorg-x11-font-utils into mkfontscale as one of new package. I may be wrong in my assessment. yes, apologies, not sure how this slipped through. It's tracked in Bug 1937125 now, update will be out in a few minutes. This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed. |