Warner,
Thanks for the quick response.
If I have time I'll rig up my build to disable the use of
assembly routines on x86_64 and any compiler builtin functions
to do some testing of these routines.
On Fri, Oct 22, 2021 at 10:05:38PM -0600, Warner Losh wrote:
> Done.
>
Done.
https://cgit.freebsd.org/src/commit/?id=3550a49f6814af38c21b0033ef8746953451dade
Since the license is a verbatim copy of the standard SPDX license, I tagged
it using our draft license policy's
suggested SPDX-License-Identifier: tag.
Warner
On Fri, Oct 22, 2021 at 9:14 PM Steve Kargl <
It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24
replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c,
and s_scalbnl.c by those in MUSL. There are no Copyright
notices in these files. There is no statement to the originals
of these files within the files.
If one
On Fri, Oct 22, 2021 at 04:11:56PM +, Baptiste Daroussin wrote:
>
> 22 oct. 2021 18:06:56 John Baldwin :
>
> > On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote:
> >> main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
> >> changed DIALOG_STATE, DIALOG_VARS, and
On Fri, Oct 22, 2021 at 03:51:15PM -0600, Warner Losh wrote:
> On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > All,
> >
> > With the new world order, what is the future of ident(1)?
> > Should it be removed from base? Given a compiled binary
> > in
On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> All,
>
> With the new world order, what is the future of ident(1)?
> Should it be removed from base? Given a compiled binary
> in base, how does one find the equivalent git info that
> ident(1) used to
All,
With the new world order, what is the future of ident(1)?
Should it be removed from base? Given a compiled binary
in base, how does one find the equivalent git info that
ident(1) used to perform?
Having a few minutes to dust off old patchs for libm, should
I remove $FreeBSD$ tags in files
On 10/22/21 16:00, Ludovit Koren wrote:
Hi,
I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty
on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN
interface:
ure0 on uhub0
ure0: on usbus1
miibus0: on ure0
rgephy0: PHY 0 on miibus0
rgephy0: OUI 0x00e04c,
22 oct. 2021 18:06:56 John Baldwin :
> On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote:
>> main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
>> changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
>> These are publicly exposed in (ones that I noticed):
>>
On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote:
main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
These are publicly exposed in (ones that I noticed):
/usr/include/dialog.h:extern DIALOG_STATE dialog_state;
Hi,
I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty
on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN
interface:
ure0 on uhub0
ure0: on usbus1
miibus0: on ure0
rgephy0: PHY 0 on miibus0
rgephy0: OUI 0x00e04c, model 0x, rev. 0
rgephy0: none,
On 22 Oct 2021, at 14.05, Konstantin Belousov wrote:
>
> On Fri, Oct 22, 2021 at 01:07:47AM -0700, Julian Elischer wrote:
>> Several years ago (OK, maybe 12 years ago) I did an experiment where I
>> unpacked a
>> freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing
>>
On Fri, Oct 22, 2021 at 01:07:47AM -0700, Julian Elischer wrote:
> Several years ago (OK, maybe 12 years ago) I did an experiment where I
> unpacked a
> freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing
> various
> compat packagesand options and a.out support and changing
On Fri, 22 Oct 2021 01:07:47 -0700
Julian Elischer wrote:
> Several years ago (OK, maybe 12 years ago) I did an experiment where I
> unpacked a
> freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing
> various
> compat packagesand options and a.out support and changing
main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
These are publicly exposed in (ones that I noticed):
/usr/include/dialog.h:extern DIALOG_STATE dialog_state;
/usr/include/dialog.h:extern DIALOG_VARS dialog_vars;
Several years ago (OK, maybe 12 years ago) I did an experiment where I
unpacked a
freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after
installing various
compat packagesand options and a.out support and changing MAX_PID to
be 6, I was able to
chroot to it and do a "make world".
On 9/28/21 9:15 AM, Rodney W. Grimes wrote:
On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes
wrote:
^^^
re-guid the pool on first boot.
Isnt the proper place to solve this lack of Unique UUID creation
in the tool(s) that are creating the zfs pool in the first place.
On 2021-Oct-21, at 16:24, Mark Millard wrote:
> On 2021-Oct-21, at 11:53, Mark Millard wrote:
>
>> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote:
>>
>>> On Thu, 21 Oct 2021 07:40:36 -0700
>>> Mark Millard via freebsd-current wrote:
>>>
On 2021-Oct-21, at 06:14, Gary
18 matches
Mail list logo
