Date: Wed, 20 Dec 2017 01:58:23 +0100 From: Jan Beich <jbeich@FreeBSD.org> To: Mathieu Arnold <mat@FreeBSD.org> Cc: Mark Linimon <linimon@FreeBSD.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r456719 - in head: biology/bedtools comms/gnuradio editors/libreoffice emulators/stella games/armagetron graphics/gsculpt net/linknx net/rsplib science/afni security/botan2 security/hig... Message-ID: <bmiu-jjv4-wny@FreeBSD.org> References: <201712191441.vBJEfTLf054114@repo.freebsd.org> <8tdy-a671-wny@FreeBSD.org> <7ae87444-6657-7506-f987-14ec50f648f6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mathieu Arnold <mat@FreeBSD.org> writes: > Le 19/12/2017 =C3=A0 20:06, Jan Beich a =C3=A9crit=C2=A0: > >> Mark Linimon <linimon@FreeBSD.org> writes: >> >>> Author: linimon >>> Date: Tue Dec 19 14:41:29 2017 >>> New Revision: 456719 >>> URL: https://svnweb.freebsd.org/changeset/ports/456719 >>> >>> Log: >>> Mark more recently failing ports broken on aarch64. >> Marking each port individually where commit message contains an excerpt = more >> than 1 line long would be more helpful. Build logs tend to disappear over >> time either because a machine goes offline or move. I've had trouble in = the past >> figuring out whether a fix was enough going by one cryptic 1 line in BRO= KEN >> or maybe the issue is no longer present after several port and toolchain= updates. > > Well, it would be, but it is not the aim of portmgr members (or > committers working with some delegated powers) to fix everything. Non sequitur? portmgr@ already formats commit messages adding BROKEN lines verbosely enough. I've just asked another committer to follow the suit. games/armagetron: mark BROKEN for Clang >=3D 4.0 network/nNetObject.cpp:1533:46: error: ordered comparison between pointer= and zero ('const nSocket *' and 'int') while(sn_Connections[user].socket>0 && ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ Reported by: pkg-fallout Notice how important the second line of the error message is. That's where the fix would be applied. If the line disappears (e.g., via update) go figure if BROKEN needs to be lifted. A green build doesn't guarantee the issue was actually fixed. > If you want to know how it fails, then simply try and build the port. I wish... - qemu-user-static doesn't work on powerpc* and sparc64 - qemu-user-static sometimes crashes during port build - don't always have access to a beefy machine >>> Modified: head/biology/bedtools/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> --- head/biology/bedtools/Makefile Tue Dec 19 14:40:35 2017 (r456718) >>> +++ head/biology/bedtools/Makefile Tue Dec 19 14:41:29 2017 (r456719) >>> @@ -13,8 +13,9 @@ COMMENT=3D Toolset for genome arithmetic >>> LICENSE=3D GPLv2 >>> LICENSE_FILE=3D ${WRKSRC}/LICENSE >>=20=20 >>> -BROKEN_armv6=3D fails to compile: implicit instantiation of >>> undefined template __static_assert_test<false> >>> -BROKEN_armv7=3D fails to compile: implicit instantiation of >>> undefined template __static_assert_test<false> >>> +BROKEN_FreeBSD_12_aarch64=3D fails to compile: /usr/include/c++/v1/que= ue:401:5: error: static_assert failed >>> +BROKEN_armv6=3D fails to compile: implicit instantiation of >>> undefined template __static_assert_test<false> >>> +BROKEN_armv7=3D fails to compile: implicit instantiation of >>> undefined template __static_assert_test<false> >> Why limit to Tier2 when Tier1 architectures are also affected? Affects >> any FreeBSD release/architecture defaulting to libc++ 4.0 or later. > > Because Mark mostly works on Tier 2 architectures. Does it forbid providing a post-commit review? If not, is the issue I raised incorrect? A quick look at pkg-fallout@ for the past week is enough to figure out on which FreeBSD release/architecture tuples a port fails. Obviously, one needs to double check a fix hasn't been committed recently. For one, Clang/libc++ 4.0 and Clang/libc++ 5.0 bustage spanned multiple months. > Instead of criticizing the tremendous amount of work he is doing, Do you mean "tremendous" makes any "review" into "criticism"? Or is it just mine? Please, be specific then. > simply mark them BROKEN without architecture, or fix them. That looks like a mentor's job. I'm just a low-rank reviewer that may (and often is) wrong, pointing out issues based on experience. > Let me repeat, portmgr members regularly mark things BROKEN. This is > because they do not build. Also, portmgr members WILL NOT be fixing > those ports. Was I being impolite or excessively dumb for you to "repeat"?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bmiu-jjv4-wny>