Hello all,
On deskutils/treesheets port, upstream did some updated that broke build.
After investigating it upstream says we are building with an outdated C++
standard lib.
To fix it, I'm using a fall back to fast_float as we see in main PR:
https://github.com/aardappel/treesheets/issues/686
I don't want a GUI for bhyve. I want to manage everything by creating a
script in bash.
On Mon, Aug 5, 2024 at 8:52 PM Dennis Clarke wrote:
> On 8/5/24 14:22, Miroslav Lachman wrote:
> > On 05/08/2024 18:50, Dennis Clarke wrote:
> >> On 8/5/24 12:12, Harry Schmalzbauer wrote:
> >>> Hello,
> >>>
On 8/5/24 14:22, Miroslav Lachman wrote:
On 05/08/2024 18:50, Dennis Clarke wrote:
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that
utilizd bhyve(8), which already had bhyve_config(5) support back then.
This may feel
On 05/08/2024 18:50, Dennis Clarke wrote:
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that utilizd
bhyve(8), which already had bhyve_config(5) support back then.
This may feel slightly off topic but I assure you that it is of
On 2024-08-05 19:04, Mario Marietto wrote:
Hello.
I'm also interested in writing a script to manage the bhyve vms. Even if
I suspect that my approach will be different. My idea is to ask the user
what he wants to do and then the script will configure the vm getting
the information provided
Hello.
I'm also interested in writing a script to manage the bhyve vms. Even if I
suspect that my approach will be different. My idea is to ask the user what
he wants to do and then the script will configure the vm getting the
information provided by the user.
I will give a look at
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that utilizd
bhyve(8), which already had bhyve_config(5) support back then.
This may feel slightly off topic but I assure you that it is of great
benefit. Have a look at the
Hello,
two years elapsed since I last deployed a FreeBSD machine that utilizd
bhyve(8), which already had bhyve_config(5) support back then.
I was astonished that I still couldn't find bhyve in /etc/rc.d in
14.1-stable as of last week.
Since I utilize ng_bridge(8) and do some more things
> Subject: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000
> 13.2 works. 13.3 and 14.x panic.
13.3 iso will work if load ispfw first (escape to loader, unload kernel, load ispfw, load kernel, boot)
also,
adding ispfw_load="YES"
On Wed, 31 Jul 2024 at 21:52, Kyle Evans wrote:
> On 7/31/24 14:31, Gleb Smirnoff wrote:
> > On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
> > K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
> > K> > > Author: Alfonso Siciliano
> > K> > > Date: Sat May 25 02:42:46 2024
Dag-Erling Smørgrav wrote:
> Loader I/O performance is much better these days so loading modules
> pre-boot doesn't slow the boot down much any more, but it's still more
That depends very much on the h/w, especially the storage attachment.
None of which applies to any machine likely to be using
On 7/31/24 14:31, Gleb Smirnoff wrote:
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > > change: --form and --mixedgauge do not
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > > change: --form and --mixedgauge do not print field input to output
if > > eldlen>
On 7/27/24 19:28, Mark Millard wrote:
On Jul 27, 2024, at 16:07, Mark Millard wrote:
The following old files were in the historically incrementally
updated directory tree but not in the installation to an empty
directory tree (checked via diff -rq):
Hi,
I was pleasantly surprised when I installed a new [1] zfs-on-root -current
to rpi4 that when adduser was invoked, I was given the option to encrypt
the homedir. This is a great feature for my context [2].
It doesn't automount on boot but I think this is more of a feature
rather than a
On Wed, Jul 31, 2024 at 10:48:15AM -0400, John Baldwin wrote:
> On 7/31/24 08:15, void wrote:
> > Hi,
> >
> > Looking at man 4 aesni it appears this pertains to intel and AMD only?
> > is its prescence on arm64 a bug?
> >
> > It seems to be added to /boot/loader.conf by default.
> >
> > The
On 7/31/24 08:15, void wrote:
Hi,
Looking at man 4 aesni it appears this pertains to intel and AMD only?
is its prescence on arm64 a bug?
It seems to be added to /boot/loader.conf by default.
The method I used to install is to boot to the latest snapshot at
the time, then plug in a usb3 disk,
> On 31. Jul 2024, at 15:01, void wrote:
>
> On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote:
>> void writes:
>>> The arm64 device is headless and i connect to it via serial.
>>> I noticed the beastie menu come up with the option Video for
>>> console. Cycled it to
Hi,
Looking at man 4 aesni it appears this pertains to intel and AMD only?
is its prescence on arm64 a bug?
It seems to be added to /boot/loader.conf by default.
The method I used to install is to boot to the latest snapshot at
the time, then plug in a usb3 disk, ran bsdinstall to that disk,
On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote:
void writes:
The arm64 device is headless and i connect to it via serial.
I noticed the beastie menu come up with the option Video for
console. Cycled it to Serial, booted, all fine. [...]
man boot.config
Thank you for
Hello,
I've pushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
> __BSD_VISIBLE") and audited a bit for similar issues in the other ssp
> headers, but didn't see any off-hand. With that change:
>
> 100% tests passed, 0 tests failed out of 267
>
> Thanks,
>
> Kyle Evans
>
Upgraded
On Tue, Jul 30, 2024 at 10:02:37PM -0600, Warner Losh wrote:
> On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
>
> > Miroslav Lachman <000.f...@quip.cz> writes:
> > > I'm a bit confused. If I understand it right, you say loader.conf
> > > causes less memory fragmentation, but DES said
On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
> Miroslav Lachman <000.f...@quip.cz> writes:
> > I'm a bit confused. If I understand it right, you say loader.conf
> > causes less memory fragmentation, but DES said "it still increases low
> > memory fragmentation". So what is true? And
> On Jul 31, 2024, at 2:54 AM, Dag-Erling Smørgrav wrote:
>
> Miroslav Lachman <000.f...@quip.cz> writes:
>> I'm a bit confused. If I understand it right, you say loader.conf
>> causes less memory fragmentation, but DES said "it still increases low
>> memory fragmentation". So what is true?
On 07/30/2024 9:25 am, Larry Rosenman wrote:
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning:
On 7/30/24 16:16, Cy Schubert wrote:
In message , Gleb Smirnoff writes:
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilizati
on week
T> T>
In message , Gleb Smirnoff writes:
> On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
> T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
> T> T> This is an automated email to inform you that the July 2024 stabilizati
> on week
> T> T> started with FreeBSD/main at
Shawn Webb writes:
> While probably less efficient than just running the tools outright, I
> usually just set up a tmpfs that I chroot into and install those kinds
> of packages.
Yeah, I do something similar, with the footnote that I more often than
not have no internet connection, so I
On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote:
"Poul-Henning Kamp" writes:
Dag-Erling Smørgrav writes:
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
Apart from the internals of
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilization
week
T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged
as
On Tue, Jul 30, 2024 at 07:07:51PM +, Poul-Henning Kamp wrote:
> I do not want want this to turn into a everything-and-Emacs bloat-party,
> but I would find it really helpful if our install-ISO images had two
> HW-spelunking ports installed:
>
> sysutils/smartmontools
>
> and
>
>
On 2024-07-30 19:07 +, Poul-Henning Kamp wrote:
> sysutils/smartmontools
>
> and
>
> sysutils/dmidecode
>
> Is that even possible ?
>
> Am I the only one who thinks so ?
I have missed having these tools numerous times over the years. Whether it's
installing on a new
I do not want want this to turn into a everything-and-Emacs bloat-party,
but I would find it really helpful if our install-ISO images had two
HW-spelunking ports installed:
sysutils/smartmontools
and
sysutils/dmidecode
Is that even possible ?
Am I the only one who thinks so ?
void writes:
> The arm64 device is headless and i connect to it via serial.
> I noticed the beastie menu come up with the option Video for
> console. Cycled it to Serial, booted, all fine. [...]
man boot.config
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Miroslav Lachman <000.f...@quip.cz> writes:
> I'm a bit confused. If I understand it right, you say loader.conf
> causes less memory fragmentation, but DES said "it still increases low
> memory fragmentation". So what is true? And is this something to watch
> out for, or is memory fragmentation
On 7/29/24 18:04, Nuno Teixeira wrote:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
Hi,
I've pushed
On Tue, Jul 30, 2024 at 11:57:07PM +0900, Tomoaki AOKI wrote:
Another aspect is that loading multiple too large modules easily makes
boots crash. Staging area (memory region which loader allocates to load
kernel and modules, and maybe configured buffers) is limited.
This is why I went looking
On 30/07/2024 16:30, Warner Losh wrote:
[..]
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any
problems
it used to solve are solved, and that the preferred way is to load
everything from
Hi,
I have an rpi4 arm64 device at n271321-9ae91f59c500 and an amd64 image
running in screen(8) as zvol-backed vm at n271360-82283cad12a4
The arm64 device is headless and i connect to it via serial.
I noticed the beastie menu come up with the option Video for
console. Cycled it to Serial,
On Tue, 30 Jul 2024 19:22:31 +0800
Alastair Hogge wrote:
>
>
> On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
> >On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> >> Gary Jennejohn writes:
> >
> >[..]
> >
> >>> I also load it from /boot/loader.conf using
On Tue, Jul 30, 2024, 4:50 AM Poul-Henning Kamp wrote:
>
> Dag-Erling Smørgrav writes:
>
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
>
> Apart from the internals of
On Tue, Jul 30, 2024, 3:39 AM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
archive
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
>
> I'm getting the following on an up2date checkout:
> Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
> ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
> archive member 'FaultMaps.o' is neither
On 30/07/2024 12:31, Dag-Erling Smørgrav wrote:
Miroslav Lachman <000.f...@quip.cz> writes:
Dag-Erling Smørgrav writes:
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation.
Does this also apply today? I recently
On 30/07/2024 14:55, Michael Gmelin wrote:
On Tue, 30 Jul 2024 11:38:57 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
[..]
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any
problems it used to solve are
On Tue, 30 Jul 2024 11:38:57 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at
"Poul-Henning Kamp" writes:
> Dag-Erling Smørgrav writes:
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
> Apart from the internals of config(8) and it's input data, is there
>
On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
>On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
>> Gary Jennejohn writes:
>
>[..]
>
>>> I also load it from /boot/loader.conf using filemon_load="YES"
>>
>> This does cause the module to be loaded at boot time, but
Dag-Erling Smørgrav writes:
> There is very little difference between options and devices in kernel
> configuration files, but for what it's worth, filemon is a device, not
> an option.
Apart from the internals of config(8) and it's input data, is there
any actual difference left ?
--
On Tue, 30 Jul 2024 11:10:06 +0200
Dag-Erling Smørgrav wrote:
> Gary Jennejohn writes:
> > filemon is not a device, it's an option. So you can't have "device
> > filemon" in your kernel config file.
>
> There is very little difference between options and devices in kernel
> configuration
Miroslav Lachman <000.f...@quip.cz> writes:
> Dag-Erling Smørgrav writes:
> > This does cause the module to be loaded at boot time, but it's slower
> > than loading it later, and it increases memory fragmentation.
> Does this also apply today? I recently read from someone on a mailing
> list that
Hi,
On Tue, 30 Jul 2024, at 10:10, Dag-Erling Smørgrav wrote:
> void writes:
>> How would I go about remedying the issue that usage/examples
>> are not present in manpages for either the device line in kernel
>> config or filemon.ko ?
>
> https://reviews.freebsd.org/D46184
thank you!
On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
Gary Jennejohn writes:
[..]
I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option
void writes:
> How would I go about remedying the issue that usage/examples
> are not present in manpages for either the device line in kernel
> config or filemon.ko ?
https://reviews.freebsd.org/D46184
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Gary Jennejohn writes:
> filemon is not a device, it's an option. So you can't have "device
> filemon" in your kernel config file.
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
> I compile
On 7/29/24 18:04, Nuno Teixeira wrote:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
>
Hi,
Looking into it-
I understand the reason. Thanks for your investigation.
> 2024/07/30 12:37、Warner Losh のメール:
>
> That was my fault.
>
> Turns out I forgot to copy the menu version back from my laptop to my server
> before committing.
> My laptop is the only place I had the menu. I got this stuff working there
That was my fault.
Turns out I forgot to copy the menu version back from my laptop to my
server before committing.
My laptop is the only place I had the menu. I got this stuff working there
last week after I got it
working on my server... then forgot I'd done that and pushed the wrong
version...
Yes. My fault. I'll fix. I thought I'd tested the menu... but apparently
not. My apologies.
Warner
On Mon, Jul 29, 2024, 6:44 PM 内藤祐一郎 wrote:
> Hi, I updated my FreeBSD current machine to the following commit.
>
> FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
>
My lua boot loader shows no menu after updating the following commit with my
patch in the previous mail.
FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
Hi, I updated my FreeBSD current machine to the following commit.
FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
The lua loader fails as
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode
ld: warning:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
[ 47% 363/744] /usr/bin/cc -DS2N_ATOMIC_SUPPORTED
How would I go about remedying the issue that usage/examples
are not present in manpages for either the device line
in kernel config or filemon.ko ?
--
Hi,
What/where are the full instructions for installing new kernel and
world in a rpi4/arm64 zfs context?
I'm looking for instructions that would account for u-boot, zfs and
zfs encryption.
--
On Sat, 27 Jul 2024 19:31:37 +0100
void wrote:
> On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
>
> >filemon is not a device, it's an option. So you can't have "device
> >filemon" in your kernel config file.
> >
> >I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in
On Jul 27, 2024, at 16:07, Mark Millard wrote:
> The following old files were in the historically incrementally
> updated directory tree but not in the installation to an empty
> directory tree (checked via diff -rq):
>
> /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde
>
The following old files were in the historically incrementally
updated directory tree but not in the installation to an empty
directory tree (checked via diff -rq):
/usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde
/usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h
Marek Zarychta wrote:
>
> What about filesystem perfomnace ? Have you benchmarked your FS and
> whole system with and without filemon loaded ?
FWIW filemon does nothing unless make opens the device.
and then it only impacts syscalls done by that pid and its children.
> I am not questionining
slightly tangent question but does filemon and consequently
WITH_META_MODE=YES work, when /usr/obj is on tmpfs? In my test, it is not
and i tested without reboot, so /usr/obj is not removed. Reason is to avoid
disk use when building world/kernel.
On Sat, Jul 27, 2024 at 6:35 PM void wrote:
>
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
man 4 filemon has the following
NAME
filemon – the filemon device
[...]
DESCRIPTION
The filemon device allows a
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my
kernel config file.
What's the actual line in your
On Jul 26, 2024, at 21:58, Mark Millard wrote:
> On Jul 26, 2024, at 21:20, Mark Millard wrote:
>
>> The original mount was:
>>
>> mount -onoatime 192.168.1.140:/ /mnt
>>
>> For reference:
>> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
>> (nfs, noatime)
>>
>>
Dnia Sat, Jul 27, 2024 at 03:27:19PM +0100, Nuno Teixeira napisał(a):
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
What about filesystem perfomnace ? Have you benchmarked your FS and
whole system
On Sat, 27 Jul 2024 15:27:19 +0100
Nuno Teixeira wrote:
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
>
> Cheers,
>
> void escreveu (sábado, 27/07/2024 à(s) 14:50):
>
> > Is it better to load
Hello,
I use filemon for builds with WITH_META_MODE loaded from rc.conf:
kld_list="... filemon" for some years on both amd64 and aarch64.
Cheers,
void escreveu (sábado, 27/07/2024 à(s) 14:50):
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device
> On Jul 27, 2024, at 9:49 PM, void wrote:
>
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device filemon' in the kernel config file? or to
> just load it when rebuilding the system?
>
> There is man 4 filemon but nothing there to describe usage as
Is it better to load filemon as kldload filemon, or to
have it set as a device via 'device filemon' in the kernel
config file? or to just load it when rebuilding the system?
There is man 4 filemon but nothing there to describe usage as .ko
or device. System is n271321-9ae91f59c500 on arm64.
On Jul 26, 2024, at 21:20, Mark Millard wrote:
> The original mount was:
>
> mount -onoatime 192.168.1.140:/ /mnt
>
> For reference:
> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> (nfs, noatime)
>
> gdb reports:
>
> Reading symbols from /sbin/umount...
>
The original mount was:
mount -onoatime 192.168.1.140:/ /mnt
For reference:
192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt (nfs,
noatime)
gdb reports:
Reading symbols from /sbin/umount...
Reading symbols from /usr/lib/debug//sbin/umount.debug...
[New LWP 100137]
On Jul 26, 2024, at 16:44, Warner Losh wrote:
> On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote:
>> On Jul 26, 2024, at 07:56, Philip Paeps wrote:
>>
>> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> >> So, it looks like updating the kernel and world on ampere2 and
>> >> enabling
On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote:
> On Jul 26, 2024, at 07:56, Philip Paeps wrote:
>
> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
> >> So, it looks like updating the kernel and world on ampere2 and
> >> enabling builds of main-armv7-default should no longer have
> >>
On Jul 26, 2024, at 07:56, Philip Paeps wrote:
> On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> So, it looks like updating the kernel and world on ampere2 and
>> enabling builds of main-armv7-default should no longer have
>> main-armv7-default hang-up during graphviz installation (or
>>
On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
So, it looks like updating the kernel and world on ampere2 and
enabling builds of main-armv7-default should no longer have
main-armv7-default hang-up during graphviz installation (or
analogous contexts). Hopefully, that means that
On Jul 25, 2024, at 09:48, Mark Millard wrote:
> Michal Meloun has committed a fix in main:
>
> See:
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
>
> that starts with:
>
> From: Michal Meloun
> Date: Thu, 25 Jul 2024 16:25:09 UTC
> The branch main has
Michal Meloun has committed a fix in main:
See:
https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
that starts with:
From: Michal Meloun
Date: Thu, 25 Jul 2024 16:25:09 UTC
The branch main has been updated by mmel:
URL:
On Wed, Jul 24, 2024 at 11:34 AM m...@freebsd.org
wrote:
>
>
> On 24.07.2024 17:47, Konstantin Belousov wrote:
> > On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
> >>
> >>
> >>> On Jul 24, 2024, at 06:50, Konstantin Belousov
> wrote:
> >>>
> >>> On Wed, Jul 24, 2024 at 12:34:57PM
On 24.07.2024 17:47, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
On 24.07.2024 12:24, Konstantin Belousov wrote:
On
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
>
>
> > On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
> >
> > On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
> >>
> >>
> >> On 24.07.2024 12:24, Konstantin Belousov wrote:
> >>> On Tue, Jul 23, 2024 at
> On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
>
> On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>>
>>
>> On 24.07.2024 12:24, Konstantin Belousov wrote:
>>> On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>
>
> On 24.07.2024 12:24, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> > > On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> > > >
> > > > On 23.07.2024 11:36, Konstantin
On 24.07.2024 12:24, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a
On Tue, Jul 23, 2024 at 2:11 PM John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a
On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the July 2024 stabilization
week
T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as
T> main-stabweek-2024-Jul.
Testing at Netflix didn't discover any
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
>>> The good news is that I'm finally able to generate a working/locking
>>> test case. The culprit (at least for me) is if
On Tue, Jul 23, 2024 at 07:46:51PM +0200, Michal Meloun wrote:
>
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> > > The good news is that I'm finally able to generate a working/locking
> > > test case. The culprit (at
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is that I'm finally able to generate a working/locking
test case. The culprit (at least for me) is if "-mcpu" is used when
compiling libthr (e.g. indirectly injected
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> The good news is that I'm finally able to generate a working/locking
> test case. The culprit (at least for me) is if "-mcpu" is used when
> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
> If it is not
1 - 100 of 138514 matches
Mail list logo
