Closed rlemosor closed 1 year ago
(blind copied the issue in here from an older tracker, adjusted the text)
The complication with this is that Fedora's texlive is divided into texlive and texlive-base. RHEL's texlive has both of those in one package. I don't have any proposals for the fix, I'm just pointing out the main reason for the discrepancy.
Just FTR, rubygem-kramdown is apparently one of the packages which builds in ELN but fails in c9s [1].
Long overdue, but I've reached out to the RHEL maintainer of texlive to see if we can get some movement here before RHEL 10 branches.
While a RHEL-like ELN build now exists, some parts of texlive/texlive-base are still being pulled in from rawhide:
https://tiny.distro.builders/view-srpm--view-eln--texlive.html https://tiny.distro.builders/view-srpm--view-eln--texlive-base.html
Therefore we need to 1) remove any unwanted texlive BRs from ELN packages, and 2) make sure that the ELN subset of texlive is self-contained.
Just encountered this trying to prune dependencies of dblatex:
Error:
Problem: package texlive-collection-xetex-12:20230311-2.eln126.noarch from eln-appstream requires tex-awesomebox, but none of the providers can be installed
- package texlive-awesomebox-12:20230311-2.eln126.noarch from eln-appstream requires tex-fontawesome, but none of the providers can be installed
- package texlive-awesomebox-12:20230311-2.eln126.noarch from local requires tex-fontawesome, but none of the providers can be installed
- cannot install the best candidate for the job
- nothing provides fontawesome-fonts needed by texlive-fontawesome-12:20230311-2.eln126.noarch from eln-appstream
- nothing provides fontawesome-fonts needed by texlive-fontawesome-12:20230311-2.eln126.noarch from local
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
This seems to have been fixed in https://src.fedoraproject.org/rpms/texlive/c/4787cd33692eff75b6ba7c5ba0d087fa9d2e1286?branch=rawhide but obviously not in the eln branch which seems to have no common history with rawhide.
Also on the "self-contained" front, cjk and xecjk are listed in the workload but %if 0
'd in the spec file, which is the cause of at least some of the rawhide builds still showing up.
This seems to have been fixed in https://src.fedoraproject.org/rpms/texlive/c/4787cd33692eff75b6ba7c5ba0d087fa9d2e1286?branch=rawhide but obviously not in the eln branch which seems to have no common history with rawhide.
Thanks, filed: https://src.fedoraproject.org/rpms/texlive/pull-request/7
And filed https://src.fedoraproject.org/rpms/dblatex/pull-request/5 to hopefully prune some unwanted texlive deps.
Also on the "self-contained" front, cjk and xecjk are listed in the workload but
%if 0
'd in the spec file, which is the cause of at least some of the rawhide builds still showing up.
/cc @ngothan
@yselkowitz , we want to reduce more packages so xecjk and cjk should be dropped. Should we remove them from configs/sst_cs_system_management-text-processing.yaml in order to prune these deps?
@yselkowitz , we want to reduce more packages so xecjk and cjk should be dropped. Should we remove them from configs/sst_cs_system_management-text-processing.yaml in order to prune these deps?
Yes, they'll need to be delisted, but if this change applies only to eln, then the c9s config needs to be split out.
@yselkowitz , this change should only apply to eln. We don't plan to remove them from c9s! Could you please help me with split out?
Thanks!
ELN texlive configuration looks good now, the test will be the rebuild.
@ngothan, I just noticed that the ELN texlive build uses xpdf instead of poppler. We already need poppler in RHEL for all other PDF-related features, are you sure that we really want xpdf in RHEL 10 just for texlive?
@yselkowitz, it's the intention because texlive upstream dropped poppler support.
Here is the texlive's statement:
# poppler is aggressively developed, with requirements for new compilers
# and language versions. That's fine for them, but since we don't need
# anything new, it has become too time-consuming and problematic to
# continue to support it in the TL sources, when we don't have any
# requirement for it.
I am working on reducing the deps in xpdf, since texlive only needs xpdf-libs and xpdf-devel for ELN/RHEL10. I will commit this change today or early next week.
CR is showing the following warning for the texlive workload:
The following required packages are not available (and were skipped):
- texlive-texlive-docindex
- texlive-updmap-map
@yselkowitz , texlive-texlive-docindex and texlive-updmap-map were dropped by texlive upstream. We need to remove them from ELN
i created pull request for that: https://github.com/minimization/content-resolver-input/pull/863
@yselkowitz , could you please merge this above PR ?
Thanks!
@ngothan I don't have merge privileges there, but those that do will get to it in due course.
Merged.
@ngothan ELN texlive-related build failure, could you help diagnose? https://kojipkgs.fedoraproject.org//work/tasks/2399/102272399/build.log
@yselkowitz Sure, i will have a look today.
@yselkowitz I tried to build cairomm on my test machine with f38 using mock, but got errors:
No matches found for the following disable plugin patterns: local, spacewalk, versionlock
Fedora - ELN BaseOS - Developmental packages for the next Enterprise Linux release 3.1 kB/s | 2.3 kB 00:00
Fedora - ELN AppStream - Developmental packages for the next Enterprise Linux release 3.3 kB/s | 2.3 kB 00:00
Fedora - ELN CodeReady Linux Builders - Build packages for the next Enterprise Linux rele 5.8 kB/s | 2.3 kB 00:00
No matching package to install: 'mm-common >= 1.0.4'
No matching package to install: 'pkgconfig(mm-common-libstdc++)'
Not all dependencies satisfied
Error: Some packages could not be found.
It looks like ELN buildroot repo is missing in my mock setting. Could you please give me the url to such repo?
Thanks!
add --enablerepo=local
to use the full buildroot.
@yselkowitz, This issue is fixed in texlive-20230311-4. I also removed texlive-tibetan and texlive-arabxetex.
PR: https://github.com/minimization/content-resolver-input/pull/871
@sgallagher , it would be great if you could merge it. Thank you!
cairomm built successfully in ELN with -4. The forthcoming ELN mass rebuild will be the real test.
@yselkowitz , Thanks for feedback! Do you know when is the ELN mass rebuild?
@ngothan ELN mass rebuild is under way, first texlive-related error:
https://kojipkgs.fedoraproject.org//work/tasks/9074/102629074/build.log
@ngothan another: https://kojipkgs.fedoraproject.org//work/tasks/4731/102634731/build.log
@yselkowitz , it should be fixed in texlive-20230311-7.eln127.
@sgallagher could you please merge https://github.com/minimization/content-resolver-input/pull/891 which is needed for this fix.
Thanks
@ngothan thanks, -7 fixed those two, and it doesn't look like any other mass rebuild failures are related to texlive.
@yselkowitz do we have a url to mass rebuild failures ?
@yselkowitz do we have a url to mass rebuild failures ?
I'm tracking them in #141
@tdawson , is there any reason why you built texlive-base in ELN branch?
https://koji.fedoraproject.org/koji/buildinfo?buildID=2227842
We have to stop building texlive-base in ELN branch and remove it from there because it is redundant with the new texlive package (adapted for RHEL10) in ELN branch!
You are correct, the texlive-base
source package should not be built in ELN. Unfortunately it still shows up in the dependency tree periodically when the rawhide builds of certain packages (which BuildRequires other texlive components only in the Fedora builds) are tagged in prior to being rebuilt for ELN. @sgallagher @tdawson is there a way to permanently block the texlive-base SRPM from ELN?
I manually built it. We had hundreds (600-1200) of packages that were mis-tagged, and/or not built. I did my best to filter things. But when things were in Content Resolver's list, they kept showing up to be built even when I was trying to not build them. (I kept taking python3.11 out of the list, and I still ended up rebuilding it.) It's very likely that I built several packages that we don't want. ELN rpm builds now work. Although I'm certain there are many packages that still don't build due to the dependencies, it seems I'm causing more harm than good, so I'll stop.
@tdawson as i know stephen already untagged and removed it from the auto-build list.
If you still find dependency issue in texlive in ELN branch, please report it here. so i can fix it.
Thanks!
ELN repeat of F39 mass rebuild completed without any texlive issues, so I'm calling this done.
The texlive shipped in RHEL is a minimal subset of the upstream distribution providing only what is strictly needed, whereas the version shipped in Fedora (and currently ELN) contains the whole texlive distribution, which is several orders of magnitude larger.
This causes issues with the Content Resolver, as it is pulling in FAR more dependencies than it needs to. Also, some packages that build fine in ELN (e.g. libtommath) fail in RHEL 9 because they do not have all the necessary texlive packages to build their documentation.
It is probably too late to address this for RHEL 9 (we will sort out the issues in CentOS Stream 9 soon), but it is now opportune to look into this for Rawhide/ELN for RHEL 10 as Fedora 34 has already branched (in Feb, 2021) and been released (late Apr 2021).