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 li
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 /usr/tests/lib/l
> 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 insta
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. Stop
(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 buil
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 sour
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 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 sound
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 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 w
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 TARGET
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 whene
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 tind
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, reb
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
> >>> usin
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 s
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 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, 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
> >>> us
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 automati
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 para
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 it
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 my
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/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 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 w
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 primitive
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 /etc/make.c
28 matches
Mail list logo
