Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
rubygem-kramdown failed to build from source in Red Hat Enterprise Linux 9 CentOS Stream
https://kojihub.stream.rdu2.redhat.com//koji/taskinfo?taskID=247461
For details on the mass rebuild see:
Please fix rubygem-kramdown at your earliest convenience and set the bug's status to
ASSIGNED when you start fixing it.
Hi @Than,
could you please take a look. It seems that the reason for the failure is:
~~~
LaTeX Error: File `xpatch.sty' not found.
~~~
This works on Fedora and there is also:
~~~
$ sudo dnf repoquery -q --disablerepo=* --enablerepo=rawhide --whatprovides 'tex(xpatch.sty)'
texlive-xpatch-9:svn54563-38.fc35.noarch
~~~
which does not seems to be case on RHEL9. As far as I can tell, there is missing `Source5716: https://ctan.math.illinois.edu/systems/texlive/tlnet/archive/xpatch.tar.xz` in RHEL9. Is this intentional?
There is actually this [1] commit in RHEL8, which disabled most of the test cases. However, I am not sure how I figured this out that time ¯\_(ツ)_/¯
[1] https://src.osci.redhat.com/rpms/rubygem-kramdown/c/ddb73473b8448da4ed559d5763bc8bba9aa0c057?branch=rhel-8.5.0
@Than any estimate when you could have some cycles to work on this? I don't want to put pressure on you, I am just asking because I'm still considering to just disable the specific test cases to unblock other work such as package removal from RHEL9 + git-lfs update, etc. I don't think this functionality would be essential for Kramdown.
Hi Vit,
i don't like to include xpatch.sty in texlive because it makes texlive bigger. Our goal for RHEL9 is to keep the texlive package as small as possible.
I have looked at the FTBFS place, it only happens when testing. I will suggest to disable this test.
Would the suggestion be acceptable to you?
Thanks!
(In reply to Than Ngo from comment #7)
> Hi Vit,
>
> i don't like to include xpatch.sty in texlive because it makes texlive
> bigger. Our goal for RHEL9 is to keep the texlive package as small as
> possible.
>
> I have looked at the FTBFS place, it only happens when testing. I will
> suggest to disable this test.
>
> Would the suggestion be acceptable to you?
I am fine with disabling the test cases. It will look similar to RHEL8. I'll refer to this ticket, so next time we don't need to re-evaluate ;)
Thx for looking into this.
@Than: actually, digging a bit deeper, I wonder if you are sure xpatch.sty can be omitted. It seems that the dependency chain is:
scrartcl.cls > xpatch.sty if (amsthm.sty is used)
Given that scrartcl.cls and amsthm.sty are shipped, they can also be used by other users then just Kramdown test suite. I just want to doublecheck that the possible breakage is expected.
Just FTR, this is short reproducer:
~~~
$ cat << EOF | latex
\documentclass{scrartcl}
\usepackage{amsthm}
\begin{document}
\end{document}
EOF
~~~