'; }
Bug 239682 - Default to devel/llvm90 when libLLVM/libclang are required or if /usr/bin/clang is not enough
Summary: Default to devel/llvm90 when libLLVM/libclang are required or if /usr/bin/cla...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jan Beich
URL:
Keywords: needs-qa
Depends on: 235215 240722
Blocks:
  Show dependency tree / graph
 
Reported: 2019-08-06 20:40 UTC by Jan Beich
Modified: 2019-10-05 05:37 UTC (History)
21 users (show)

See Also:
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+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committerfreebsd_triage 2019-08-06 20:40:45 UTC 
According to llvm.org schedule 9.0.0 is to be released sometime after 2019-08-28. Let's test/fix consumers in advance. Those not ready by release to stop using LLVM_DEFAULT or be marked BROKEN. Runtime testing of every consumer is optional - up to maintainers, a la any other library update.

See review D21172 for the patch or add DEFAULT_VERSIONS+=llvm=90 to make.conf(5).
Comment 1 commit-hook freebsd_committerfreebsd_triage 2019-08-07 08:48:01 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
Comment 2 Santhosh Raju 2019-08-07 17:59:23 UTC 
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.
Comment 3 Ashish SHUKLA freebsd_committerfreebsd_triage 2019-08-07 18:04:41 UTC 
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.
Comment 4 commit-hook freebsd_committerfreebsd_triage 2019-08-08 11:42:36 UTC 
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
Comment 5 Gleb Popov freebsd_committerfreebsd_triage 2019-08-08 13:11:03 UTC 
What's required from me?
Comment 6 Jan Beich freebsd_committerfreebsd_triage 2019-08-08 13:26:47 UTC 
(In reply to Gleb Popov from comment #5)
Report https://reviews.freebsd.org/P291 upstream, update or cherry pick the fix and test.
Comment 7 Gleb Popov freebsd_committerfreebsd_triage 2019-08-08 14:10:58 UTC 
(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.
Comment 8 Jan Beich freebsd_committerfreebsd_triage 2019-08-08 14:49:19 UTC 
(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.
Comment 9 Gleb Popov freebsd_committerfreebsd_triage 2019-08-08 15:35:34 UTC 
KLEE supports 6.0, 7.0 and 8.0 as of now. Upstream is known to lag behind newest LLVM releases.
Comment 10 Mamadou Babaei 2019-08-10 14:17:36 UTC 
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
Comment 11 Mamadou Babaei 2019-08-10 14:26:31 UTC 
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?
Comment 12 Jan Beich freebsd_committerfreebsd_triage 2019-08-10 15:59:41 UTC 
(In reply to Mohammad S. Babaei from comment #10)
See bug 233723.
Comment 13 Henry Hu 2019-08-11 05:11:43 UTC 
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:
Comment 14 Jan Beich freebsd_committerfreebsd_triage 2019-08-11 05:17:36 UTC 
(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.
Comment 15 Mamadou Babaei 2019-08-12 23:44:08 UTC 
(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.
Comment 16 Mamadou Babaei 2019-08-13 00:26:37 UTC 
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
Comment 17 Mark Linimon freebsd_committerfreebsd_triage 2019-08-27 21:17:45 UTC 
(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.
Comment 18 Jan Beich freebsd_committerfreebsd_triage 2019-08-28 07:46:15 UTC 
(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.
Comment 19 Val Packett 2019-08-28 12:32:38 UTC 
(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.
Comment 20 commit-hook freebsd_committerfreebsd_triage 2019-09-08 00:01:39 UTC 
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
Comment 21 commit-hook freebsd_committerfreebsd_triage 2019-09-20 19:59:36 UTC 
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
Comment 22 Brooks Davis freebsd_committerfreebsd_triage 2019-10-01 16:36:34 UTC 
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.
Comment 23 Jan Beich freebsd_committerfreebsd_triage 2019-10-04 05:57:16 UTC 
(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.
Comment 24 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 13:16:06 UTC 
(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.
Comment 25 Jan Beich freebsd_committerfreebsd_triage 2019-10-04 15:55:05 UTC 
(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.
Comment 26 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 15:58:53 UTC 
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.
Comment 27 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 16:09:32 UTC 
(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.
Comment 28 Brooks Davis freebsd_committerfreebsd_triage 2019-10-04 16:26:08 UTC 
(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.
Comment 29 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 16:39:37 UTC 
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.
Comment 30 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 16:54:23 UTC 
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)...
Comment 31 Jan Beich freebsd_committerfreebsd_triage 2019-10-04 17:04:47 UTC 
(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.
Comment 32 Mark Linimon freebsd_committerfreebsd_triage 2019-10-04 17:15:26 UTC 
(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.
Comment 33 Brooks Davis freebsd_committerfreebsd_triage 2019-10-04 18:10:25 UTC 
(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.
Comment 34 commit-hook freebsd_committerfreebsd_triage 2019-10-04 20:09:07 UTC 
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
Comment 35 commit-hook freebsd_committerfreebsd_triage 2019-10-04 20:10:11 UTC 
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
Comment 36 Jan Beich freebsd_committerfreebsd_triage 2019-10-04 20:22:18 UTC 
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.
Comment 37 Warner Losh freebsd_committerfreebsd_triage 2019-10-04 20:35:23 UTC 
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).
Comment 38 Brooks Davis freebsd_committerfreebsd_triage 2019-10-04 20:36:07 UTC 
(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.
Comment 39 commit-hook freebsd_committerfreebsd_triage 2019-10-04 22:14:28 UTC 
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
Comment 40 commit-hook freebsd_committerfreebsd_triage 2019-10-04 22:16:32 UTC 
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