From owner-freebsd-pkg@FreeBSD.ORG Sat May 30 17:58:04 2015 Return-Path: Delivered-To: freebsd-pkg@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADD41FEA for ; Sat, 30 May 2015 17:58:04 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 848941D0D for ; Sat, 30 May 2015 17:58:04 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id A9961160298; Sat, 30 May 2015 10:58:03 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 1AA1516015F for ; Sat, 30 May 2015 10:58:01 -0700 (MST) Message-ID: <5569FA28.3020802@pinyon.org> Date: Sat, 30 May 2015 10:58:00 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-pkg@freebsd.org Subject: Fwd: Re: 10/stable virtualbox-ose crashes References: <5569F857.1020202@pinyon.org> In-Reply-To: <5569F857.1020202@pinyon.org> X-Forwarded-Message-Id: <5569F857.1020202@pinyon.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 17:58:04 -0000 Just discovered freebsd-pkg, so this message sent to ports might be more appropriate for this list. -------- Forwarded Message -------- Hi, On 05/29/15 10:52, Kimmo Paasiala wrote: > On Fri, May 29, 2015 at 8:45 PM, Adam McDougall wrote: >> On 05/29/2015 13:38, Kevin Oberman wrote: >>> On Fri, May 29, 2015 at 10:10 AM, Russell L. Carter >>> wrote: >>> >>>> Hi, >>>> kldload vboxsrv crashes recent 10/stables. Last known working >>>> kernel/module pair is from May 5th. >>>> >>>> Not sure what is the optimal next step, suggestions welcome. >>>> >>> >>> Sounds like you have done this, but several reports have been made of this >>> recently. All were "fixed" by rebuilding virtualbox-ose-kmod. Always >>> rebuild all kernel modules that are in ports when rebuilding the kernel, >>> preferably by adding the appropriate PORTS_MODULES to /etc/src.conf. >>> -- >>> Kevin Oberman, Network Engineer, Retired >>> E-mail: rkoberman@gmail.com >> >> Won't this will be a problem if people use official packages (built on >> 10.x-RELEASE) on a system running -stable? Wouldn't it mean an ABI was >> violated? > > > The KBI (kernel binary interface that the kernel modules use) is not > part of the promised stability, only the userland ABI is guaranteed to > stay compatible. According to: http://blog.shatow.net/posts/2015-04-27-Poudriere-FreeBSD-Journal/ "Packages are built for the oldest release of each branch. These packages are supposed to be ABI/KBI compatible with all future releases on those branches as well as the STABLE branch for that release. This means that packages built for 8.3 will work on 8.4 but are not guaranteed to work on 9.x." After sleeping on the problem, I think that the simplest approach to managing the evolution of the KBI in stable is to mark packages that depend on the KBI, port kernel modules for instance, as dependent on poudriere's world source tree. Then when the source tree is updated, on the first subsequent bulk package build port kernel modules would be correctly updated. This would eliminate the maintenance complexity I outlined in previous messages that arises from maintaining port kernel modules outside of poudriere. I just verified that updating poudriere's source tree does not currently cause any port kernel modules to be rebuilt. Comments? Thanks, Russell