https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: kde-apps/libkexiv2-21.04.0 fails to compile. Discovered on: amd64 (internal ref: tinderbox) NOTE: This machine uses GCC-11: https://gcc.gnu.org/gcc-11/porting_to.html If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 704139 [details] build.log build log and emerge --info
Possible context of error(s): Could not find a package configuration file provided by "Qt5Gui" with any
dev-qt/qtgui is in DEPEND/RDEPEND.
(In reply to Andreas Sturmlechner from comment #3) > dev-qt/qtgui is in DEPEND/RDEPEND. Right, just like https://bugs.gentoo.org/787035#c3 from today and the same in the past. What is going on here?
I think I said this in the past but you really want —-complete-graph and possibly even —-deep when running a tinderbox style operation (straight from Zac), otherwise various deps will not be satisfied at later steps.
I don't see qtgui in the emerge history and by default it is not installed
(In reply to Agostino Sarubbo from comment #6) > I don't see qtgui in the emerge history and by default it is not installed So why doesn’t emerge want to install it? What does emerge -pv qtgui say?
(In reply to Agostino Sarubbo from comment #6) > I don't see qtgui in the emerge history and by default it is not installed The ebuild maintainer cannot possibly do more than correctly define build dependencies, which is the case here. > * dependency graph for kde-apps/libkexiv2-21.04.0 > `-- kde-apps/libkexiv2-21.04.0 ~amd64 > `-- dev-qt/qtgui-5.15.2-r1 (>=dev-qt/qtgui-5.15.2) ~amd64 If you believe there is a bug by dev-qt/qtgui not being present, it can only be in Portage.
*** Bug 787035 has been marked as a duplicate of this bug. ***
*** Bug 784629 has been marked as a duplicate of this bug. ***
And with that, kde proj is outta here.
*** Bug 787974 has been marked as a duplicate of this bug. ***
*** Bug 787836 has been marked as a duplicate of this bug. ***
*** Bug 787977 has been marked as a duplicate of this bug. ***
Something is definitely wrong here. Several bugs ended up hitting poppler5[qt] bugs where it is already a dep too.
*** Bug 787917 has been marked as a duplicate of this bug. ***
(In reply to Sam James from comment #15) > Something is definitely wrong here. Several bugs ended up hitting > poppler5[qt] bugs where it is already a dep too. Yes, it's bug 756199.
(In reply to Zac Medico from comment #17) > (In reply to Sam James from comment #15) > > Something is definitely wrong here. Several bugs ended up hitting > > poppler5[qt] bugs where it is already a dep too. > > Yes, it's bug 756199. Aha, thank you. Is there any chance this is related to bug 787947 too?
*** Bug 787728 has been marked as a duplicate of this bug. ***
*** Bug 792399 has been marked as a duplicate of this bug. ***
*** Bug 794865 has been marked as a duplicate of this bug. ***
*** Bug 782604 has been marked as a duplicate of this bug. ***
*** Bug 847265 has been marked as a duplicate of this bug. ***
Think I hit this today multiple times. harfbuzz[cairo] failed to emerge because x11-libs/cairo wasn't installed.
*** Bug 860018 has been marked as a duplicate of this bug. ***
*** Bug 883971 has been marked as a duplicate of this bug. ***
*** Bug 895966 has been marked as a duplicate of this bug. ***
*** Bug 906252 has been marked as a duplicate of this bug. ***
All known bugs for this in Portage are fixed as of 3.0.56. Please file new bugs with details, ideally with a reproducer, if it happens again.
(I should say: there is still bug 756199, but there's no practical cases we're aware of where that happens right now, so...)
Created attachment 880072 [details] parsebib.log parsebib.log
(In reply to Sam James from comment #29) > All known bugs for this in Portage are fixed as of 3.0.56. Please file new > bugs with details, ideally with a reproducer, if it happens again. Reproduced with parsebib few minutes ago. However I don't really have a reproducer, just emerge parsebib
(In reply to Agostino Sarubbo from comment #32) > (In reply to Sam James from comment #29) > > All known bugs for this in Portage are fixed as of 3.0.56. Please file new > > bugs with details, ideally with a reproducer, if it happens again. new bug please...
(In reply to Agostino Sarubbo from comment #32) > Reproduced with parsebib few minutes ago. However I don't really have a > reproducer, just emerge parsebib Yeah this deserves a new bug report, and USE flags may be relevant. From stage3 I found these 3 cycles with USE="X acl gmp inotify ssl systemd threads xpm zlib Xaw3d alsa athena cairo dbus dynamic-loading games gfile gif gpm gsettings gtk gui gzip-el harfbuzz imagemagick jit jpeg json kerberos lcms libxml2 livecd m17n-lib mailutils motif png small-ja-dic sound source sqlite svg test tiff toolkit-scroll-bars tree-sitter valgrind webp wide-int xft xml xwidgets": * Error: circular dependencies: (app-emacs/commander-0.7.0-r1:0/0::gentoo, ebuild scheduled for merge) depends on (app-emacs/ert-runner-0.8.0:0/0::gentoo, ebuild scheduled for merge) (buildtime) (app-emacs/commander-0.7.0-r1:0/0::gentoo, ebuild scheduled for merge) (buildtime) It might be possible to break this cycle by applying the following change: - app-emacs/commander-0.7.0-r1 (Change USE: -test) (media-libs/libwebp-1.3.2:0/7::gentoo, ebuild scheduled for merge) depends on (media-libs/tiff-4.5.1:0/6::gentoo, ebuild scheduled for merge) (buildtime_slot_op) (media-libs/libwebp-1.3.2:0/7::gentoo, ebuild scheduled for merge) (buildtime_slot_op) It might be possible to break this cycle by applying any of the following changes: - media-libs/tiff-4.5.1 (Change USE: -webp) - media-libs/libwebp-1.3.2 (Change USE: -tiff) (media-libs/harfbuzz-8.2.0:0/6.0.0::gentoo, ebuild scheduled for merge) depends on (media-libs/freetype-2.13.2:2/2::gentoo, ebuild scheduled for merge) (buildtime_slot_op) (media-libs/harfbuzz-8.2.0:0/6.0.0::gentoo, ebuild scheduled for merge) (buildtime) It might be possible to break this cycle by applying the following change: - media-libs/freetype-2.13.2 (Change USE: -harfbuzz)
(In reply to Sam James from comment #18) > (In reply to Zac Medico from comment #17) > > (In reply to Sam James from comment #15) > > > Something is definitely wrong here. Several bugs ended up hitting > > > poppler5[qt] bugs where it is already a dep too. > > > > Yes, it's bug 756199. Looking at this again, I don't see how find_smallest_cycle could drop an unsatisfied build-time dependency. It could definitely drop a "satisfed" build-time dependency though, as in bug 921333. > Aha, thank you. Is there any chance this is related to bug 787947 too? Circular deps like that trigger find_smallest_cycle misbehavior, but find_smallest_cycle should never be able to drop unsatisfied dependencies, and I'm currently clueless about what is causing this.
It's worth noting that the tinderbox case is pathological -- lots of --oneshots.
(In reply to Zac Medico from comment #35) > Looking at this again, I don't see how find_smallest_cycle could drop an > unsatisfied build-time dependency. I'm talking for bug 923447 where I had the opportunity to make a set of tests. In my (pretty empty) stage3 when you want to emerge parsebib you get: [binary N ] acct-group/mail-0-r2-1 [binary N ] app-eselect/eselect-ctags-1.19-1 [binary N ] app-eselect/eselect-emacs-1.19-1 [binary N ] net-libs/liblockfile-1.17-1 [binary N ] app-emacs/emacs-common-1.9-1 [binary N ] app-editors/emacs-29.2-1 [ebuild N ] app-emacs/parsebib-4.3 So I expect that all depend are installed before, but for some reason (note that tinderbox uses emerge -j) emerge history (qlop -mv) is empty in https://923447.bugs.gentoo.org/attachment.cgi?id=883898 that means 2 (or more) possible scenario: 1) app-emacs/parsebib is processed by emerge before all deps get installed 2) DEPEND are calculated in a wrong way and then app-emacs/parsebib is installed like you are using 'emerge -O' I tried to reproduce manually this issue but I did not get anywhere in the end, however I noticed (especially with parsebib and some emacs ebuild) that I have reproduced the issue a lot of times.
