Summary: | random/package: build failure because a DEPEND is not scheduled before | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | asturm, esigra, juippis, sam, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 155723 | ||
Attachments: |
build.log
parsebib.log |
Description
Agostino Sarubbo
2021-04-30 06:17:29 UTC
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. |