Bug 239682
| Summary: | Default to devel/llvm90 when libLLVM/libclang are required or if /usr/bin/clang is not enough | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> |
| Component: | Individual Port(s) | Assignee: | Jan Beich <jbeich> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | arrowd, ashish, brooks, cmt, gecko, grahamperrin, henry.hu.sh, imp, info, jbeich, jmd, kde, linimon, pgsql, rozhuk.im, santhosh.raju, tobik, val, x11, yuri, zeising |
| Priority: | --- | Keywords: | needs-qa |
| Version: | Latest | Flags: | arrowd:
maintainer-feedback+
ashish: maintainer-feedback+ jbeich: maintainer-feedback? (brooks) cmt: maintainer-feedback+ jbeich: maintainer-feedback? (cs) jbeich: maintainer-feedback? (ed) jbeich: maintainer-feedback? (gecko) henry.hu.sh: maintainer-feedback+ info: maintainer-feedback+ jbeich: maintainer-feedback+ jmd: maintainer-feedback+ jbeich: maintainer-feedback? (kde) jbeich: maintainer-feedback? (pgsql) santhosh.raju: maintainer-feedback+ tobik: maintainer-feedback+ jbeich: maintainer-feedback? (x11) yuri: maintainer-feedback+ |
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240629 | ||
| Bug Depends on: | 235215, 240722 | ||
| Bug Blocks: | |||
|
Description
Jan Beich
2019-08-06 20:40:45 UTC
A commit references this bug: Author: tobik Date: Wed Aug 7 08:47:31 UTC 2019 New revision: 508301 URL: https://svnweb.freebsd.org/changeset/ports/508301 Log: devel/ccls: Update to latest commit This should make it work with devel/llvm90. PR: 239682 Changes: head/devel/ccls/Makefile head/devel/ccls/distinfo www/cliqz was built without issues using llvm-90 In my test run, Mk/bsd.default-versions.mk was updated from 80 to 90 and the bulk builds were run. The builds were tested successfully for the following versions of FreeBSD. 11.2-RELEASE-p12 12.0-RELEASE-p8 13.0-CURRENT 1300037 r350364 Both amd64/i386 were tested out in the above versions. Right now the lang/rubinius is broken due to non-LLVM reasons, so this update is good to go from my side. I will look at trying to fix it, or expire it soon. A commit references this bug: Author: tobik Date: Thu Aug 8 11:42:06 UTC 2019 New revision: 508373 URL: https://svnweb.freebsd.org/changeset/ports/508373 Log: security/afl++: Update to latest commit This makes it work with devel/llvm90. PR: 239682 Changes: head/security/afl++/Makefile head/security/afl++/distinfo What's required from me? (In reply to Gleb Popov from comment #5) Report https://reviews.freebsd.org/P291 upstream, update or cherry pick the fix and test. (In reply to Jan Beich from comment #6) I've done that, but I believe it's much easier to fix KLEE dependency to llvm80 instead of LLVM_DEFAULT. (In reply to Gleb Popov from comment #7) > much easier to fix KLEE dependency to llvm80 instead of LLVM_DEFAULT. The patch in review D21172 already does. Unless the port supports only one LLVM version (e.g., llvm80 but not llvm70, llvm60) then using LLVM_DEFAULT is kinda OK if you're willing to support. If we do end up with USES=llvm it'd be nice to have something more than version range checks. Alternatively, library support (e.g., libclang from devel/llvm*, libatomic from lang/gcc*) can be added into USES=compiler after throwing out unused cruft. KLEE supports 6.0, 7.0 and 8.0 as of now. Upstream is known to lag behind newest LLVM releases. At the moment I do not have a FreeBSD workstation. So, I did setup a new FreeBSD VM and modified editors/jucipp port to rely on LLVM90. Now, I am getting the following weird error: # Created by: Mohammad S. Babaei <info@babaei.net> install -m 0644 unstable/pointer-gestures/pointer-gestures-unstable-v1.xml '/usr/ports/graphics/wayland-protocols/work/stage/usr/local/share/wayland-protocols/unstable/pointer-gestures' ====> Compressing man pages (compress-man) ===> Installing for wayland-protocols-1.17 ===> Checking if wayland-protocols is already installed ===> Registering installation for wayland-protocols-1.17 as automatic Installing wayland-protocols-1.17... ===> mesa-libs-18.3.2_1 depends on package: wayland-protocols>=1.8 - found ===> Returning to build of mesa-libs-18.3.2_1 ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/pthread-stubs.pc - found ===> mesa-libs-18.3.2_1 depends on executable: bison - found ===> mesa-libs-18.3.2_1 depends on executable: msgfmt - found ===> mesa-libs-18.3.2_1 depends on executable: gmake - found ===> mesa-libs-18.3.2_1 depends on package: pkgconf>=1.3.0_1 - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/bin/python2.7 - found ===> mesa-libs-18.3.2_1 depends on package: llvm80>=3.9.0_4 - not found ===> llvm80-8.0.1_2 needs Python 3.6 at least, but 2.7 was specified. *** Error code 1 Stop. make[7]: stopped in /usr/ports/devel/llvm80 *** Error code 1 Stop. make[6]: stopped in /usr/ports/graphics/mesa-libs *** Error code 1 Stop. make[5]: stopped in /usr/ports/graphics/mesa-libs *** Error code 1 Stop. make[4]: stopped in /usr/ports/graphics/cairo *** Error code 1 Stop. make[3]: stopped in /usr/ports/graphics/cairo *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/gobject-introspection *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/gtk-update-icon-cache *** Error code 1 Stop. make: stopped in /usr/ports/editors/jucipp I have to mention I also did $ cat /etc/make.conf DEFAULT_VERSIONS+=python=3.6 But it does not change anything. But, if I do $ cat /etc/make.conf DEFAULT_VERSIONS+=python=3.6 DEFAULT_VERSIONS+=llvm=90 // or $ cat /etc/make.conf DEFAULT_VERSIONS+=llvm=90 I get the following error ===> Applying FreeBSD patches for mesa-libs-18.3.2_1 ===> mesa-libs-18.3.2_1 depends on package: wayland-protocols>=1.8 - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/pthread-stubs.pc - found ===> mesa-libs-18.3.2_1 depends on executable: bison - found ===> mesa-libs-18.3.2_1 depends on executable: msgfmt - found ===> mesa-libs-18.3.2_1 depends on executable: gmake - found ===> mesa-libs-18.3.2_1 depends on package: pkgconf>=1.3.0_1 - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/bin/python2.7 - found ===> mesa-libs-18.3.2_1 depends on package: llvm90>=3.9.0_4 - found ===> mesa-libs-18.3.2_1 depends on package: xorgproto>=0 - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xcb.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xdamage.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xfixes.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xshmfence.pc - found ===> mesa-libs-18.3.2_1 depends on file: /usr/local/libdata/pkgconfig/xxf86vm.pc - found ===> mesa-libs-18.3.2_1 depends on shared library: libwayland-egl.so - found (/usr/local/lib/libwayland-egl.so) ===> mesa-libs-18.3.2_1 depends on shared library: libexpat.so - found (/usr/local/lib/libexpat.so) ===> mesa-libs-18.3.2_1 depends on shared library: libdrm.so - not found ===> License MIT accepted by the user ===> libdrm-2.4.98_1,1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by libdrm-2.4.98_1,1 for building ===> Extracting for libdrm-2.4.98_1,1 => SHA256 Checksum OK for libdrm-2.4.98.tar.bz2. ===> Patching for libdrm-2.4.98_1,1 ===> Applying extra patch /usr/ports/graphics/libdrm/files/extra-xf86drm.c ===> Applying FreeBSD patches for libdrm-2.4.98_1,1 ===> libdrm-2.4.98_1,1 depends on file: /usr/local/libdata/pkgconfig/pthread-stubs.pc - found ===> libdrm-2.4.98_1,1 depends on executable: meson - not found ===> meson-0.51.0 needs Python 3.5 at least, but 2.7 was specified. *** Error code 1 Stop. make[9]: stopped in /usr/ports/devel/meson *** Error code 1 Stop. make[8]: stopped in /usr/ports/graphics/libdrm *** Error code 1 Stop. make[7]: stopped in /usr/ports/graphics/libdrm *** Error code 1 Stop. make[6]: stopped in /usr/ports/graphics/mesa-libs *** Error code 1 Stop. make[5]: stopped in /usr/ports/graphics/mesa-libs *** Error code 1 Stop. make[4]: stopped in /usr/ports/graphics/cairo *** Error code 1 Stop. make[3]: stopped in /usr/ports/graphics/cairo *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/gobject-introspection *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/gtk-update-icon-cache *** Error code 1 Stop. make: stopped in /usr/ports/editors/jucipp How should I get past these Python things and test the actual editors/jucipp port? (In reply to Mohammad S. Babaei from comment #10) See bug 233723. I tested cquery with newer version of LLVM, and "cquery --test-unit" and "cquery --check <sample c++ file>" seem to work fine. We can make it use the default LLVM version with this patch:
diff --git a/devel/cquery/Makefile b/devel/cquery/Makefile
index 4ebab81..a91ea4a 100644
--- a/devel/cquery/Makefile
+++ b/devel/cquery/Makefile
@@ -12,8 +12,8 @@ LICENSE= MIT
BROKEN_powerpc64= fails to build: Checking for 'clang++' (C++ compiler): not found
-BUILD_DEPENDS= llvm-config60:devel/llvm60
-LIB_DEPENDS= libclang.so:devel/llvm60
+BUILD_DEPENDS= llvm-config${LLVM_DEFAULT}:devel/llvm${LLVM_DEFAULT}
+LIB_DEPENDS= libclang.so:devel/llvm${LLVM_DEFAULT}
USES= compiler:c++14-lang waf
@@ -28,7 +28,7 @@ GH_TUPLE= miloyip:rapidjson:daabb88:rapidjson/third_party/rapidjson \
PLIST_FILES= bin/cquery
-CONFIGURE_ARGS= --variant=system --llvm-config=${LOCALBASE}/bin/llvm-config60
+CONFIGURE_ARGS= --variant=system --llvm-config=${LOCALBASE}/bin/llvm-config${LLVM_DEFAULT}
MAKE_ARGS= --variant=system
post-install:
(In reply to Henry Hu from comment #13) > We can make it use the default LLVM version with this patch: Already proposed and landed as part of bug 232598. (In reply to Jan Beich from comment #12) OK, thanks that solved the issue for me. I'll test editors/jucipp and report back soon. editors/jucipp passes all the following tests with LLVM90 just fine:
make stage
make stage-qa
make check-orphans
make package
make install
make deinstall
make clean
(In reply to Jan Beich from comment #0) > Those not ready by release to stop using LLVM_DEFAULT or be marked BROKEN. I don't understand why we would desire to mark them BROKEN. This seems like a POLA violation to me. The former I understand, the latter not so. (In reply to Mark Linimon from comment #17) Runtime. Loading more than one libLLVM.so version can lead to crashes. A consumer cannot block other consumers from switching. If only one devel/llvm existed (like in OpenBSD Ports) then it'd be mainly about making consumers build. For example, OpenGL application can load LLVM via graphics/mesa-dri and as part of its own usage. In the past emulators/rpcs3 was affected until it switched to static linking and later to bundled LLVM copy of development snapshot. Currently, I suspect lang/clover is affected. Pining mesa-dri and blocking OpenGL-based LLVM consumers from switching just because a barely usable OpenCL implementation isn't compatible yet due to being based on very old upstream release would be silly. (In reply to Jan Beich from comment #18) Clover *is* a part of Mesa, it should never use a different version than other parts. If the clover port doesn't build with llvm90 right now, it's time to upgrade Mesa. Mesa master builds completely with 9, including clover and everything. A commit references this bug: Author: jmd Date: Sun Sep 8 00:01:24 UTC 2019 New revision: 511525 URL: https://svnweb.freebsd.org/changeset/ports/511525 Log: devel/oclgrind: always compile with CXX/CC from LLVM_DEFAULT This will fix issues when switching LLVM_DEFAULT to 9.0 on releases with older base compilers. PR: 239682 Changes: head/devel/oclgrind/Makefile A commit references this bug: Author: jbeich Date: Fri Sep 20 19:58:45 UTC 2019 New revision: 512440 URL: https://svnweb.freebsd.org/changeset/ports/512440 Log: Switch default devel/llvm* to 90 PR: 239682 Reviewed by: tobik Differential Revision: https://reviews.freebsd.org/D21172 Changes: head/Mk/bsd.default-versions.mk head/Mk/bsd.gecko.mk head/comms/gnuradio/Makefile head/databases/postgresql11-server/Makefile head/databases/postgresql12-server/Makefile head/devel/android-tools-simpleperf/Makefile head/devel/ccls/Makefile head/devel/clazy/Makefile head/devel/cloudabi-toolchain/Makefile head/devel/cquery/Makefile head/devel/dmlc-core/Makefile head/devel/ikos/Makefile head/devel/ispc/Makefile head/devel/kdevelop/Makefile head/devel/libclc/Makefile head/devel/oclgrind/Makefile head/devel/pijul/Makefile head/devel/py-llvmcpy/Makefile head/devel/qt5-qdoc/Makefile head/devel/qtcreator/Makefile head/devel/rust-bindgen/Makefile head/devel/shiboken2/Makefile head/editors/jucipp/Makefile head/graphics/mesa-dri/Makefile head/graphics/pcl-pointclouds/Makefile head/graphics/qgis-ltr/Makefile head/lang/beignet/Makefile head/lang/clover/Makefile head/lang/rubinius/Makefile head/mail/thunderbird/Makefile head/math/casadi/Makefile head/misc/veles/Makefile head/net/aluminum/Makefile head/net/waypipe/Makefile head/science/agrum/Makefile head/science/erkale/Makefile head/security/afl/Makefile head/security/afl++/Makefile head/security/klee/Makefile head/textproc/castxml/Makefile head/textproc/sonic/Makefile head/www/cliqz/Makefile head/www/firefox/Makefile head/www/firefox-esr/Makefile I'm unhappy that this went in without giving devel/llvm90 some time to settle after the release. Worse it was committed during a conference and I had vacation and international flights scheduled in the 10 days after this so I'm still cleaning up lose ends. As a matter of good practice, I'd prefer to week at least two weeks delay between the commit of the release version and a LLVM_DEFAULT update. (In reply to Brooks Davis from comment #22) That's unfortunate. I've expected you to prepare before release. Even after excluding time for EuroBSDCon 2019 + time for travel there was roughly 1 month available. Regressions won't magically disappear unless reported, be found unless users start dogfooding, and users won't dogfood before LLVM_DEFAULT switch. What you're proposing is not a good practice but an exception for 1 maintainer. And the result would be loss of motivation to prepare before release for me and maybe other maintainers i.e., ~1 month before reduced to 2 weeks after. (In reply to Jan Beich from comment #23) when the llvm developers tell you it isn't ready, it isn't ready. When the graphics folks tell you it isn't ready, it isn't ready. If it's not ready, timing doesn't matter. Please start listening to your peers. Bland assertions that we need to do this, or that a week is enough time are flat out wrong. This really needs to be backed out and you need to adopt a more conservative approach to pushing things in. You are literally making a lot of people very mad at you for not listening to them. There's a lot of smart people in the project, and when they are mad at you for how you've done something, it pays to listen. They are almost certainly right. (In reply to Warner Losh from comment #24) > when the llvm developers tell you it isn't ready, it isn't ready. Release happens when "the llvm developers" decide something "is ready" for wide consumption. > When the graphics folks tell you it isn't ready, it isn't ready. Before you've started with FUD they were silent for the whole duration. x11@ was in CC as requested in Mk/bsd.default-versions.mk. > If it's not ready, timing doesn't matter. Please start listening to your peers. Assignee decides when patch "is ready" to land. At the time there were no blockers and maintainer timeout was reached. After landing all regressions were promptly fixed. I don't think I've made any mistakes. > Bland assertions that we need to do this, Assignee decides what work and how it's done. There were several issues (confusion and blind spots) but it's a net positive. I'll try to do better in future. > or that a week is enough time are flat out wrong. 2019-09-20 (landing) - 2019-08-06 (review request) = 45 days. > This really needs to be backed out Why? I need a technical rationale. > and you need to adopt a more conservative approach to pushing things in. Provide more details, including how to treat bad actors. My approach works fine elsewhere i.e., wherever the graphics team is not involved. > You are literally making a lot of people very mad at you for not > listening to them. I'm awaiting brooks@ reply to shed light on what led to planning/prioritization failure. Otherwise, it looks like a one-off misunderstanding. > There's a lot of smart people in the project, and when they are mad > at you for how you've done something, it pays to listen. They are > almost certainly right. I do listen but don't blindly follow unless requested by the authority in charge. "Smart people" is ambiguous term, those who excel at coding may not be good at negotiating. Obviously, you have a lot more such experience but the current attitude falls short. YOU BROKE GNOME AND HAVEN'T FIXED IT. All that other stuff is smoke and mirrors that ignores the fact this dump a big turd into the FreeBDS pkg pool and you aren't taking responsibility for your actions. Stop deflecting and fix this. You think you are right, but you are wrong and if you don't step up to the responsibility of having a commit bit there will be consequences. (In reply to Jan Beich from comment #25) >(In reply to Warner Losh from comment #24) >> when the llvm developers tell you it isn't ready, it isn't ready. >Release happens when "the llvm developers" decide something "is ready" for wide >consumption. No, FreeBSD decides when llvm is ready for FreeBSD. >> When the graphics folks tell you it isn't ready, it isn't ready. >Before you've started with FUD they were silent for the whole duration. x11@ was in CC >as requested in Mk/bsd.default-versions.mk. It broke gnome. It broke other things. People don't always have time to try things here. >> If it's not ready, timing doesn't matter. Please start listening to your peers. >Assignee decides when patch "is ready" to land. At the time there were no blockers and >maintainer timeout was reached. After landing all regressions were promptly fixed. I >don't think I've made any mistakes. I think you have. I can't use gnome. I had to waste half a day to trouble shoot it and switch over to LXDE. >> Bland assertions that we need to do this, >Assignee decides what work and how it's done. There were several issues (confusion and >blind spots) but it's a net positive. I'll try to do better in future. Right. You didn't wait for the people in the project who spent lots of time maintaining things to reply. In the past, we've not done big compiler bumps on a 'timeout' basis. You didn't get a positive affirmation from Brooks, for example. That's not cool. Even if there's technically a timeout rule, you have to use some common sense around this and not do it on a 'timeout' basis. >> or that a week is enough time are flat out wrong. >2019-09-20 (landing) - 2019-08-06 (review request) = 45 days. It was a week before the branch. And we knew *RIGHT*AWAY* things were broken. And 9.0 hasn't been out for 45 days, so this is *BOGUS*. >> This really needs to be backed out >Why? I need a technical rationale. You broke stuff. It's really that simple. >> and you need to adopt a more conservative approach to pushing things in. >Provide more details, including how to treat bad actors. My approach works fine >elsewhere i.e., wherever the graphics team is not involved. Brooks isn't on the graphics team. People do not like your bull in a chinashop approach. You have ignored the feedback and now claim it's OK except for the graphics people? No, I don't buy it. And even so, if the graphics people are complaining, it's on *YOU* to fix it. You are literally the only person I've had to have more than a single conversation with due to problems created for the graphics folks. >> You are literally making a lot of people very mad at you for not >> listening to them. >I'm awaiting brooks@ reply to shed light on what led to planning/prioritization >failure. Otherwise, it looks like a one-off misunderstanding. It is not. There have been many complaints about you to over the past six months. I've not had success being nice, so I'm being firm now. >> There's a lot of smart people in the project, and when they are mad >> at you for how you've done something, it pays to listen. They are >> almost certainly right. > >I do listen but don't blindly follow unless requested by the authority in charge. >"Smart people" is ambiguous term, those who excel at coding may not be good at >negotiating. Obviously, you have a lot more such experience but the current attitude >falls short. My current attitude is because I'm sick to death of mopping up messes caused by your lack of attention to detail and your lack of acknowledging that there's a problem here to fix. My attitude is a direct result of prior attempts failing to produce better behavior and at my wits end for knowing how to move forward. (In reply to Jan Beich from comment #23) I did prepare over the whole 9.0.0 cycle, I find your implications that I did not offensive. You are correct that some bugs won't be found until LLVM_DEFAULT is bumped, but doing it without coordination with me (the PR does not count) and making the switch the I was unavailable to respond to the reports is unacceptable. I'm upset that users are getting a less than ideal experience due to your needless rush to bump the default and worse that we've inflicted it on the quarterly branch effectively untested. Let's also look at the timeline: September 19th: 9.0.0 was released September 25th: llvm90 port was updated to 9.0.0 release September 28th: LLVM_DEFAULT bumped. 3 days is too fast. It broke things like llvm (I burned half a day digging out from that mess after I updated after the packages were built). It couldn't have possibly been tested in just 3 days. Finally, the exprun for FreeBSD base has kept it from upgrading to 9.0 because the fallout from this upgrade is too large. Let that sink in: we can't upgrade base because llvm 9.0 is too broken. And yet it got rushed in just before the quarterly branch. This is not sound engineering. Two edits to my last message:
(1) LLVM_DEFAULT was bumped September 20th, 5 days before the port was updated to the 9.0 release:
Author: jbeich <jbeich@35697150-7ecd-e111-bb59-0022644237b5>
Date: Fri Sep 20 19:58:36 2019 +0000
Switch default devel/llvm* to 90
PR: 239682
Reviewed by: tobik
Differential Revision: https://reviews.freebsd.org/D21172
git-svn-id: svn+ssh://svn.freebsd.org/ports/head@512440 35697150-7ecd-e111-bb59-0022644237b5
So the bug was closed the 28th, but the default was updated days before the port was updated.
(2) the thing that broke for me was gnome (or some part of gnome, it's hard to know for sure since it rendered my laptop unusable in X w/o switching to something else)...
(In reply to Brooks Davis from comment #28) > You are correct that some bugs won't be found until LLVM_DEFAULT is bumped, but > doing it without coordination with me (the PR does not count) and making the > switch the I was unavailable to respond to the reports is unacceptable. "(the PR does not count)" bit is offensive to me. In ports/ the primary way to cooperate with each other is either via bugzilla. Other ways are too easily lost in the noise. For one, portmgr@ encourages every ports/ contributor to file a bug even for stuff submitted on phabricator. Why are you ignoring the place where the coordination happens? > I'm upset that users are getting a less than ideal experience due to > your needless rush to bump the default and worse that we've > inflicted it on the quarterly branch effectively untested. Despite watching bugzilla, maillists, freebsd forums, reddit, twitter, gitter everything looked fine. Now that Warner said Gnome (without giving more details) I've searched again and have found the following: https://forums.freebsd.org/threads/gnome-starts-in-black.72497/post-441133 If so (i.e., related) it implies only /quarterly users run Gnome, so the issue wouldn't be found by extra waiting on /latest. The fix would be to pin mesa-dri to llvm80. Would have to be done during LLVM_DEFAULT=100 bump, anyway. (In reply to Warner Losh from comment #29) > Finally, the exprun for FreeBSD base has kept it from upgrading to > 9.0 because the fallout from this upgrade is too large. Let that > sink in: we can't upgrade base because llvm 9.0 is too broken. And > yet it got rushed in just before the quarterly branch. This is not > sound engineering. LLVM_DEFAULT bump is too small scale compared to base Clang upgrades. There are only 43 consumers. I regularly touch ports with ~100 consumers, often without filing any bugs. And I've helped fixing base Clang bustage as well. (In reply to Jan Beich from comment #31) > If so (i.e., related) it implies only /quarterly users run Gnome This is a false assumption. (In reply to Jan Beich from comment #31) > > You are correct that some bugs won't be found until LLVM_DEFAULT is bumped, but > > doing it without coordination with me (the PR does not count) and making the > > switch the I was unavailable to respond to the reports is unacceptable. > > "(the PR does not count)" bit is offensive to me. In ports/ the primary way to cooperate with each other is either via bugzilla. Other ways are too easily lost in the noise. For one, portmgr@ encourages every ports/ contributor to file a bug even for stuff submitted on phabricator. A PR is useful and necessary for a something like this, but a group PR with noisy history is no substitute for making individual contact with the most effected parties. If you only want to communicate via PRs then I can make a habit of setting maintainer-feedback to "-" immediately, but that doesn't feel like a constructive way to proceed. One additional point on LLVM updates, many downstream projects don't do their updates to new versions until after release. This isn't great, but it's reality. In the past I've found we had better luck waiting a few weeks or even a month so more things had been updated to support modern LLVM versions to reduce the amount of version smear in a typical pkg set. Making the LLVM_DEFAULT bump lift as many ports as possible at once is helpful in that it reduces the number of stragglers that need to be chased down later as we try to keep the number of versions under control. A commit references this bug: Author: jbeich Date: Fri Oct 4 20:08:28 UTC 2019 New revision: 513776 URL: https://svnweb.freebsd.org/changeset/ports/513776 Log: graphics/mesa-dri: revert r512573 and limit to llvm80 after r512440 Mesa 18.3 doesn't support LLVM 9. While some fixes were backported there're probably more issues. Apparently, Gnome shows black screen. As the port is unlikely to be ready for future LLVM_DEFAULT bumps without a version update just limit to previously tested value. PR: 239682 Requested by: imp Changes: head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/graphics/mesa-dri/files/patch-0a7e767 head/graphics/mesa-dri/files/patch-39d0c68 head/graphics/mesa-dri/files/patch-3e249b8 head/graphics/mesa-dri/files/patch-648dc52 head/graphics/mesa-dri/files/patch-b5012a0 head/graphics/mesa-dri/files/patch-dded2ed head/graphics/mesa-dri/files/patch-e4803ab head/lang/clover/Makefile A commit references this bug: Author: jbeich Date: Fri Oct 4 20:09:13 UTC 2019 New revision: 513777 URL: https://svnweb.freebsd.org/changeset/ports/513777 Log: MFH: r513776 graphics/mesa-dri: revert r512573 and limit to llvm80 after r512440 Mesa 18.3 doesn't support LLVM 9. While some fixes were backported there're probably more issues. Apparently, Gnome shows black screen. As the port is unlikely to be ready for future LLVM_DEFAULT bumps without a version update just limit to previously tested value. PR: 239682 Requested by: imp Approved by: ports-secteam blanket Changes: _U branches/2019Q4/ branches/2019Q4/graphics/libosmesa/Makefile branches/2019Q4/graphics/mesa-dri/Makefile branches/2019Q4/graphics/mesa-dri/Makefile.common branches/2019Q4/graphics/mesa-dri/files/patch-0a7e767 branches/2019Q4/graphics/mesa-dri/files/patch-39d0c68 branches/2019Q4/graphics/mesa-dri/files/patch-3e249b8 branches/2019Q4/graphics/mesa-dri/files/patch-648dc52 branches/2019Q4/graphics/mesa-dri/files/patch-b5012a0 branches/2019Q4/graphics/mesa-dri/files/patch-dded2ed branches/2019Q4/graphics/mesa-dri/files/patch-e4803ab branches/2019Q4/lang/clover/Makefile Only Mesa because it will remain stuck on llvm80 for years due to complications with QA and build system. I don't think anything else can affect Gnome. If you find more regressions, please, report. Binary package estimates: /latest around Saturday evening. Delays mainly come from ports r513733 and ports r513734. /quarterly around Sunday morning as previous build hasn't finished yet. (In reply to Brooks Davis from comment #33) Bug noise is a good argument. I'll think of a solution e.g., splitting into many bugs, removing CC after approval, mailing off-bug. "typical pkg set" argument is double-edged, sacrificing many for the few. If LLVM_DEFAULT is too old (e.g., misses some C++20 stuff or has bugs only fixed in later version) it may lead to individual ports hardcoding llvm versions. However, some like Mesa can avoid RUN_DEPENDS by statically linking. Thanks Jan for updating Mesa. I'll see if that helps. The effects were quite odd (mouse didn't function sometimes, scrolling broken, switching windows caused hangs) and it took me a while to rule things out (tried a different mouse, tried the same advice on other computer, tracked down it was related to gnome, and not x11, sorting out trying latest drm-kmod, etc). (In reply to Jan Beich from comment #36) > "typical pkg set" argument is double-edged, sacrificing many for the few. If LLVM_DEFAULT is too old (e.g., misses some C++20 stuff or has bugs only fixed in later version) it may lead to individual ports hardcoding llvm versions. However, some like Mesa can avoid RUN_DEPENDS by statically linking. I'd like to see us bump LLVM_DEFAULT well before the next release comes out (roughly every six months), I just think it's best to give it some settle time. One could argue for waiting for the X.0.1 patch release, but that's probably more conservative than necessary. FWIW, I do get a fair bit of dogfooding even in the RCs without soliciting testing. It might be worth doing a call for testing on the mailing list for LLVM_DEFAULT bumps in the future. A commit references this bug: Author: zeising Date: Fri Oct 4 22:14:04 UTC 2019 New revision: 513788 URL: https://svnweb.freebsd.org/changeset/ports/513788 Log: Bump remaining mesa ports after llvm version change Bump these mesa ports as well, to ensure that they are rebuilt with the correct llvm port. This was missed in r513776 PR: 239682 MFH: 2019Q4 (implicit, fix for earlier commits) Changes: head/graphics/libxatracker/Makefile head/graphics/mesa-libs/Makefile head/lang/clover/Makefile A commit references this bug: Author: zeising Date: Fri Oct 4 22:15:36 UTC 2019 New revision: 513789 URL: https://svnweb.freebsd.org/changeset/ports/513789 Log: MFH: r513788 Bump remaining mesa ports after llvm version change Bump these mesa ports as well, to ensure that they are rebuilt with the correct llvm port. This was missed in r513776 PR: 239682 Approved by: ports-secteam (implicit, cleanup after earlier commits) Changes: _U branches/2019Q4/ branches/2019Q4/graphics/libxatracker/Makefile branches/2019Q4/graphics/mesa-libs/Makefile branches/2019Q4/lang/clover/Makefile |