Bug 1875899 - texlive-kpathsea and texlive-xetex has wrong order on rawhide
Summary: texlive-kpathsea and texlive-xetex has wrong order on rawhide
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Kadlčík
QA Contact:
URL:
Whiteboard:
Depends On: 1876430 1876441 1878090
Blocks: 1827602
TreeView+ depends on / blocked
 
Reported: 2020-09-04 15:52 UTC by Petr Menšík
Modified: 2020-09-21 12:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-21 12:05:49 UTC
Embargoed:


Attachments (Terms of Use)
The update transaction. (34.12 KB, text/plain)
2020-09-07 09:56 UTC, Pavel Raiskup
no flags Details

Description Petr Menšík 2020-09-04 15:52:29 UTC
Description of problem:
I am trying building my bind 9.16 candidate. However, texlive installation is not the same as when I use fedpkg mockbuild. For some reason, texlive-kpathsea filetriggers are not run correctly. Check details in bug #1827602 comment #9.

That makes the installation later non-functional and tex building fails.

It fails only on rawhide and F33 chroots, works on f31 and f32. Texlive package requires are different, it may be related.

Version-Release number of selected component (if applicable):


How reproducible:
reliable

Steps to Reproduce:
1. Copr project settings from https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/package/texlive-test/
2. build for f33 and rawhide
3. curl -s https://download.copr.fedorainfracloud.org/results/pemensik/bind-9.16/fedora-{31,32,33,rawhide}-x86_64/01637867-texlive-test/root.log.gz | gunzip -c | grep -E 'Installing.*(texlive-kpathsea|texlive-xetex)'
(4.) fmtutil-sys --listcfg | grep /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf

Actual results:
DEBUG util.py:623:    Installing       : texlive-kpathsea-7:20190410-8.fc31.x86_64          113/387 
DEBUG util.py:623:    Installing       : texlive-xetexconfig-9:svn45845-19.fc31.noarch      254/387 
DEBUG util.py:623:    Installing       : texlive-xetex-7:20190410-8.fc31.x86_64             313/387 
DEBUG util.py:623:    Installing       : texlive-kpathsea-7:20190410-12.fc32.x86_64         115/395 
DEBUG util.py:623:    Installing       : texlive-xetexconfig-9:svn45845-19.fc32.noarch      256/395 
DEBUG util.py:623:    Installing       : texlive-xetex-7:20190410-12.fc32.x86_64            321/395 
DEBUG util.py:623:    Installing       : texlive-xetexconfig-9:svn45845-27.fc33.noarch      524/632 
DEBUG util.py:623:    Installing       : texlive-xetex-7:20200327-15.fc33.x86_64            551/632 
DEBUG util.py:623:    Installing       : texlive-kpathsea-7:20200327-15.fc33.x86_64         556/632 
DEBUG util.py:623:    Installing       : texlive-xetexconfig-9:svn45845-27.fc33.noarch      524/632 
DEBUG util.py:623:    Installing       : texlive-xetex-7:20200327-15.fc34.x86_64            551/632 
DEBUG util.py:623:    Installing       : texlive-kpathsea-7:20200327-15.fc34.x86_64         556/632 


Expected results:
texlive-kpathsea and texlive-xetex are installed in the same order. fmtutil-sys would then read expected configuration

Additional info:
I am not sure whether it is problem in texlive-base package or COPR. I have tried playing with dnf --installroot and --releasever changes, but it always installed tex with existing fmtutil.cnf. It also always worked on fedpkg scratch- build or mockbuild. It seems it has wrong order only on COPR.

Source Type:
    Build from an SCM repository
SCM type:
    git
Clone URL:
    https://src.fedoraproject.org/forks/pemensik/rpms/bind.git
Committish:
    texlive-test
Subdirectory:
    texlive
Build SRPM with:
    rpkg

Comment 1 Petr Menšík 2020-09-04 16:06:55 UTC
Note:

texlive-xetex is installed last on f31 and f32, where build works.
But it does not work on f33 and f34, where texlive-xetex is installed before texlive-kpathsea.

This is strange, because kpathsea should be always first.

$ dnf repoquery --requires texlive-xetex | grep texlive-kpathsea
Last metadata expiration check: 0:07:50 ago on Fri 04 Sep 2020 11:57:27 AM EDT.
texlive-kpathsea

Comment 2 Pavel Raiskup 2020-09-05 07:40:59 UTC
As we discussed personally, I believe we need to fix the kpathsea package.  I commented
the separate bug.  For now, I'm keeping this bug open, but let's discuss the problem
there first.

Comment 3 Pavel Raiskup 2020-09-07 08:11:08 UTC
Have you also tried to build with bootstrap ON?

Comment 4 Pavel Raiskup 2020-09-07 09:56:01 UTC
Created attachment 1713939 [details]
The update transaction.

I am not able to reproduce this on "updated" builder (see the
attached transaction).  Depending on if the bootstrap helps,
it may be related to any updated package on the F31 builder.

Since "just" updating the builders should help, I'd rather stop
with such fix and not waste additional time on further debugging
in our team.

If anyone wants to bisect the updated packages and debug this
further - I can provide ssh access to one of our builder
VMs.

Comment 5 Petr Menšík 2020-09-11 09:34:52 UTC
I have checked "Enable mock's use_bootstrap_container experimental feature on" and tried rebuild [1] [2]. No change in results.

Is that what you suggested?

What does it mean updating builders?

1. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1651409/
2. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1657256/

Comment 6 Petr Menšík 2020-09-11 09:37:17 UTC
 bug 1876430 and bug 1876441

Comment 7 Pavel Raiskup 2020-09-11 10:09:43 UTC
> What does it mean updating builders?

Creating a new set of VM images with updated packages.

Comment 8 Pavel Raiskup 2020-09-11 10:11:57 UTC
> Is that what you suggested?

Yes.  If that did not help, the problem will be in something different than
dnf/rpm stack.  Some low-level thing, systemd/kernel/selinux, dunno.

Comment 9 Petr Menšík 2020-09-14 09:27:11 UTC
Filled also bug 1878090 on texlive-base. Because there seems to be dependency loop. That is one of difference between f33 and f32. Not sure that is related, but it might be.

Comment 10 Jakub Kadlčík 2020-09-20 22:21:37 UTC
> Creating a new set of VM images with updated packages.

Done, builders are now running Fedora 32.

Comment 11 Pavel Raiskup 2020-09-21 05:38:57 UTC
Thanks Jakub!

Petr, can you please test that the builds in Copr are working for you now?

Comment 12 Petr Menšík 2020-09-21 10:23:24 UTC
(In reply to Pavel Raiskup from comment #11)
> Thanks Jakub!
> 
> Petr, can you please test that the builds in Copr are working for you now?

Oh yes, it seems this issue is fixed now.
It built all packages:

https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1680002/

Comment 13 Pavel Raiskup 2020-09-21 12:05:49 UTC
Thank you for checking!  I'm closing this, then.


Note You need to log in before you can comment on or make changes to this bug.