Failed compose. - [41588033](https://koji.fedoraproject.org/koji/taskinfo?taskID=41588033) Live media log:https://kojipkgs.fedoraproject.org//work/tasks/8092/41588092/livemedi... error: 2020-02-18 08:42:41,890 INFO pylorax: Non interactive installation failed: 2020-02-18 08:42:41,890 INFO pylorax: Problem: conflicting requests 2020-02-18 08:42:41,890 INFO pylorax: - nothing provides libcgns.so.3.4 needed by paraview-5.6.0-14.fc32.i686 2020-02-18 08:42:41,890 INFO pylorax: - nothing provides libcgns.so.3.4()(64bit) needed by paraview-5.6.0-14.fc32.x86_64. 2020-02-18 08:42:41,890 INFO pylorax: Root log:https://kojipkgs.fedoraproject.org//work/tasks/8092/41588092/root.log DEBUG util.py:596:  2020-02-18 08:42:41,890: Non interactive installation failed: DEBUG util.py:596:  2020-02-18 08:42:41,890: Problem: conflicting requests DEBUG util.py:596:  2020-02-18 08:42:41,890: - nothing provides libcgns.so.3.4 needed by paraview-5.6.0-14.fc32.i686 DEBUG util.py:596:  2020-02-18 08:42:41,890: - nothing provides libcgns.so.3.4()(64bit) needed by paraview-5.6.0-14.fc32.x86_64. DEBUG util.py:596:  2020-02-18 08:42:41,890:  -- Danny Lee  <dreamer(a)panix.com&gt; I have been impressed with the urgency of doing. Knowing is not enough; we must apply. Being willing is not enough; we must do.  ~ Leonardo da Vinci

On Thu, Feb 20, 2020 12:17:46 -0500, Danny Lee wrote: > Failed same error Issue #1023.  Question: should i report the same failure > in future composes? Could you comment on the ticket pointing out that cgnslib-3.4.0-4 does provide libcgns.so.3.4, and so we're not sure why this error is being thrown? These are the links for the build, and the update on Bodhi: https://koji.fedoraproject.org/koji/rpminfo?rpmID=20541315 https://bodhi.fedoraproject.org/updates/FEDORA-2020-6832b9c562 It could be related to something infra-side, so releng will be able to tell us what we're missing so we can try to fix it. How does that sound? _______________________________________________ Neurofedora mailing list -- neurofedora(a)lists.fedoraproject.org To unsubscribe send an email to neurofedora-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/neurofedora@lists.fedorapro...

On Thu, Feb 20, 2020 21:34:44 -0500, Danny Lee wrote: > Ok, so in the future I will use the commands you showed me: > > $ sudo dnf repoquery --whatprovides 'file' > > > So, it's available on F31. It isn't on F32+, though: > > $ sudo dnf --releasever 32 repoquery --whatprovides ‘file' > > And then look up the 'whatprovides' file in: > > https://koji.fedoraproject.org/koji > https://bodhi.fedoraproject.org/ > > Make sure those look good and I'll report that. Yes, that is the general way to find broken dependency errors. Note that it isn't only a file, it is a general "capability" that rpms provide. Files are one type of capability. Here, for example, we see what Python modules python3-nest provides: $ rpm -q --provides python3-nest python-nest = 2.18.0-7.fc31 python3-nest = 2.18.0-7.fc31 python3-nest(x86-64) = 2.18.0-7.fc31 python3.7dist(connplotter) = 0.7a0 python3.7dist(pynest) = nest-2.18 python3.7dist(topology) = nest-2.18 python3dist(connplotter) = 0.7a0 python3dist(pynest) = nest-2.18 python3dist(topology) = nest-2.18 So, we could run: $ sudo dnf repoquery --whatprovides 'python3dist(topology)' python3-nest-0:2.18.0-2.fc31.x86_64 python3-nest-0:2.18.0-7.fc31.x86_64 > However, looking at the error report in root log I saw a second error, I was > wondering if its valid or if the first error is the one to tackle first? > > [root log - https://kojipkgs.fedoraproject.org//work/tasks/3367/41683367/root.log] > DEBUG util.py:596: 2020-02-20 08:56:36,338: The exact error message is: > DEBUG util.py:596: 2020-02-20 08:56:36,338: > DEBUG util.py:596: 2020-02-20 08:56:36,338: Non interactive installation failed: > DEBUG util.py:596: 2020-02-20 08:56:36,338: Problem 1: conflicting requests > DEBUG util.py:596: 2020-02-20 08:56:36,338: - nothing provides libcgns.so.3.4 needed by paraview-5.6.0-14.fc32.i686 > DEBUG util.py:596: 2020-02-20 08:56:36,338: - nothing provides libcgns.so.3.4()(64bit) needed by paraview-5.6.0-14.fc32.x86_64 > DEBUG util.py:596: 2020-02-20 08:56:36,339: Problem 2: conflicting requests > DEBUG util.py:596: 2020-02-20 08:56:36,339: - package gnome-boxes-3.35.90-2.fc32.x86_64 requires libvirt-daemon-kvm, but none of the providers can be installed > DEBUG util.py:596: 2020-02-20 08:56:36,339: - package libvirt-daemon-kvm-6.0.0-1.fc32.x86_64 requires libvirt-daemon-driver-storage = 6.0.0-1.fc32, but none of the providers can be installed > DEBUG util.py:596: 2020-02-20 08:56:36,339: - package libvirt-daemon-driver-storage-6.0.0-1.fc32.x86_64 requires libvirt-daemon-driver-storage-rbd = 6.0.0-1.fc32, but none of the providers can be installed > DEBUG util.py:596: 2020-02-20 08:56:36,339: - package libvirt-daemon-driver-storage-rbd-6.0.0-1.fc32.x86_64 requires librados.so.2()(64bit), but none of the providers can be installed > DEBUG util.py:596: 2020-02-20 08:56:36,339: - package libvirt-daemon-driver-storage-rbd-6.0.0-1.fc32.x86_64 requires librados.so.2(LIBRADOS_14.2.0)(64bit), but none of the providers can be installed > DEBUG util.py:596: 2020-02-20 08:56:36,339: - nothing provides libfmt.so.5()(64bit) needed by librados2-2:15.1.0-1.fc33.x86_64. > DEBUG util.py:596: 2020-02-20 08:56:36,339: > DEBUG util.py:596: 2020-02-20 08:56:36,340: The installer will now terminate. AH! This would affect anything that pulls in the workstation, since that includes gnome-boxes. Kevin filed a bug and a new build seems to have fixed this already. So, the next compose shouldn't have this error, at least: https://bugzilla.redhat.com/show_bug.cgi?id=1805422 > Finally, when you say to comment on the ticket - you mean the issue #1023, > right?  I posted a comment at the bottom of this URLhttps://pagure.io/releng/ > failed-composes/issue/1023 Yes, the idea is to keep the releng folks in the loop as to why the compose is failing and that we're aware of it. > Is there a bug report to file anywhere? These are all bugs that should be filed against the individual packages. The individual maintainers should be fixing them. Where possible, we can help with pull requests and so on. _______________________________________________ Neurofedora mailing list -- neurofedora(a)lists.fedoraproject.org To unsubscribe send an email to neurofedora-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/neurofedora@lists.fedorapro...

On Sun, Mar 01, 2020 13:06:33 -0500, Danny Lee wrote: > A notification for paraview was emailed to NeuroFedora-bugs - > > subject line: [NeuroFedora-bugs] [Bug 1799847] paraview: FTBFS in Fedora > rawhide/f32 > > I visited the bodhi page, and saw unstable by Karma -3 and then stable by Karma > +3 and a place where I can comment myself.  Is this something that I contribute > to in terms of explaining what happened in our build? > > This is just kind of a general operating procedure kind of question. It is in testing: https://fedoraproject.org/wiki/QA:Updates_Testing You can test whether the updated version of the package works, and provide karma there. I think for the image, let's leave it out now. The image is building, and is stable. We shouldn't tinker with it too much now. Given how busy releng are with all the release related work, I'd also rather not bother them again unless absolutely necessary. :) _______________________________________________ Neurofedora mailing list -- neurofedora(a)lists.fedoraproject.org To unsubscribe send an email to neurofedora-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/neurofedora@lists.fedorapro...