On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>
> > On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
> >
> > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>>
> >>> Hi,
> >>>
> >>>
> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>>
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>>
>>> Hi,
>>>
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> On Nov
On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
> Tomoaki AOKI wrote:
>
> >
> > Or create database (key-value store would be sufficient) storing commit
> > order (like r* of svn) and commit hash.
> > I'm still not certain whether commit order or commit hash should be the
> > "key".
Tomoaki AOKI wrote:
>
> Or create database (key-value store would be sufficient) storing commit
> order (like r* of svn) and commit hash.
> I'm still not certain whether commit order or commit hash should be the
> "key". Possibly store hash as the key fisrt and store assigned MONOTONIC
> order
Brooks Davis wrote:
> The dates are just strings in the commits. There's no central commit
> queue to rewrite the commits with new dates. The project could someday
> implment such a thing, but we deemed anything like that out of scope for
> the first phase of the migration.
>
> I do fine it
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >
> > Hi,
> >
> > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> > >
> > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > > >
> > >
> On Jan 4, 2024, at 15:22, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>>
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>>>
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
Hi,
On Fri, 17 Nov
> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>
>> Hi,
>>
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>>
On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
On Thu, 16 Nov 2023
John,
On 04.01.2024 09:20, John Kennedy wrote:
On Tue, Jan 02, 2024 at 08:02:04PM -0800, John Kennedy wrote:
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
On 01.01.2024 08:59, John Kennedy wrote:
...
My poudriere build did eventually fail as well:
...
On Tue, Jan 02, 2024 at 08:02:04PM -0800, John Kennedy wrote:
> On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
> > On 01.01.2024 08:59, John Kennedy wrote:
> > > ...
> > >My poudriere build did eventually fail as well:
> > > ...
> > > [05:40:24] [01] [00:17:20] Finished
On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>
> > On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
> >
> > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >>>
>
On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>
> Hi,
>
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >
> > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > >
> > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> > >>
> > >> On
On Wed, 3 Jan 2024 23:32:27 +
Brooks Davis wrote:
> On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> > On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> > >
> > > Nothing about dates is centralized in git, but some server side checks
> > > could be implemented on
On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> >
> > Nothing about dates is centralized in git, but some server side checks
> > could be implemented on CommitDate. IMO we should require that
> > CommitDate be >= the previous
Bakul Shah wrote in
<46c8698a-a004-4b5f-9107-6d9fd3685...@iitbombay.org>:
|On Jan 3, 2024, at 11:22 AM, Brooks Davis wrote:
|>
|> Nothing about dates is centralized in git, but some server side checks
|> could be implemented on CommitDate. IMO we should require that
|> CommitDate be >=
On Wed, Jan 03, 2024 at 10:52:04PM +, Jamie Landeg-Jones wrote:
> Brooks Davis wrote:
>
> > Nothing about dates is centralized in git, but some server side checks
> > could be implemented on CommitDate. IMO we should require that
> > CommitDate be >= the previous one and less than "now".
>
On Jan 3, 2024, at 11:22 AM, Brooks Davis wrote:
>
> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate. IMO we should require that
> CommitDate be >= the previous one and less than "now".
Given that git commit objects form a DAG, I
Brooks Davis wrote:
> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate. IMO we should require that
> CommitDate be >= the previous one and less than "now".
Ah, I realised Linux doesn't like centralised dates, because of the
On Wed, Jan 03, 2024 at 07:13:35PM +, Jamie Landeg-Jones wrote:
> https://cgit.freebsd.org/ports/
>
> The latest update to "main" is :
>
> authorYuri Victorovich 2023-01-03 14:49:38 +
> committer Yuri Victorovich 2023-01-03 14:49:38 +
>
> I.e. A year old. Reading the commit
Yuri wrote:
> Hi Jamie,
>
>
> This was a faulty script where 2023 wasn't changed to 2024.
>
> Thanks for the notice.
Ahh, ok, I did think it was probably a bit more than coincidence that it
was exactly 1 year to the day!
Cheers for the quick reply, Jamie
https://cgit.freebsd.org/ports/
The latest update to "main" is :
authorYuri Victorovich 2023-01-03 14:49:38 +
committer Yuri Victorovich 2023-01-03 14:49:38 +
I.e. A year old. Reading the commit message, it does appear to be a wrong
clock, rather than an old message, but whilst
Patrick M. Hausen:
> > Am 02.01.2024 um 13:56 schrieb Jan Bramkamp :
> > IPv6 enabled interfaces need a link-local address for normal
> > operation. Please set the auto-linklocal flag on the bridge and try
> > again.
>
> And remove the link-local address from alc0. A bridge member must not have
>
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
> On 01.01.2024 08:59, John Kennedy wrote:
> > ...
> >My poudriere build did eventually fail as well:
> > ...
> > [05:40:24] [01] [00:17:20] Finished devel/gdb@py39 | gdb-13.2_1: Success
> > [05:40:24] Stopping 2
On 01.01.2024 08:59, John Kennedy wrote:
On Mon, Jan 01, 2024 at 06:43:58AM +0100, Kurt Jaeger wrote:
markj@ pointed me in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
to
https://github.com/openzfs/zfs/pull/15719
So it will probably be fixed sooner or later.
The other ZFS crashes
Hi all,
> Am 02.01.2024 um 13:56 schrieb Jan Bramkamp :
>
> IPv6 enabled interfaces need a link-local address for normal operation.
> Please set the auto-linklocal flag on the bridge and try again.
And remove the link-local address from alc0. A bridge member must not have
any layer 3 addresses
On 02.01.24 00:40, Lexi Winter wrote:
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask
Am 2024-01-02 08:22, schrieb Kurt Jaeger:
Hi!
The sysctl for block cloning is vfs.zfs.bclone_enabled.
To check if a pool has made use of block cloning:
zpool get all poolname | grep bclone
One more thing:
I have two pools on that box, and one of them has some bclone files:
# zpool get
Hi!
> The sysctl for block cloning is vfs.zfs.bclone_enabled.
> To check if a pool has made use of block cloning:
> zpool get all poolname | grep bclone
One more thing:
I have two pools on that box, and one of them has some bclone files:
# zpool get all ref | grep bclone
ref bcloneused
Am 2024-01-02 00:40, schrieb Lexi Winter:
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu
16384
options=680003
inet 127.0.0.1 netmask
Hi!
> Am 2023-12-31 19:34, schrieb Kurt Jaeger:
> > I already have
> >
> > vfs.zfs.dmu_offset_next_sync=0
> >
> > which is supposed to disable block-cloning.
>
> It isn't. This one is supposed to fix an issue which is unrelated to block
> cloning (but can be amplified by block cloning). This
Am 2023-12-31 19:34, schrieb Kurt Jaeger:
I already have
vfs.zfs.dmu_offset_next_sync=0
which is supposed to disable block-cloning.
It isn't. This one is supposed to fix an issue which is unrelated to
block cloning (but can be amplified by block cloning). This issue is
fixed since some
On Mon, Jan 01, 2024 at 02:27:17PM +0100, Kurt Jaeger wrote:
> > On Mon, Jan 01, 2024 at 06:43:58AM +0100, Kurt Jaeger wrote:
> > > markj@ pointed me in
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
> > > to
> > > https://github.com/openzfs/zfs/pull/15719
> > >
> > > So it will
hello,
i'm having an issue with bridge(4) and IPv6, with a configuration which
is essentially identical to a working system running releng/14.0.
ifconfig:
lo0: flags=1008049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
On Mon, Jan 01, 2024 at 08:42:26AM -0800, John Kennedy wrote:
> Applying the two ZFS kernel patches fixes that issue:
commit 09af4bf2c987f6f57804162cef8aeee05575ad1d (zfs: Fix SPA sysctl handlers)
landed too.
root@bsd15:~ # sysctl -a | grep vfs.zfs.zio
On Mon, Jan 01, 2024 at 06:43:58AM +0100, Kurt Jaeger wrote:
> > > I can crash mine with "sysctl -a" as well.
>
> markj@ pointed me in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
> to
> https://github.com/openzfs/zfs/pull/15719
>
> So it will probably be fixed sooner or later.
On Mon, Jan 01, 2024 at 02:27:17PM +0100, Kurt Jaeger wrote:
> Do you have
>vfs.zfs.dmu_offset_next_sync=0
I didn't initially, I do now. Like I said, I haven't been following that one
100%. I know it isn't block-clone per say, so much as some underlying problem
it pokes with a pointy
Hi!
> On Mon, Jan 01, 2024 at 06:43:58AM +0100, Kurt Jaeger wrote:
> > markj@ pointed me in
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
> > to
> > https://github.com/openzfs/zfs/pull/15719
> >
> > So it will probably be fixed sooner or later.
> >
> > The other ZFS crashes I've
On Mon, Jan 01, 2024 at 06:43:58AM +0100, Kurt Jaeger wrote:
> markj@ pointed me in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
> to
> https://github.com/openzfs/zfs/pull/15719
>
> So it will probably be fixed sooner or later.
>
> The other ZFS crashes I've seen are still an
Hi!
> > I can crash mine with "sysctl -a" as well.
markj@ pointed me in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276039
to
https://github.com/openzfs/zfs/pull/15719
So it will probably be fixed sooner or later.
The other ZFS crashes I've seen are still an issue.
--
> I can crash mine with "sysctl -a" as well.
Smaller test, this is sufficient to crash things:
root@bsd15:~ # sysctl vfs.zfs.zio
vfs.zfs.zio.deadman_log_all: 0
vfs.zfs.zio.dva_throttle_enabled: 1
vfs.zfs.ziopanic: sbuf_clear makes no sense on sbuf
On Sun, Dec 31, 2023 at 07:34:45PM +0100, Kurt Jaeger wrote:
> Hi!
>
> Short overview:
> - Had CURRENT system from around September
> - Upgrade on the 23th of December
> - crashes in ZFS, see
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261538
> for details
> - Reinstalled from scratch
Hi!
Short overview:
- Had CURRENT system from around September
- Upgrade on the 23th of December
- crashes in ZFS, see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261538
for details
- Reinstalled from scratch with new SSDs drives from
Dear FreeBSD Community,
The deadline for the next FreeBSD Status Report update is
December, 31st 2023 for work done since the last round of quarterly reports:
October 2023 - December 2023.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during
On Fri, Dec 29, 2023, 6:52 AM wrote:
>
>
> > On Dec 29, 2023, at 14:43, tue...@freebsd.org wrote:
> >
> >> On Dec 29, 2023, at 14:07, Konstantin Belousov
> wrote:
> >>
> >> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
> >>> The problem is really that our kernel headers (those
> On Dec 29, 2023, at 14:43, tue...@freebsd.org wrote:
>
>> On Dec 29, 2023, at 14:07, Konstantin Belousov wrote:
>>
>> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
>>> The problem is really that our kernel headers (those under sys/) require
>>> C99. The only thing that
> On Dec 29, 2023, at 14:07, Konstantin Belousov wrote:
>
> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
>> The problem is really that our kernel headers (those under sys/) require
>> C99. The only thing that
>>
> On Dec 29, 2023, at 13:50, Dimitry Andric wrote:
>
> The problem is really that our kernel headers (those under sys/) require C99.
> The only thing that
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> did was move two static inline functions from
> On Dec 29, 2023, at 13:50, Dimitry Andric wrote:
>
> The problem is really that our kernel headers (those under sys/) require C99.
> The only thing that
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> did was move two static inline functions from
On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
> The problem is really that our kernel headers (those under sys/) require C99.
> The only thing that
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> did was move two static inline functions
The problem is really that our kernel headers (those under sys/) require C99.
The only thing that
https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
did was move two static inline functions from sys/netinet/tcp_var.h to
sys/netinet/tcp.h, and it looks like the
(...)
-ansi == Same as -std=c89
So it seems correct to remove it when -std=c99 is used.
Nuno Teixeira escreveu no dia sexta, 29/12/2023 à(s)
12:03:
>
>
>
> I think we have two options:
>> 1. Build the ports with a C version of at least C99.
>>
>
> - Adding USE_CSTD=c99
> - Removing -ansi:
>
On 29/12/2023 05:46, Christopher Davidson wrote:
Hi FreeBSD mailing list,
I have recently started to look at the CURRENT isos, for installation in
a virtualbox, and while trying to install these images I have received
verification issues with the checksums.
Problem: FreeBSD installer will
I think we have two options:
> 1. Build the ports with a C version of at least C99.
>
- Adding USE_CSTD=c99
- Removing -ansi:
--- configure.orig 2023-12-29 11:54:11 UTC
+++ configure
-CFLAGS="$CFLAGS $(DSO_CFLAGS) -ansi -Wall"
+CFLAGS="$CFLAGS $(DSO_CFLAGS) -Wall"
Fix build.
Notes:
> On Dec 29, 2023, at 10:18, Nuno Teixeira wrote:
>
> Hello all,
>
> From 157 to 158 devel/nspr (dependency of firefox) fails:
>
> ###
> cc -o prmapopt.o -c -fvisibility=hidden-O2 -pipe
> -fstack-protector-strong -fno-strict-aliasing -ansi -Wall -fPIC -UDEBUG
>
Hello all,
>From 157 to 158 devel/nspr (dependency of firefox) fails:
###
cc -o prmapopt.o -c -fvisibility=hidden-O2 -pipe
-fstack-protector-strong -fno-strict-aliasing -ansi -Wall -fPIC -UDEBUG
-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
Hi FreeBSD mailing list,
I have recently started to look at the CURRENT isos, for installation in a
virtualbox, and while trying to install these images I have received
verification issues with the checksums.
Problem: FreeBSD installer will error out of the installer upon verification of
I am still using the same workaround: instead of rv =
efi_global_getenv("ConOut", buf, ); I have rv =
efi_global_getenv("ConIn", buf, );
Happy New Year!
On Mon, May 15, 2023 at 8:41 AM Oleg Lelchuk wrote:
> I got it.
>
> On Mon, May 15, 2023, 8:32 AM Toomas Soome wrote:
>
>>
>>
>> On 15. May
Seems that it was related to PR273661.
I follow this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661#c5
and its now building
Thanks
Santi
On 12/28/23 20:32, Santiago Martinez wrote:
Hi David,
- I'm running 14.0R-P3
- Last commit:
5f71f9636efa25f6de1a832202bae7c78ad013aa
Hi David,
- I'm running 14.0R-P3
- Last commit:
5f71f9636efa25f6de1a832202bae7c78ad013aa (HEAD -> main,
origin/main, origin/HEAD)
Author: rilysh
Date: Thu Dec 28 02:34:32 2023 -0500
- Just a clean build, no options on command line or src.conf/make
- Kernel builds without a
On Thu, Dec 28, 2023 at 04:05:49PM +0100, Santiago Martinez wrote:
> Hi Everyone, I'm having issues building world from current (just now).
>
> Same header missing on multiple parts.
>
> Best regards.
>
> Santiago
>
It might be useful to know:
* What you are running at the time;
* what
Hi Everyone, I'm having issues building world from current (just now).
Same header missing on multiple parts.
Best regards.
Santiago
"""
In file included from
/usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13:
In file included from
On Wed, Dec 27, 2023, 2:24 PM Juraj Lutter wrote:
>
>
> On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov wrote:
>
> Hello,
>
> I updated my tree to revision 3334a537ed38, made buildworld and kernel as
> usual.
> Booting with new kernel leads to keyboard not working at system login
> prompt and
On Wed, Dec 27, 2023 at 11:44:37PM +0300, Ruslan Makhmatkhanov wrote:
>Hello,
>I updated my tree to revision 3334a537ed38, made buildworld and kernel
>as usual.
>
>Booting with new kernel leads to keyboard not working at system login
>prompt and the message "kernel: psm:
> On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov wrote:
>
> Hello,
>
> I updated my tree to revision 3334a537ed38, made buildworld and kernel as
> usual.
> Booting with new kernel leads to keyboard not working at system login prompt
> and the message "kernel: psm: keyboard controller
Hello, I updated my tree to revision 3334a537ed38, made buildworld and kernel as usual.Booting with new kernel leads to keyboard not working at system login prompt and the message "kernel: psm: keyboard controller failed" in /var/log/messages. Reverting to boot the old kernel
Hi Glen,
Am Mon, Dec 25, 2023 at 06:01:36PM +0300 schrieb Gleb Popov:
> On Mon, Dec 25, 2023 at 5:38 PM Robert Clausecker wrote:
> >
> > Greetings!
> >
> > I am happy to announce that the FreeBSD Foudation sponsored amd64 libc
> > SIMD enhancement work has landed in CURRENT following extensive
On Mon, Dec 25, 2023 at 5:38 PM Robert Clausecker wrote:
>
> Greetings!
>
> I am happy to announce that the FreeBSD Foudation sponsored amd64 libc
> SIMD enhancement work has landed in CURRENT following extensive testing.
>
> Big thanks to all those who assisted in testing and reviewing the
>
Greetings!
I am happy to announce that the FreeBSD Foudation sponsored amd64 libc
SIMD enhancement work has landed in CURRENT following extensive testing.
Big thanks to all those who assisted in testing and reviewing the
changes, especially to mjg@ and kib@.
If there are any problems resulting
On 25 Dec 2023, at 2:12, Xin Li wrote:
> On 2023-12-23 14:17, Mike Karels wrote:
>> On 23 Dec 2023, at 15:23, Craig Leres wrote:
>>
>>> On 12/23/23 06:52, Konstantin Belousov wrote:
This is strange change at best. I have no opinion about the disabling
of compression of the rotated logs
On 2023-12-23 14:17, Mike Karels wrote:
On 23 Dec 2023, at 15:23, Craig Leres wrote:
On 12/23/23 06:52, Konstantin Belousov wrote:
This is strange change at best. I have no opinion about the disabling
of compression of the rotated logs by default, but we already have knobs
to do that.
On 2023-12-24 10:03, Rodney W. Grimes wrote:
On 2023-12-23 06:52, Konstantin Belousov wrote:
On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
> On Dec 24, 2023, at 19:31, Justin Hibbits wrote:
>
> Hi Michael,
>
> The GENERIC config is for 32-bit powerpc, GENERIC64 is what you want
> for 64-bit config.
Hi Justin,
thanks a lot! That was the problem.
Best regards
Michael
>
> - Justin
>
> On Sun, 24 Dec 2023 12:18:55 +0100
>
Hi Michael,
The GENERIC config is for 32-bit powerpc, GENERIC64 is what you want
for 64-bit config.
- Justin
On Sun, 24 Dec 2023 12:18:55 +0100
tue...@freebsd.org wrote:
> Dear all,
>
> I just tried to build world and kernel on a 64-bit PPC system.
>
> make -j 32 buildworld
>
> ran without
> On 2023-12-23 10:17, Ceri Davies wrote:
> > I really don?t like the idea of adding flags that make the program ignore a
> > config file. I also think this is premature until ZFS installs are default
> > on all architectures.
> >
> > However, if you must (and I see you have) change this,
> On 2023-12-23 06:52, Konstantin Belousov wrote:
> > On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
> >> Hi,
> >>
> >> Inspired by D42961, I propose that we move forward with disabling the
> >> compression by default in newsyslog, as implemented in
> >> https://reviews.freebsd.org/D43169
Xin Li wrote:
> Inspired by D42961, I propose that we move forward with disabling the
> compression by default in newsyslog, as implemented in
> https://reviews.freebsd.org/D43169
I like the possibility to entirely disable compression on log files, or
to select a specific compression algorithm,
On 24.12.2023 15:47, tue...@freebsd.org wrote:
On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote:
On 24.12.2023 14:18, tue...@freebsd.org wrote:
Dear all,
I just tried to build world and kernel on a 64-bit PPC system.
make -j 32 buildworld
ran without problems.
However
make kernel
> On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote:
>
> On 24.12.2023 14:18, tue...@freebsd.org wrote:
>> Dear all,
>> I just tried to build world and kernel on a 64-bit PPC system.
>> make -j 32 buildworld
>> ran without problems.
>> However
>> make kernel KERNCONF=GENERIC
>> breaks with
>>
On 24.12.2023 14:18, tue...@freebsd.org wrote:
Dear all,
I just tried to build world and kernel on a 64-bit PPC system.
make -j 32 buildworld
ran without problems.
However
make kernel KERNCONF=GENERIC
breaks with
..
--- all_subdir_accf_data ---
--- accf_data.kld ---
ld -m elf32ppc_fbsd
Dear all,
I just tried to build world and kernel on a 64-bit PPC system.
make -j 32 buildworld
ran without problems.
However
make kernel KERNCONF=GENERIC
breaks with
..
--- all_subdir_accf_data ---
--- accf_data.kld ---
ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize -r
On Sat, 23 Dec 2023 15:14:20 -0800
Xin Li wrote:
> On 2023-12-23 07:09, Enji Cooper wrote:
> > This impacts embedded systems or jails which use UFS as the default
> > /var/log backed device. There are quite a few larger consumers of
> > FreeBSD out there that still use UFS instead of ZFS.
>
> I
On 23 December 2023 09:18:23 EET, Xin Li wrote:
>Hi,
>
>Inspired by D42961, I propose that we move forward with disabling the
>compression by default in newsyslog, as implemented in
>https://reviews.freebsd.org/D43169
>
>Historically, newsyslog has compressed rotated log files to save disk
Dear FreeBSD Community,
The deadline for the next FreeBSD Status Report update is
December, 31st 2023 for work done since the last round of quarterly reports:
October 2023 - December 2023.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during
On 2023-12-23 07:09, Enji Cooper wrote:
This impacts embedded systems or jails which use UFS as the default
/var/log backed device. There are quite a few larger consumers of
FreeBSD out there that still use UFS instead of ZFS.
I appreciate your feedback!
Thank you for pointing out the
On 2023-12-23 10:17, Ceri Davies wrote:
I really don’t like the idea of adding flags that make the program ignore a
config file. I also think this is premature until ZFS installs are default on
all architectures.
However, if you must (and I see you have) change this, please don’t call the
On 2023-12-23 13:08, Steve Kargl wrote:
On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote:
I appreciate your perspective on this issue. However, I believe there are
additional benefits to modifying the newsyslog code (which is already done
in commit 906748d208d3, by the way) beyond what
On 23 Dec 2023, at 15:23, Craig Leres wrote:
> On 12/23/23 06:52, Konstantin Belousov wrote:
>> This is strange change at best. I have no opinion about the disabling
>> of compression of the rotated logs by default, but we already have knobs
>> to do that. Adding a knob that disables (or
On 12/23/23 06:52, Konstantin Belousov wrote:
This is strange change at best. I have no opinion about the disabling
of compression of the rotated logs by default, but we already have knobs
to do that. Adding a knob that disables (or enables) other knobs to work
is weird.
I totally agree.
On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote:
>
> I appreciate your perspective on this issue. However, I believe there are
> additional benefits to modifying the newsyslog code (which is already done
> in commit 906748d208d3, by the way) beyond what can be achieved by simply
>
On 2023-12-23 06:52, Konstantin Belousov wrote:
On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169
Historically, newsyslog
On 2023-12-23 00:51, Miroslav Lachman wrote:
On 23/12/2023 08:18, Xin Li wrote:
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169
Historically, newsyslog has compressed rotated
> On 23. Dec 2023, at 16:10, Enji Cooper wrote:
>
>
>> On Dec 22, 2023, at 23:18, Xin Li wrote:
>>
>> Hi,
>>
>> Inspired by D42961, I propose that we move forward with disabling the
>> compression by default in newsyslog, as implemented in
>> https://reviews.freebsd.org/D43169
>>
>>
> On Dec 22, 2023, at 23:18, Xin Li wrote:
>
> Hi,
>
> Inspired by D42961, I propose that we move forward with disabling the
> compression by default in newsyslog, as implemented in
> https://reviews.freebsd.org/D43169
>
> Historically, newsyslog has compressed rotated log files to save
On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
> Hi,
>
> Inspired by D42961, I propose that we move forward with disabling the
> compression by default in newsyslog, as implemented in
> https://reviews.freebsd.org/D43169
>
> Historically, newsyslog has compressed rotated log files to
W dniu 23.12.2023 o 09:51, Miroslav Lachman pisze:
On 23/12/2023 08:18, Xin Li wrote:
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169
Historically, newsyslog has compressed
On 23/12/2023 08:18, Xin Li wrote:
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169
Historically, newsyslog has compressed rotated log files to save disk
space. This approach
Xin Li wrote on 2023-12-22 at 23:18:23:
> Inspired by D42961, I propose that we move forward with disabling the
> compression by default in newsyslog, as implemented in
> https://reviews.freebsd.org/D43169
[...]
> Therefore I would propose that we change the default compression setting
> to
Hi,
Inspired by D42961, I propose that we move forward with disabling the
compression by default in newsyslog, as implemented in
https://reviews.freebsd.org/D43169
Historically, newsyslog has compressed rotated log files to save disk
space. This approach was valuable in the early days where
On Fri, 22 Dec 2023 12:17:15 -0700
Warner Losh wrote:
> On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome wrote:
>
> >
> >
> > > On 22. Dec 2023, at 11:09, Mark Millard wrote:
> > >
> > > Tomoaki AOKI wrote on
> > > Date: Thu, 21 Dec 2023 23:21:00 UTC :
> > >
> > >> On Thu, 21 Dec 2023 14:22:14
On Dec 22, 2023, at 13:49, Konstantin Belousov wrote:
> On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote:
>> Yes. I'd prefer to make this more parameterized, maybe with sanity checks.
>>
>> That is, there'd be a tool that would do the right thing, based on what you
>> tell it to do.
701 - 800 of 138228 matches
Mail list logo
