r you but isn't installed anymore.
--
John Baldwin
ally ossl should replace aesni and
armv8crypto IMO).
Side topic: the ossl(4) manpage in main is stale and needs to be updated
to reflect armv7 and powerpc64 support. I'm not sure yet if it supports
AES-GCM for armv8 as well.
--
John Baldwin
> 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:
&g
2.
The function is
static inline size_t
round_up(size_t size)
{
if (size % _thr_page_size != 0)
size = ((size / _thr_page_size) + 1) *
_thr_page_size;
return size;
}
The body can be condensed to
return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
This is shorter in both lines of code and instruction bytes.
John Carr
hat
> such matters here.
>
> But Michal Meloun's report indicated not using builds
> done on amd64 as well. ("Tegra" models and examples of
> ARMv7-A and of ARMv8-A.)
>
> For John Carr, I do not know if amd64 based builds of
> the world were system
nd `devctl enable ata0`
reproduced the issue:
ata0: at channel 0 on atapci0
This should be fixed now by commit 56b822a17cde5940909633c50623d463191a7852.
Sorry for the breakage.
--
John Baldwin
oving it into kernel space.
- John
signature.asc
Description: PGP signature
ting SMBv2/3.
> Unfortunately I don't know anybody else trying to do this tremendous work.
>
I am working on a from scratch implementation of smbfs. I do not have
any kind of time estimate since it is in my spare time. I chose this
route after spending considerable time looking at Apple and Solaris
implementations and wanting something without all of the legacy 1.0
crap. I do have a very minimal working FUSE version at this point, but
there is much to do, and even more to abide by the various
specifications.
I just thought I'd share in case anyone is interested.
- John
signature.asc
Description: PGP signature
e beginning.
If this is indeed the issue, switching to a -devel GCC port should fix it.
FWIW, the devel/freebsd-gcc* ports have passed this flag to GCC's configure
for a long time (since we made the switch in clang).
--
John Baldwin
Getting a set but not used warning for “td” in sys/kern/kern_condvar.c when
doing a buildkernel for a config file without “options KTRACE”. I failed to
copy the full error message/line numbers but I will reproduce this evening if
needed.
JN
On Wed, Feb 14, 2024 at 06:19:04PM -0800, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted with
st of pkg base materials.
Question: Are any of the changes to be MFC'd at some point?
If I do I will merge a large batch at once, and probably adjust
the order. For example, I'll merge the pci_host_generic changes
before pci_pci changes so that stable branches will be bisectable.
--
John Baldwin
y be 64-bit.
BAR == a range of memory or I/O port addresses decoded by a device,
usually mapped to a register bank, but sometimes mapped to internal
memory (e.g. a framebuffer)
Window == a range of memory or I/O port addresses decoded by a bridge
for which transactions are passed across the bridge to be handled by
a child device.
--
John Baldwin
On 2/14/24 9:57 AM, Mark Millard wrote:
On Feb 14, 2024, at 08:08, John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I was
On 2/14/24 8:42 AM, Warner Losh wrote:
On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I
Feb 12, 2024, at 10:41, Mark Millard wrote:
On Feb 12, 2024, at 09:32, John Baldwin wrote:
On 2/9/24 8:13 PM, Mark Millard wrote:
Summary:
pcib0: mem 0x7d50-0x7d50930f
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size
iated with the faulting instruction pointer (as long as it isn't in
a kernel module), e.g. for gdb you would use 'gdb /boot/kernel/kernel' and then
'l *', e.g. from above: 'l *0x80acb962'
--
John Baldwin
for a child BAR, but I wouldn't expect
rman_manage_region to fail.
Logging the return value from rman_manage_region would be the first step I think
to see which error value it is returning.
Probably I should fix pci_host_generic.c to handle translation properly however.
I can work on a patch for that.
--
John Baldwin
In message , Chris writes:
>I upgraded to an alder lake based machine and installed 14.
>But I can't seem to get the intel graphics loaded (drm-515-kmod).
>It simply freezes at load.
Shot in the dark:
# pkg delete drm-515-kmod && pkg install drm-510-kmod && kldload i915kms
John
groenv...@acm.org
t least a little value in getting it to work because the armv6
code is bit rotting and will go away entirely unless people use it.
John Carr
> On Jan 15, 2024, at 10:59, Mario Marietto wrote:
>
> Hello to everyone.
>
> I'm trying to install FreeBSD 14 natively on my ARM
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
> Please see/test: https://github.com/openzfs/zfs/pull/15732 .
Looks like that has landed in current:
commit f552d7adebb13e24f65276a6c4822bffeeac3993
Merge: 13720136fbf a382e21194c
Author: Martin Matuska
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:
> > > ...
> &g
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
&g
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 p
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.
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 s
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 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 0xf8002c8
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
On 12/10/23 8:43 AM, Dimitry Andric wrote:
On 10 Dec 2023, at 15:11, Herbert J. Skuhra wrote:
On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote:
On arm64 running CURRENT from two weeks ago I updated to
c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge
and built and
On arm64 running CURRENT from two weeks ago I updated to
c711af772782 Bump __FreeBSD_version for llvm 17.0.6 merge
and built and installed from source. make installworld failed:
install: target directory `/usr/include/c++/v1/__tuple/' does not exist
That pathname is a file:
-r--r--r--
On Nov 29, 2023, at 12:21 PM, Manoel Games wrote:
>
> I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the
> FreeBSD-CURRENT kernel, and is it done through pkg? I installed
> FreeBSD-CURRENT without src.
As a new user you should probably run a supported release version,
On 11/15/23 3:06 PM, Bakul Shah wrote:
On Nov 15, 2023, at 7:57 AM, John Baldwin wrote:
On 10/9/23 5:21 PM, Bakul Shah wrote:
Any hints on how to use bhyve's -G option to debug a VM
kernel? I can connect to it from gdb with "target remote :"
& bhyve stops the VM initia
ly published if the CI
is green as that would give us greater confidence of "we believe these
are good" before they are uploaded for publishing.
--
John Baldwin
ript as follows, then parttion editor run at
terminal.
My guess is something to do with commit
23099099196548550461ba427dcf09dcfb01878d,
though I don't see how it could work any differently in this case as the only
change to part_config there was to return if if geom_gettree fails, and if it
fails, provider_for_name would presumably have failed anyway.
--
John Baldwin
pping (basically stepping via
temporary breakpoints) when debugging the kernel this way.
--
John Baldwin
);
```
Seems 14.0 only create one KTLS thread.
IIRC 13.2 create one thread per core.
That part should not be different. There should always be one thread per core.
--
John Baldwin
AM. Note also
that if we did this, we would want to do it for 14.0 as 13.x -> 14 upgrades
are affected in the same way.
--
John Baldwin
No, the conflict markers are not placed in the versions in /etc. However,
etucpdate
does refuse to do a "new" upgrade until you resolve all the conflicts from your
previous upgrade to ensure that conflicted upgrades aren't missed.
--
John Baldwin
I had a problem yesterday and today rebuilding a -CURRENT system from source:
--- magic.mgc ---
./mkmagic magic
magic, 4979: Warning: Current entry does not yet have a description for
adding a MIME type
mkmagic: could not find any valid magic files!
The cause was an sscanf call unexpecte
> On Jul 9, 2023, at 19:59, Konstantin Belousov wrote:
>
> On Sun, Jul 09, 2023 at 11:36:03PM +0000, John F Carr wrote:
>>
>>
>>> On Jul 9, 2023, at 19:25, Konstantin Belousov wrote:
>>>
>>> On Sun, Jul 09, 2023 at 10:41:27PM +00
> On Jul 9, 2023, at 19:25, Konstantin Belousov wrote:
>
> On Sun, Jul 09, 2023 at 10:41:27PM +0000, John F Carr wrote:
>> Kernel and system at a146207d66f320ed239c1059de9df854b66b55b7 plus some
>> irrelevant local changes, four 64 bit ARM processors, make.conf sets
&
Kernel and system at a146207d66f320ed239c1059de9df854b66b55b7 plus some
irrelevant local changes, four 64 bit ARM processors, make.conf sets
CPUTYPE?=cortex-a57.
I typed ^C while /bin/sh was starting a pipeline and my shell got hung in the
middle of fork().
>From the terminal:
# git log --one
On Jul 6, 2023, at 20:42, Mike Karels wrote:
>
>
> Thanks for isolating this. Let me know when you have the bug number.
> I just tested a fix (the compat code drops the reference on the current
> address space an extra time, probably freeing it).
>
> Mike
The bug was introduced in January, 20
> On Jun 25, 2023, at 20:16, Mark Millard wrote:
>
> Using the likes of:
>
> FreeBSD-14.0-CURRENT-arm64-aarch64-ROCK64-20230622-b95d2237af40-263748.img
> and:
> FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20230622-b95d2237af40-263748.img
>
> I have shown the following behavior after setting up
> On Jun 26, 2023, at 04:32, Mark Millard wrote:
>
> On Jun 24, 2023, at 17:25, Mark Millard wrote:
>
>> On Jun 24, 2023, at 14:26, John F Carr wrote:
>>
>>>
>>>> On Jun 24, 2023, at 13:00, Mark Millard wrote:
>>>>
>>
> On Jun 24, 2023, at 4:16 AM, Marcin Cieslak wrote:
>
> I just noticed that I had to remove "device twe"
> from my kernel configuration when rebuilding my -CURRENT today.
>
> Is there any problem with this driver that makes it difficult
> to keep around?
>
> Believe or not, I still rent a mach
> On Jun 24, 2023, at 13:00, Mark Millard wrote:
>
> The running system build is a non-debug build (but
> with symbols not stripped).
>
> The HoneyComb's console log shows:
>
> . . .
> GEOM_STRIPE: Device stripe.IMfBZr destroyed.
> GEOM_NOP: Device md0.nop created.
> g_vfs_done():md0.nop[READ
userspace to always use a dynamically sized mask.
This could perhaps be done in an API-preserving manner by making cpuset_t
an opaque wrapper type in userland and requiring CPU_* to indirect to
functions in libc, etc. That's a fair bit more work however.
--
John Baldwin
those to
a frequency and necessary delay.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
moved enc_xform_des
for example.
--
John Baldwin
00063 and uname
-U also reports 1400063.
FWIW, this was a cross-build, maybe that played a role too.
If you do a NO_CLEAN=yes build, we don't relink binaries just because
crt*.o changed (where the note is stored).
--
John Baldwin
ug in how it manages
saved FPU contexts and reuses a context? If so, I would just suggest
that ZFS switch to using FPU_KERN_NOCTX instead which runs all SSE
type code in a critical section to disable preemption but avoids
having to allocate and manage FPU contexts.
--
John Baldwin
On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote:
> > Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
> > The only argument I've heard from some non-sighted friends about not using
> > FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from
> > the start if I
On Thu, Jul 07, 2022 at 10:11:52PM +0200, Klaus Küchemann wrote:
> > Am 07.07.2022 um 19:32 schrieb Hans Petter Selasky :
> > The only argument I've heard from some non-sighted friends about not using
> > FreeBSD natively is that ooh, MacOSX is so cool. It starts speaking from
> > the start if I
n] MUA
should tag the post appropriately and each MUA be able to convert as
needed between them.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
signature.asc
Description: PGP signature
On 5/4/22 1:38 PM, Steve Kargl wrote:
On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote:
On 5/4/22 12:53 PM, Steve Kargl wrote:
On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
I don't know the entire FreeBSD ecosystem. Do people
use FreeBSD on embedded systems
On 5/4/22 12:53 PM, Steve Kargl wrote:
On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
On 5/2/22 10:37 AM, Steve Kargl wrote:
On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
On Sun, 1 May 2022 at 11:54, Steve Kargl
wrote:
diff --git a/gcc/config/freebsd-spec.h b/gcc
sume libthr style threads, and I think GCC can safely do the
same.
--
John Baldwin
x27;t exists in 13.0 so I couldn't
apply those in every branch.
I build this directly on -current. I'm guessing that these are what
triggered this behaviour:
commit 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1
Author: John Baldwin
Date: Mon Apr 18 16:06:27 2022 -0700
Make -Wunused
My -CURRENT kernel has INVARIANTS (inherited from GENERIC) but not WITNESS:
include GENERIC
ident STRIATUS
nooptions WITNESS
nooptions WITNESS_SKIPSPIN
My kernel build fails:
/usr/home/jfc/freebsd/src/sys/kern/vfs_lookup.c:102:13: error: variable 'line'
set but not used [-Werror,-
byte foo.core instead of a valid core dump.
--
John Baldwin
view not merged yet is https://reviews.freebsd.org/D34147.
It is work to keep it working though and I hadn't worked on it again
until recently.
--
John Baldwin
local mail accounts to forward cron
periodic e-mails just fine. It even supports STARTTLS and SMTP AUTH.
I haven't tried using it for simple local delivery to /var/mail/root.
--
John Baldwin
On 1/1/22 9:00 AM, Ed Maste wrote:
On Fri, 31 Dec 2021 at 18:04, John Baldwin wrote:
However, your point about libcxxrt.so.1 is valid. It needs to also be moved
to /lib if libc++.so.1 is moved to /lib.
libcxxrt.so.1 has always been in /lib.
Oh, I was thrown off by the .so indirection for
On 12/31/21 2:59 PM, Mark Millard wrote:
On 2021-Dec-31, at 14:28, Mark Millard wrote:
On 2021-Dec-30, at 14:04, John Baldwin wrote:
On 12/30/21 1:09 PM, Mark Millard wrote:
On 2021-Dec-30, at 13:05, Mark Millard wrote:
This asks a question in a different direction that my prior
reports
nk
against
both of those libraries when -lc++ is encountered.
I have finally reproduced Cy's build error locally and am testing my fix. If it
works I'll commit it.
--
John Baldwin
On 12/14/21 9:40 AM, Gleb Smirnoff wrote:
On Tue, Dec 14, 2021 at 09:28:07AM -0800, John Baldwin wrote:
J> > AFAIK, today it will always panic only with WITNESS. Without WITNESS it
would
J> > pass through mtx_lock as long as the mutex is not locked.
J>
J> Yes, but the default
On 12/13/21 12:25 PM, Gleb Smirnoff wrote:
On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote:
J> > J> So there are two things here. The root issue is that the devel/apr1
port
J> > J> runs a configure test for TCP_NDELAY being inherited by accepted
sockets.
J>
my laptop had a rather annoying beep whose volume
I couldn't control that I actually prefer to have off normally. On further
reflection, the beep I was looking for for bad input may actually be an
xscreensaver thing for an invalid character to unlock the screen vs a sysbeep
anyway.
--
John Baldwin
ormally changes to the
VOP/VFS are not MFC'd. However, in this case, it might be
ok to do so, since it is unlikely there is an out of source tree
file system with a custom VOP_ALLOCATE() method?
I do not see much wrong with #2, this is what I would do myself.
I also think this is fine.
--
John Baldwin
On 12/13/21 9:35 AM, Gleb Smirnoff wrote:
Hi John,
On Mon, Dec 13, 2021 at 07:45:07AM -0800, John Baldwin wrote:
J> So there are two things here. The root issue is that the devel/apr1 port
J> runs a configure test for TCP_NDELAY being inherited by accepted sockets.
J> This te
r it had most recently drawn and the machine looked hung. (The
fact that that sysbeep is off so I couldn't tell if typing in commands was
doing anything vs emitting errors probably didn't improve trying to diagnose
the hang as "sitting in ddb" initially, though I don't know if DDB itself
emits a beep for invalid commands, etc.)
--
John Baldwin
are used for dry-run and actual run.
(Not looked into the code. Just a thought.)
So the new changes always build a temporary tree (vs trying to build
/var/db/etupdate/current in place). For -n it should be that it just
doesn't change /var/db/etcupdate/current at the end, but if it did the
move anyway that would explain the bug you are seeing. That does indeed
look broken. Please file a PR as a reminder for me to fix it.
--
John Baldwin
say "r" with "File still has conflicts, are you sure?",
so it will only install a file to /etc with those changes if you have
explicitly confirmed you want it.
--
John Baldwin
John-Mark Gurney wrote this message on Thu, Dec 02, 2021 at 15:43 -0800:
> David Chisnall wrote this message on Thu, Dec 02, 2021 at 10:34 +:
> > On 02/12/2021 09:51, Dimitry Andric wrote:
> > > Apparently the "block runtime" is supposed to provide the actual objec
link.
I can't seem to find any docs on clang about how to properly compile
code that uses blocks, so, unless someone points me to docs on how to
compile blocks enable programs, I'll just patch libpru to not use
blocks since it seems like blocks is well supported. I don't want
to f
mand failed with exit code 1 (use -v to see invocation)
What is the correct fix? It seems like atexit.c or the linker should
be fixed, as pructl doesn't use atexit_b at all.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
ESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa:
v2-sparc64-sav.in
Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa:
v2-sparc64-u.out
Only in /usr/obj/DESTDIRs/main-amd64-poud/usr/tests/usr.sbin/sa:
v2-sparc64-usr.in
I'll commit fixes for some of these.
--
John Baldwin
re/i18n/esdb/ISO-8859 (cleandir)
678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir)
I think Jess has a possible fix. This is some regression added in the
build system several months ago.
--
John Baldwin
e it was already there in February, this is not the case. Will try to
reproduce this, but wasn't able up to now.
The congestion control changes just probably exacerbated the bug by
adding a new reference on this module, just as they exposed the bug
with khelp using the wrong SYSINIT subsystem.
--
John Baldwin
stopped in /usr/src/cddl/lib/libavl
My guess is that this was fixed by
git: 9e9c651caceb - main - cddl: fix missing ZFS library dependencies
--
John Baldwin
On Mon, Nov 08, 2021 at 07:08:31PM +, Alexander wrote:
> Hello, I am currently using FreeBSD 14.0-CURRENT and I found a bug that
> triggers a kernel panic. I wanted to make a kernel crash dump to further
> investigate the issue, but after a few tries I still did not manage to do it.
> I started
te, even via power_off/power_on
commands.
Sorry that I don't have a solution for you. The closest that I could
suggest is to try to drop the USB id from the ure driver or switch it's
mode to try the ucdce driver instead. I've seen that it's been
.so.2
No, these lines are for removing the current versions of the
libraries if you do 'make delete-old WITHOUT_DIALOG=yes'.
They weren't bumped previously when I bumped them for ncurses
(probably my fault).
--
John Baldwin
/include/dialog.h:extern DIALOG_VARS dialog_vars;
/usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[];
Then we need to bump libdialog's so version to 10? (I don't
think libdialog has symbol versioning)
--
John Baldwin
177io 0pf+0w
I'm curious if this is a know issue either in Qemu or in FreeBSD for
risc-v or if I'm doing anything wrong here?
It is a known issue with how we brand FreeBSD/riscv binaries. Jess
(cc'd) has a WIP review with a possible fix IIRC.
--
John Baldwin
proposal happen.
Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE!
I think this is fine. I would also be fine with either removing 'toor' from the
default password file or just leaving it as-is for POLA. (I would probably
prefer removing it outright.)
--
John Baldwin
s no 'make
buildworld'
output in /usr/obj (as if you had run 'make cleanworld' up above where you list
'make clean')
--
John Baldwin
t; /tmp/etc.diff
(etcupdate diff doesn't show any diffs.)
Today I've just updated current and etcupdate -p gives:
"Failed to build new tree"
What might be wrong?
You can look in /var/db/etcupdate/log to check for errors.
--
John Baldwin
MPILER=yes' to force your builds
to use the
clang 11 included in stable/13 instead of the host clang 12. You could also
MFC the fixes
from head to use -Wno-error= instead of -Wno-error-.
--
John Baldwin
to update to stock
versions you can use 'etcupdate revert /path/to/file'. Otherwise, you can
use the patch generated by 'etcupdate diff' either as a guide to manually
update files to remove unwanted differences, or as input to patch -R.
--
John Baldwin
On 6/15/21 11:22 AM, Bakul Shah wrote:
On Jun 15, 2021, at 9:03 AM, John Baldwin wrote:
On 6/10/21 8:13 AM, Bakul Shah wrote:
On Jun 10, 2021, at 7:13 AM, Thomas Laus wrote:
The drm-kmod module is the latest from the pkg server. It all
worked this past Monday after the recent drm-kmod
-kmod /usr/local/sys/modules
Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.
This is what I do now as well. I think this is probably the
sanest approach to use on HEAD at least.
--
John Baldwin
On 6/7/21 12:58 PM, Ian Lepore wrote:
On Mon, 2021-06-07 at 13:53 -0600, Warner Losh wrote:
On Mon, Jun 7, 2021 at 12:26 PM John Baldwin wrote:
On 5/20/21 9:37 AM, Michael Gmelin wrote:
Hi,
After a binary update using freebsd-update, all files in /etc
contain
"empty" VCS Id he
elieve we might eventually remove them in the future, but doing so
right now would introduce a lot of churn and the conversion to git
had enough other churn going on.
--
John Baldwin
2.5G device. So, other
non-RealTek devices would be great to test with.
Let me know if you have any issues with the change!
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
you should just create a new dataset
for the database instead of reuse /var's dataset, that way the fixed
record size does not cause problems for the rest of /var...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
On 4/24/21 4:42 AM, Graham Perrin wrote:
On 21/04/2021 18:19, John Baldwin wrote:
On 4/17/21 12:52 PM, Graham Perrin wrote:
2)
<https://reviews.freebsd.org/D28062#change-5KzY5tEtVUor> line 2274
etcupdate -p
I get:
> No previous tree to compare against, a sane comparison is not
1 - 100 of 4747 matches
Mail list logo
