From owner-freebsd-arch@freebsd.org Fri Feb 15 15:50:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4C2314DED67 for ; Fri, 15 Feb 2019 15:50:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B72166F322 for ; Fri, 15 Feb 2019 15:50:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1FFoQSt009386 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Feb 2019 07:50:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1FFoQdw009385; Fri, 15 Feb 2019 07:50:26 -0800 (PST) (envelope-from sgk) Date: Fri, 15 Feb 2019 07:50:26 -0800 From: Steve Kargl To: Johannes Lundberg Cc: freebsd-arch@freebsd.org Subject: Re: "DRM removal soon" is premature Message-ID: <20190215155026.GA9317@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: B72166F322 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.71 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; TO_DN_SOME(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.62)[0.621,0]; NEURAL_HAM_LONG(-0.48)[-0.477,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.790,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(0.09)[ip: (0.17), ipnet: 128.95.0.0/16(0.23), asn: 73(0.10), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 15:50:31 -0000 On Fri, Feb 15, 2019 at 09:07:08AM +0000, Johannes Lundberg wrote: > > This happens all time for me with virtualbox-kmod as well in current. > Changes to src breaks certain (kmod) ports and there's always a delay > until they are fixed. This is life in -CURRENT. I accept this and don't > go bitching to virtualbox-kmod maintainers about it. Your usage is an > edge case so naturally there will be a longer delay before breakage is > noticed, until we can get automated CI up and running (even so, there > will be a delay). > Was virtualbox-kmod every a part of the FreeBSD base sytem? drm2 was a part of the base system and it was functional until it was unhooked from the build. The issue with the merged PAE vs. non-PAE i386/pmap.h would have been identified prior to it being committed if either drm2 had not been unhooked or if an exp-run over ports was run. I also don't see how this is an edge case. A part of drm2 removal was the creation of a port, so those who don't have the luxury of updating hardware every year can continue to use drm2. If this type of breakage of functionality formerly in base, and the name calling of someone pointing out the breakage, is the new norm, then it is a harbinger of doom for pkg-base. -- Steve