On 10/08/2019 04:56, Clay Daniels Jr. wrote:
drm-kmod was the same (g20190710)
It's equally (if not more) important to consider what's installed by
drm-kmod.
Can you share output from these three commands?
pkg info | grep kmod
pciconf -lv | grep -C 3 display
grep PORTS_MODULES
On 13/08/2019 16:31, Hans Petter Selasky wrote:
> 1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to
> report an error when such a condition is occurring. Here is the
> backtrace of the illegal mutex recursion.
I have an old patch that replaces hand-rolled ACPI platform
(Please send the followup to freebsd-testing@ and note Reply-To is set.)
FreeBSD CI Weekly Report 2019-08-11
===
Here is a summary of the FreeBSD Continuous Integration results for the period
from 2019-08-05 to 2019-08-11.
During this period, we have:
* 2066
While the buildworld buildkernel seemed to go okay, and so did installkernel,
installworld is failing with:
===> lib/libc/tests/hash (install)
install -o root -g wheel -m 555 hash_test /usr/tests/lib/libc/hash/hash_test
make[7]: don't know how to make _testsDATA_FILESINS1_data/md5test-in.
I've lost the original thread, but would the sources in /usr/local/sys/modules
get built regardless of what MAKEOBJDIRPREFIX is? And, now that sources may be
installed by a port, what is the method for _just_ updating the sources? Why
do I even need to build and install the port? Personally,
> On Aug 14, 2019, at 6:59 PM, Steve Kargl
> wrote:
>
>> On Wed, Aug 14, 2019 at 06:40:28PM -0400, Daniel Eischen wrote:
>> I've lost the original thread, but would the sources in
>> /usr/local/sys/modules get built regardless of what
>> MAKEOBJDIRPREFIX is? And, now that sources may be
On Wed, Aug 14, 2019 at 06:40:28PM -0400, Daniel Eischen wrote:
> I've lost the original thread, but would the sources in
> /usr/local/sys/modules get built regardless of what
> MAKEOBJDIRPREFIX is? And, now that sources may be installed
> by a port, what is the method for _just_ updating the
On August 14, 2019 11:04:20 AM PDT, Ian Lepore wrote:
>On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
>> On 2019-08-14 19:23, Emmanuel Vadot wrote:
>> > On Wed, 14 Aug 2019 10:13:48 -0700
>> > John Baldwin wrote:
>> >
>> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
>> > > > This all
In message <10aa93aa-4fd7-47af-bfd1-994ac5a8c...@yahoo.com>, Mark
Millard write
s:
> While the buildworld buildkernel seemed to go okay, and so did installkernel,
> installworld is failing with:
>
> ===> lib/libc/tests/hash (install)
> install -o root -g wheel -m 555 hash_test
Cy Schubert wrote:
> > installworld is failing with:
> >
> > ===> lib/libc/tests/hash (install)
> > install -o root -g wheel -m 555 hash_test
> > /usr/tests/lib/libc/hash/hash_t
> > est
> > make[7]: don't know how to make _testsDATA_FILESINS1_data/md5test-in. Stop
Sorry about that. Looks
On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> On 8/14/19 11:06 AM, Kyle Evans wrote:
> > LOCAL_MODULES="" does seem like a sensible default when we're not
> > building a native kernel.
>
> Unfortunately kern.post.mk has no way of knowing that as MACHINE_*
> are already set to the
On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
> On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > LOCAL_MODULES="" does seem like a sensible default when we're not
> > > building a native kernel.
> >
> > Unfortunately kern.post.mk has no
On Wed, 2019-08-14 at 13:59 -0600, Warner Losh wrote:
> On Wed, Aug 14, 2019 at 1:56 PM Ian Lepore wrote:
>
> > On Wed, 2019-08-14 at 12:00 -0700, John Baldwin wrote:
> > > On 8/14/19 11:06 AM, Kyle Evans wrote:
> > > > LOCAL_MODULES="" does seem like a sensible default when we're
> > > > not
>
On 2019-08-14 00:35, Conrad Meyer wrote:
This is super cool, thank you! Is it feasible to integrate other
out-of-tree kmods in a similar way, e.g., nvidia-driver?
It should be possible to expand this to work with other ports that
install kmods. I think the plan is to have drm-current-kmod
On 8/13/19 3:17 PM, Ian Lepore wrote:
> On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
>> For developers this means even if you are doing testing on a box
>> that doesn't use DRM, you can install the package so that kernel
>> builds will try to compile it and hopefully spot KPI/KBI changes
On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote:
> On 8/13/19 3:17 PM, Ian Lepore wrote:
> > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote:
> > > For developers this means even if you are doing testing on a box
> > > that doesn't use DRM, you can install the package so that kernel
>
On 8/14/19 9:22 AM, Ian Lepore wrote:
> This all sounds vaguely wrong, backwards, to me. A developer who is
> using a given module on their build system might want that module to be
> rebuilt automatically, but only if the build parameters match those of
> the running build host system.
>
> If
CC @current, as I had originally intended.
On 2019-08-14 09:08, John Baldwin wrote:
1) You can set LOCALBASE to a different path either in a kernel config
(via makeoptions) or when invoking buildkernel.
For example, I mount my rpi's sdcard at /mnt on my amd64 laptop and
then cross-build into
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin wrote:
> On 8/14/19 9:22 AM, Ian Lepore wrote:
> > This all sounds vaguely wrong, backwards, to me. A developer who is
> > using a given module on their build system might want that module to be
> > rebuilt automatically, but only if the build
On 2019-08-14 19:23, Emmanuel Vadot wrote:
On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin wrote:
On 8/14/19 9:22 AM, Ian Lepore wrote:
This all sounds vaguely wrong, backwards, to me. A developer who is
using a given module on their build system might want that module to be
rebuilt
On Wed, 14 Aug 2019 19:55:02 +0200
Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> >> On 8/14/19 9:22 AM, Ian Lepore wrote:
> >>> This all sounds vaguely wrong, backwards, to me. A developer who is
> >>>
On 8/14/19 10:23 AM, Emmanuel Vadot wrote:
> On Wed, 14 Aug 2019 10:13:48 -0700
> John Baldwin wrote:
>
>> On 8/14/19 9:22 AM, Ian Lepore wrote:
>>> This all sounds vaguely wrong, backwards, to me. A developer who is
>>> using a given module on their build system might want that module to be
On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > This all sounds vaguely wrong, backwards, to me. A developer
> > > > who
On Wed, Aug 14, 2019 at 1:04 PM Ian Lepore wrote:
>
> On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> > On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > > On Wed, 14 Aug 2019 10:13:48 -0700
> > > John Baldwin wrote:
> > >
> > > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > > This all
On Wed, 14 Aug 2019 11:04:03 -0700
John Baldwin wrote:
> On 8/14/19 10:23 AM, Emmanuel Vadot wrote:
> > On Wed, 14 Aug 2019 10:13:48 -0700
> > John Baldwin wrote:
> >
> >> On 8/14/19 9:22 AM, Ian Lepore wrote:
> >>> This all sounds vaguely wrong, backwards, to me. A developer who is
> >>>
On 2019-08-14 11:04, Ian Lepore wrote:
I can't understand what you guys are not-understanding. New machinery
has been added that says "if some module source code exists in this
absolute fixed location on the build machine, then whenever you do any
kernel build for any OS version or any arch,
On 8/14/19 11:06 AM, Kyle Evans wrote:
> LOCAL_MODULES="" does seem like a sensible default when we're not
> building a native kernel.
Unfortunately kern.post.mk has no way of knowing that as MACHINE_*
are already set to the TARGET_* values by the time this target is
invoked. Also, the 'make
On 8/14/19 11:04 AM, Ian Lepore wrote:
> On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> I can't understand what you guys are not-understanding. New machinery
> has been added that says "if some module source code exists in this
> absolute fixed location on the build machine, then
28 matches
Mail list logo
