Description of problem: I noticed that when building packages requiring doxygen in mock locally or via COPR, that libaom, rav1e-libs, svt-av1-libs, and libdav1d were installed. I first noticed this when COPR builds for aom would fail because it could not find the corresponding libaom (the corresponding libaom would have been built during the build of the aom package). In an effort to determine the problem, I noticed I could build aom if I disabled documentation, and therefore requiring doxygen. I also noticed that if I initialise mock and install doxygen, the above libs are installed. Procedure: mock --init mock --install dnf mock --shell bash dnf install doxygen (within mock, of course) The above also happens with mock -r fedora-34-x86_64 Am I missing something? Version-Release number of selected component (if applicable): mock-2.10-1 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
After some investigation it seems that the "chain" installation dependencies is like this: doxygen -> graphviz -> gd -> libavif -> (libaom + libdav1d + svt-av1-libs) This seems to make no sense, because to build libaom or libdav1d, doxygen is required. These install dependencies occur inside or outside of mock. Am I misunderstanding something? Thanks!
Sorry for the late reply, this report missed our radar. Copr Team doesn't have control over the Fedora repositories (fedora packagers). Such problems need to be reported directly to appropriate package maintainers. I think it is better to ask doxygen maintainer - switching.
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.
i cannot reproduce this issue on f35 and f36.