Summary: | @world update is not finding update to llvm | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Dutch Ingraham <stoa> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=603500 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 612846 | ||
Bug Blocks: |
Description
Dutch Ingraham
2017-03-04 22:04:01 UTC
Are you sure that your mesa still needs LLVM? Please paste the output of: emerge -1vp media-libs/mesa Also, could you try: emerge --depclean -a and see if the list contains LLVM? Sorry - I should have included the fact that depcleaning had no effect:
gentoo3 ~ # emerge -ac
* Always study the list of packages to be cleaned for any obvious
* mistakes. Packages that are part of the world set will always
* be kept. They can be manually added to this set with
* `emerge --noreplace <atom>`. Packages that are listed in
* package.provided (see portage(5)) will be removed by
* depclean, even if they are part of the world set.
*
* As a safety measure, depclean will not remove any packages
* unless *all* required dependencies have been resolved. As a
* consequence of this, it often becomes necessary to run
* `emerge --update --newuse --deep @world` prior to depclean.
Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed: 434
Packages in world: 31
Packages in system: 46
Required packages: 434
Number removed: 0
gentoo3 ~ #
As to emerge -1vp media-libs/mesa, I'm not sure how to interpret the output as to whether mesa needs llvm; I've tried disabling the llvm/gallium flags, but mesa loses all 3D support without them:
gentoo3 ~ # emerge -1vp media-libs/mesa
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-libs/mesa-17.0.0::gentoo USE="classic dri3 egl gallium gbm llvm nptl pax_kernel pic -bindist -d3d9 -debug -gles1 -gles2 -opencl -openmax -osmesa (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland -xa -xvmc" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="radeon (-freedreno) -i915 -i965 -imx -intel -nouveau -r100 -r200 -r300 -r600 -radeonsi (-vc4) (-vivante) -vmware" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
If you need anything further, please let me know.
Hm, one more idea: emerge --depclean -v llvm It should print what's requiring LLVM on your system. It might be that some other package requires old LLVM. Again, I'll have to leave this up to you to interpret, but just mesa is requiring it:
gentoo3 ~ # emerge -avc llvm
Calculating dependencies... done!
sys-devel/llvm-3.7.1-r3 pulled in by:
media-libs/mesa-17.0.0 requires <sys-devel/llvm-5:0/3.7.1=, >=sys-devel/llvm-3.6.0:0[abi_x86_64(-)], <sys-devel/llvm-5:=[abi_x86_64(-)]
>>> No packages selected for removal by depclean
Packages installed: 434
Packages in world: 31
Packages in system: 46
Required packages: 434
Number removed: 0
gentoo3 ~ #
One quirk I found, which may be due to the fact that llvm is a compiler, so it may have to do with bootstrapping somehow, but 'equery depends llvm' returns llvm as a dependency of itself:
media-libs/mesa-17.0.0 [snip a bunch of if-thens]
sys-devel/llvm-3.7.1-r3 (>=sys-devel/llvm-3.5)
(In reply to Dutch Ingraham from comment #0) > @world update is not finding update to llvm. > > I'm running a systemd/hardened desktop with ACCEPT_KEYWORDS="~amd64". The > result of an 'emerge -auDN --with-bdeps=y @world' is 'Nothing to merge; > quitting.' Does it make a difference if you add --ignore-built-slot-operator-deps=y to your emerge command? That works: gentoo3 ~ # emerge -auDN --with-bdeps=y --ignore-built-slot-operator-deps=y @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-devel/llvm-3.9.1-r1 [3.7.1-r3] USE="sanitize%* -default-compiler-rt% -default-libcxx%" LLVM_TARGETS="AMDGPU%* BPF%* NVPTX%* (X86%*) -AArch64% -ARM% -Hexagon% -MSP430% -Mips% -PowerPC% -Sparc% -SystemZ% -XCore%" Would you like to merge these packages? [Yes/No] n Quitting. gentoo3 ~ # Hope this helps (because the description in the man page doesn't help *me* that much!) 'emerge -auDN --with-bdeps=y @world' now seeing the llvm update, so this bug can be closed. Thanks to all who participated here and on IRC and the mailing list! (In reply to Dutch Ingraham from comment #7) > 'emerge -auDN --with-bdeps=y @world' now seeing the llvm update, so this bug > can be closed. Did you make some kind of change to your configuration in order to get it working? It would be useful to know the specific configuration issue that triggered the problem for you. No, I thought *you* tweaked it! I just went to bed and ran a normal update (eix-sync && emerge -auDN --with-bdeps=y @world) first thing this morning. Updates to llvm and a rebuild for mesa were there (and they were the only ones.) Just to rule some common things out, this was not a mirror problem, since the one-shot command found the update (in my initial post); this is also not due to the "state" of my machine, i.e., some configuration change that did not become effective without a reboot, as I first noticed the problem 2 days ago and discussed on #gentoo, shut the system down for the night, then confirmed again the following morning (yesterday for me) and took it to the mailing list before making this bug report. I don't have any answers, but will provide any other information should you deem fit. It's possible that this issue is triggered randomly, depending on random effects which alter the path taken during backtracking. A larger --backtrack value might lead to more predictable results. They recently added mesa-17.0.1, so if that update got pulled in, then emerge would not have to trigger a rebuild for mesa-17.0.0: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5eff6ce6cec54eb7ff5b2ff53f1c24bbfbab8b8f I had previously tried a backtrack=30, which had no effect on the issue. I suppose I could have tried some larger number, but didn't think of it. Some other things that were tried are documented in this mailing list thread: https://archives.gentoo.org/gentoo-user/message/1cae40ecd04093f67b14c908ec8ac17b Also I just logged into the subject machine and check the logs - in fact mesa was upgraded, not just rebuilt as I stated above: 1488719137: === (2 of 2) Merging (media-libs/mesa-17.0.1::/usr/portage/media-libs/mesa/mesa-17.0.1.ebuild) 1488719139: >>> AUTOCLEAN: media-libs/mesa:0 1488719139: === Unmerging... (media-libs/mesa-17.0.0) 1488719142: >>> unmerge success: media-libs/mesa-17.0.0 1488719147: === (2 of 2) Post-Build Cleaning (media-libs/mesa-17.0.1::/usr/portage/media-libs/mesa/mesa-17.0.1.ebuild) 1488719147: ::: completed emerge (2 of 2) media-libs/mesa-17.0.1 to / I could speculate that the upgrade of mesa somehow triggered the (up till now hidden from @world) llvm upgrade. Is that what you were saying? (In reply to Dutch Ingraham from comment #12) > I could speculate that the upgrade of mesa somehow triggered the (up till > now hidden from @world) llvm upgrade. Is that what you were saying? Yes, because the <sys-devel/llvm-5:0/3.7.1= dependency from the previous version of mesa was locked to the 3.7.1 subslot of llvm, and a failure to trigger a rebuild of mesa would prevent the llvm upgrade. Since there was a new version of mesa available, the <sys-devel/llvm-5:0/3.7.1= dependency was no longer relevant, so it suppressed the problem. This bug was probably a symptom of bug 612846. |