In message
, Rick Macklem writes:
> --c0ae7f0635d67be9
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, May 22, 2025 at 10:48=E2=80=AFPM Cy Schubert .com> wrote:
> >
> > Hi,
> >
>
In message <406249f9-b0fc-4e22-9402-683531321...@freebsd.org>, Kristof
Provost
writes:
> On 15 May 2025, at 20:59, Cy Schubert wrote:
> > In message <20250515162552.9209b...@slippy.cwsent.com>, Cy Schubert wri=
> tes:
> >> Over the last couple of days epair(4)
In message <20250515162552.9209b...@slippy.cwsent.com>, Cy Schubert writes:
> Over the last couple of days epair(4) fails to set up when an IP address is
> specified.
>
> bob# service jail onestart test2
> Starting jails: cannot start jail "test2":
> epai
n the base system, not
> port, or the interaction between /usr/sbin/ports.
Likely be61deae0aa2.
>
> As a workaround, I will also mention that the error messages do not appear
> if I directly run /usr/local/sbin/pkg. By aliasing pkg to
> /usr/local/sbin/pkg, the issue dis
FAULT_TO_DROP is the right way to handle your case.
> >
> >>
> >> [No one filters on local loopback nor the link layer, so I've left those
> >> hooks untouched. I suppose one could add them,
> >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LIN
es please.
> I spend 10x more time messing with the kernel Makefile + CONF structure tha=
> n with my changes lol.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
>
>
> ___
s. Professionals I've
worked with do but I'm sure there are many companies where defaults are not
reviewed.
What offers the average end-user the best protection? Also, what avoids a
POLA violation. Balance these two and you will have your answer.
--
Cheers,
Cy Schubert
FreeBSD UNIX:
making his patch. Our
> resolver can't tell us a negative answer versus a timeour. This definitely i
> s
> a problem and I already started investigating it. But definitely out of scop
> e
> of NFS.
>
> --
> Gleb Smirnoff
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
5) option could serve the same purpose it does in linux,
immediately prior to late option handling.
Altering the kernel wait forever is undesirable. This would result in
boot hangs requiring console access to work around the problem. This
would be a PITA and POLA for unattended remote sites.
--
it shouldn't, because the strange behaviour
I had encountered a couple of months ago would never have happened had I
been using meta mode.
Though I can't prove it, my sense is that it does "gratuitously" rebuild
llvm more often than without. I can't prove this scientifically. Just a
seat of the pants "assessment."
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message
, Warner Losh writes:
> --8d472706223dbb34
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Sep 16, 2024, 3:13=E2=80=AFPM Cy Schubert m> wrote:
>
> > In message , void writes:
>
t;
> [void@vm3 ~ ] uname -KU
> 1500023 1500023
> [void@vm3 ~ ] echo 2+2 | bc -l
> 4
Of course the above works because the regression only affects tty users.
bc(1) now ignores EOF on the terminal while the above still works. You can
circumvent this by putting "export BC_TTY_MODE=0
On Sun, 11 Aug 2024 12:29:18 -0400
Dennis Clarke wrote:
> On 8/11/24 09:41, Cy Schubert wrote:
> > In message <54076f5e-cd6d-40d6-b4b7-495cf8e67...@blastwave.org>, Dennis
> > Clarke
> > writes:
> >> On 8/10/24 22:15, Cy Schubert wrote:
> >>&g
In message <54076f5e-cd6d-40d6-b4b7-495cf8e67...@blastwave.org>, Dennis
Clarke
writes:
> On 8/10/24 22:15, Cy Schubert wrote:
> > In message , Mark Millard
> > write
> > s:
>
> >> =E2=80=A2 [2:12 PM]Flox: getting this error in ZFS since recent =
> &
not logging =
> anymore
>
> =E2=80=A2 [2:13 PM]Flox:
> FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0 =
> main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 =
> mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG =
> amd64
Yeah. I'm get
revision.
slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf
fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf
slippy$
To verify that my repo wasn't damaged in any way I cloned a fresh new repo
from git.freebsd.org. I still can't list that revision.
>
> --
> Gleb Smirnoff
>
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
week.
It's currently in use here. I've experienced no problems so far.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
I pushed commits to fix this, the wpa_supplicant*, and hostapd* ports last
night.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message
, Nuno Teixeira writes:
>
> (...)
>
.c.o -MF
>> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o.d -o
>> src/intel/common/libintel_common.a.p/xe_intel_gem.c.o -c
>> ../src/intel/common/xe/intel_gem.c
>> ../src/intel/common/xe/intel_gem.c:72:9: error: duplicate case value '4'
>>72 |case CLOCK_BOOTTIME:
>
Cy Schubert writes:
> In message , Gleb Smirnoff writes:
> > On Tue, Apr 09, 2024 at 07:02:11PM +0200, FreeBSD User wrote:
> > F> The crash is still present on the most recent checked out sources as of
> mi
> > nutes ago.
> > F> I just checked out on HEAD the
In message <20240212193044.e089d...@slippy.cwsent.com>, Cy Schubert writes:
> In message <625e0ea4-9413-45ad-b05c-500833a1d...@freebsd.org>,
> tuexen@freebsd.o
> rg writes:
> > > On Feb 12, 2024, at 10:36, Alexander Leidinger =
> > wrote:
> > >=20
&
sival_ptr =3D 0xfe08a079ee80, sigval_int =3D =
> -1602621824,
> > sigval_ptr =3D 0xfe08a079ee80}, _reason =3D {_fault =3D=
> {
> >_trapno =3D 1489045984}, _timer =3D {_timerid =3D =
> 1489045984,
> >_overrun =3D 17
In message <3f6cf45c-3d34-4da6-9b81-337eb70bb...@karels.net>, Mike Karels
write
s:
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message c
> > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wro
> t
nel the answer. btw,
> > see mntopts(3) for where this code would go.
> These days most mount options are parsed in the kernel via vfs_getopts(),
> but not "atime". It appears that "(no)atime" sets/clears MNT_NOATIME in
> userspace via the getmntopts() function tha
ving home, other will have other distractions)
>
>As Rod suggested I'll have the tools emit a warning when they are run,
>so that those users will become aware.
>https://reviews.freebsd.org/D43585
>https://reviews.freebsd.org/D43586
>
We can also point people to the two new ports.
In message <20240125101308.92e93...@slippy.cwsent.com>, Cy Schubert writes:
> In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman
> wri
> tes:
> > On 25/01/2024 06:50, Cy Schubert wrote:
> > > In message
> > > l.
> >
In message <84c6f3b1-58b3-44f8-aeaf-35f78e059...@quip.cz>, Miroslav Lachman
wri
tes:
> On 25/01/2024 06:50, Cy Schubert wrote:
> > In message c
>
>
> >>
> >> What can they do that gpart can't do?
> >
> > This was quite a while ago, boote
In message <2369865.bDOn7JOVgO@ravel>, Olivier Certner writes:
> --nextPart5823302.8T7jmnknE8
> Content-Transfer-Encoding: 7Bit
> Content-Type: text/plain; charset="UTF-8"; protected-headers="v1"
> From: Olivier Certner
> To: Cy Schubert
> Subj
In message
, Warner Losh writes:
> --b0adc9060fbe7411
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Jan 24, 2024, 10:07=E2=80=AFPM Cy Schubert om>
> wrote:
>
> > In message <20
of a commit that broke loader (or was it a
boot blocks -- I can't remember the exact details anymore) in 12 or
13-CURRENT. The extra tools came in handy as I worked through the mess.
>
> gpart is not the "GPT partition tool". It's the universal swiss army =
> knife
> "GEOM partition tool" for all disk partitioning in any format supported.
>
> Kind regards,
> Patrick=
>
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
>
> > > fdisk was good, but somewhere around the CHS -> LBA transition things
> > > got weird with it, and for really big disks there were reports of issues
> that
> > > I could never encounter when I set out to fix them... Most likely due to
> a
>
the kern.geom.debugflags sysctl foot shooting option so that
it works. (Not that bsdlabel or fdisk worked around the issue). Otherwise
one is left with boot to single user or from alternate media if that
doesn't work.
I do have a patch that circumvents the problem. I haven't looked it i
kernel config, both should have
> been rebuilt as a part of
> the kernel build.)
>
Is anyone by chance seeing autofs in the backtrace too?
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
#x27;s IP to /etc/hosts or if using dhcp, prefix your hostname
to the localhost entry in /etc/hosts like this,
127.0.0.1 my_hostname_whatever_it_is localhost localhost.my.domain
Also make sure rpcbind is running.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
ÀÀÀÀÀÀÀÀÀ
should someone else have noticed this.
I'll play around with this a little over the weekend.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
ÀÀÀÀÀÀÀÀ
On Wed, 8 Nov 2023 15:14:34 +0100
Marek Zarychta wrote:
> W dniu 8.11.2023 o 14:10, Marek Zarychta pisze:
> >
> > W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze:
> >> On Tue, 26 Sep 2023 15:19:46 -0700
> >> Cy Schubert wrote:
> >>
> >>
gt; at /usr/src/sys/kern/kern_intr.c:1218
> #33 ithread_loop (arg=arg@entry=0xf80001c5aea0)
> at /usr/src/sys/kern/kern_intr.c:1306
> #34 0x804adae2 in fork_exit (
> callout=0x804b1120 , arg=0xf80001c5aea0,
> frame=0xfe00ce259f
9934592: Invalid argument
Try reducing your arc.max by an order of 10. This suggests that it's
probably failing in param_set_arc_max() in the val >= arc_all_memory()
comparison..
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.or
obal --add safe.directory /usr/src
>
>
This could be due to e6dc6a27230, which was committed this morning. There
is discussion on the src commits ML (dev-commits-src-all,
dev-commits-src-main) about reverting the change.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
ÀÀÀÀÀÀÀÀÀ
On Tue, 12 Sep 2023 05:29:41 +0100
Graham Perrin wrote:
> On 12/09/2023 00:17, Cy Schubert wrote:
>
> > … poudriere …
>
> > panic: vm_page_dequeue_deferred: page 0xfe000b7e9748 has unexpected
> > queue state
> > …
> <https://bugs.freebsd.org/
k = {lock_object = {
lo_name = 0x80b6167f "explock", lo_flags = 108199936,
lo_data = 0, lo_witness = 0xf8021fd82880}, lk_lock = 1,
lk_exslpfail
ÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀÀ
In message , Mark Millard
write
s:
> On Sep 5, 2023, at 08:58, Cy Schubert wrote:
>
> > In message <20230830204406.24fd...@slippy.cwsent.com>, Cy Schubert =
> writes:
> >> In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes:
> >>>
rt two days ago. The problems have been documented on the
-current list.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
ÀÀÀÀÀÀÀÀ
6508
9-b22aae410bc7: Wed Aug 30 04:38:24 PDT 2023 root@cwsys:/export/obj/opt/
src/
git-src/amd64.amd64/sys/BREAK2 amd64
Almost the same configuration as the other machine.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
In message , Mark Johnston writes:
> On Tue, Aug 29, 2023 at 07:08:35PM -0700, Cy Schubert wrote:
> > Hi
> >
> > Just got the following panic on an and64 machine running poudriere building
>
> > i386 packages.
> >
> > panic: vm_page_dequeue_deferr
000191264a4fbca in ?? ()
Backtrace stopped: Cannot access memory at address 0x19125ca905c8
(kgdb)
*vp looks good.
Dump is available if needed.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
ÀÀÀÀÀÀÀÀ
ils" are used a
>lot, probably with userlands from distributions actually using xattr.
>
>Cheers, Felix
>
If we are to break it to fix a problem, maybe a sysctl to enable/disable then?
--
Cheers,
Cy Schubert
FreeBSD UNIX:Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
Pardon the typos. Small keyboard in use.
memory is laid out on your
system you may get a hang instead.
You need to install thew new kernel and world first. Disable xdm, gdm, any
other *dm, or simply not use startx. From a text console session rebuild
the drm port and reinstall it.
I use poudriere here. My procedure is to updat
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
message dated "Tue, 15 Aug 2023 17:18:37 -0400."
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In message
t /usr/src/sys/fs/devfs/devfs_vnops.c:866
>#15 0x80bca1ce in fo_ioctl (fp=0xf81e9207f0a0, com=3222821401,
> data=, active_cred=, td=) at
> /usr/src/sys/sys/file.h:367
>#16 kern_ioctl (td=td@entry=0xfe0314249020, fd=,
> com=com@entry=3222821401, data=, data@e
s consistent with PR/271945. Reducing -J to 1 or 5:1 circumvents this
panic.
This is certainly a different panic from the one experienced on the
poudriere builder building i386 packages. Both machines run in amd64 mode.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP
I haven't experienced any problems (yet) either.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message
, Kevin Bowling writes:
> The two MFVs on head have improved/fixed stabil
xfe0=
> 422ef8560) at /usr/src/sys/sys/file.h:367
> > #17 kern_ioctl (td=3Dtd@entry=3D0xfe0422ef8560, fd=3D4, com=3Dcom=
> @entry=3D3222821401, data=3D, data@entry=3D0xfffffe02fb827d50 =
> "\017") at /usr/src/sys/kern/sys_generic.c:807
> > #18 0x
Pull request #787. I can look at it.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message , "Naman
Sood
" writes:
> Hi,
>
> wpa_supplicant-devel unfortunately did
On Fri, 30 Jun 2023 10:56:54 -0700
Cy Schubert wrote:
> Can you try wpa_supplicant-devel? It was updated last week. The -devel port
> tracks the latest WPA development.
>
>
Now that I'm back at home, looking at hostap (our upstream w1.fi) commit
logs, there have been
Can you try wpa_supplicant-devel? It was updated last week. The -devel port
tracks the latest WPA development.
--
Cheers,
Cy Schubert
FreeBSD UNIX:Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi
een detected in the following files:
>
>
>Can it be that the error was in file which is deleted now? Or was in snapshot
>which was already destroyed by some automatic script?
>
>Kind regards
>Miroslav Lachman
>
>
Zpool export/import or reboot may fix this.
--
Cheers
imental sysctl. Maybe even have it print "(experimental)" to warn
users that it will hurt.
3. Update the man pages to caution that block_cloning is experimental and
unstable.
It's not enough to have a sysctl without hiding block_cloning completely
from view. Only expose it in zpo
In message <5a47f62d-0e78-4c3e-84c0-45eeb03c7...@yahoo.com>, Mark Millard
write
s:
> On Apr 15, 2023, at 07:36, Cy Schubert =
> wrote:
>
> > In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,=20=
>
> > FreeBSD Us
> > er writes:
> &g
On Sat, 15 Apr 2023 18:07:34 +0200
Florian Smeets wrote:
> On 15.04.23 17:51, FreeBSD User wrote:
> > Am Sat, 15 Apr 2023 07:36:25 -0700
> > Cy Schubert schrieb:
> >>
> >> With an up-to-date tree + pjd@'s "Fix data corruption when cloning embedded
&
In message <20230415175218.777d0...@thor.intern.walstatt.dynvpn.de>,
FreeBSD Us
er writes:
> Am Sat, 15 Apr 2023 07:36:25 -0700
> Cy Schubert schrieb:
>
> > In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
> > FreeBSD Us
> > er wri
. IMO one is generally safe to run poudriere on the
latest ZFS with the additional patch.
My tests of the additional patch concluded that it resolved my last
problems, except for the sent email problem I'm still investigating. I'm
sure there's a simple explanation for it, i.e. the email thread was
corrupted by the EXDEV regression which cannot be fixed by anything, even
reverting to the previous ZFS -- the data in those files will remain
damaged regardless.
I cannot speak to the others who have had poudriere and other issues. I
never had any problems with poudriere on top of the new ZFS.
WRT reverting block_cloning pools to without, your only option is to backup
your pool and recreate it without block_cloning. Then restore your data.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message
, Mateusz Guzik writes:
> On 4/13/23, Cy Schubert wrote:
> > On Thu, 13 Apr 2023 19:54:42 +0900
> > Pawe=C5=82 Jakub Dawidek wrote:
> >
> >> On Apr 13, 2023, at 16:10, Cy Schubert wrote=
> :
> >> >
> >> > =EF=BB=BFIn m
On Thu, 13 Apr 2023 19:54:42 +0900
Paweł Jakub Dawidek wrote:
> On Apr 13, 2023, at 16:10, Cy Schubert wrote:
> >
> > In message <20230413070426.8a54f...@slippy.cwsent.com>, Cy Schubert writes:
> > In message <20230413064252.1e5c1...@slippy.cwsent.com>, Cy
In message <20230413070426.8a54f...@slippy.cwsent.com>, Cy Schubert writes:
> In message <20230413064252.1e5c1...@slippy.cwsent.com>, Cy Schubert writes:
> > In message , Mark Millard
> > write
> > s:
> > > [This just puts my prior reply's material
In message <20230413064252.1e5c1...@slippy.cwsent.com>, Cy Schubert writes:
> In message , Mark Millard
> write
> s:
> > [This just puts my prior reply's material into Cy's
> > adjusted resend of the original. The To/Cc should
> > be coomplete this t
In message , Mark Millard
write
s:
> [This just puts my prior reply's material into Cy's
> adjusted resend of the original. The To/Cc should
> be coomplete this time.]
>
> On Apr 12, 2023, at 22:52, Cy Schubert =
> wrote:
>
> > In message , Mark =
> Millar
ng to
conclusions. I've taken an extremely cautious approach, rolling back
snapshots (as much as possible, i.e. poudriere datasets) when EXDEV
corruption was encountered.
I did not rollback any snapshots in my MH mail directory. Rolling back
snapshots of my MH maildir would result in
In message <20230411142831.db824...@slippy.cwsent.com>, Cy Schubert writes:
> In message <434b83db-f6bb-436f-8aa5-385730d20...@dawidek.net>,
> =?utf-8?Q?Pawe=C
> 5=82_Jakub_Dawidek?= writes:
> >
> >
> > > On Apr 11, 2023, at 11:31, Cy Schubert
In message <434b83db-f6bb-436f-8aa5-385730d20...@dawidek.net>,
=?utf-8?Q?Pawe=C
5=82_Jakub_Dawidek?= writes:
>
>
> > On Apr 11, 2023, at 11:31, Cy Schubert wrote:
> >=20
> > =EF=BB=BFIn message <20230409161436.5412fa6e@thor.intern.walstatt.dynvpn.d=
>
some serious ZFS
> > > problems - I didn't find it right now.
> > >
> > > Thanks in advance,
> > >
> >
> > That's fallout from the new block cloning feature, adding the author
> >
>
> Thanks.
>
> As of this moment, all systems with the newest kernel and the new ZFS option
> enabled, crash -
> the reason is mostly in different ZFS datasets. I guess there is no way back
> once this faulty
> option is enabled?
I've run a test on a scratch pool here, first without block_cloning
enabled, then with. There was no corruption when block_cloning was
disabled. There was corruption when block_cloning was enabled.
I don't know of any way to revert back nor is there any way to fix or
recover the corrupted blocks.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
t would be a good project to have a still in school upcoming developer to
work on.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
here and would be a perfect candidate for migration to ports.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
is in fact meta mode rebuilding because of some makefile change.
Without meta mode I've experienced odd weirdnesses that are fixed through a
subsequent clean build.
I just started using meta mode again this week after a few years hiatus to
see if it addresses the occasional weird behaviour due to something not
being rebuilt when it should have been.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
I. Instead, they really need to have bindings
> automatically generated at build time. That's possible, but it's not
> the default.
This is exactly what happened with DMD D. When 64-bit statfs was introduced
all DMD D compiled programs failed to run and recompiling didn't help. The
DMD upstream failed to understand the problem. Eventually the port had to
be removed.
>
> So what the Rust community really needs is a way to know which symbols
> will be stable across releases, and which might vary. Are you
> suggesting that anything from a non-POSIX header file should be
> considered variable?
>
Rust and every other community.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message <20220829082514.63926...@thor.intern.walstatt.dynvpn.de>,
FreeBSD Us
er writes:
> Am Sun, 28 Aug 2022 06:11:20 -0700
> Cy Schubert schrieb:
>
> > In message <20220828130107.1a76d54a.gre...@freebsd.org>, Michael Gmelin
> > writes:
> > >
>
In message <20220828130107.1a76d54a.gre...@freebsd.org>, Michael Gmelin
writes:
>
>
>
> On Sun, 28 Aug 2022 03:21:24 -0700
> Cy Schubert wrote:
>
> > In message <16b4-76a1-4e46-b7c3-60492d379...@freebsd.org>,
> > Michael Gmelin w
> > rites:
ult in more human
error. I've learned over my long career to rely more on automation than
human beings. Automation [should] never fail and when it does it does
temporarily until the bug is found and fixed. Human beings inconsistently
fail.
If it were an auto-discovery script that created a
In message <202208280842.27s8gdxn055...@nuc.oldach.net>, Helge Oldach
writes:
> Cy Schubert wrote on Sat, 27 Aug 2022 17:26:38 +0200 (CEST):
> > As stated before in this thread, replacing /var/run with tmpfs is not a
> > supported configuration.
>
> Not supported? What
In message <20220827082638.57901a72@slippy>, Cy Schubert writes:
> On Sat, 27 Aug 2022 15:38:44 +0200
> Juraj Lutter wrote:
>
> > > On 27 Aug 2022, at 15:27, Michael Gmelin wrote:
> > >=20
> > >=20
> > > =20
> > >> On 27. Aug 20
e process of changing build and boot processes and the
potential POLA fallout from such a change. A change like this needs to
be architected.
I don't think this is the mailing list to discuss this topic. This
should be discussed on ports@. Not here. Maybe it should be moved there
as this is a ports not a base O/S issue.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
In message <20220725153706.a2bb...@slippy.cwsent.com>, Cy Schubert writes:
> In message , Mark Johnston writes:
> > On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> > > In message <20220724030857.b57f...@slippy.cwsent.com>, Cy Schubert
In message , Mark Johnston writes:
> On Sun, Jul 24, 2022 at 10:07:19AM -0700, Cy Schubert wrote:
> > In message <20220724030857.b57f...@slippy.cwsent.com>, Cy Schubert writes:
> > > In message <20220723185533.9ea7d...@slippy.cwsent.com>, Cy Schubert write
> s:
&
In message <20220724030857.b57f...@slippy.cwsent.com>, Cy Schubert writes:
> In message <20220723185533.9ea7d...@slippy.cwsent.com>, Cy Schubert writes:
> > In message , Mark Johnston writes:
> > > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> >
In message <20220723185533.9ea7d...@slippy.cwsent.com>, Cy Schubert writes:
> In message , Mark Johnston writes:
> > On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > > In message <20220723035223.57cd...@slippy.cwsent.com>, Cy Schubert writes
>
In message , Mark Johnston writes:
> On Sat, Jul 23, 2022 at 07:14:44AM -0700, Cy Schubert wrote:
> > In message <20220723035223.57cd...@slippy.cwsent.com>, Cy Schubert writes:
> > > I'm not sure if this is because my obj tree needs a fresh rebuild and
> > >
In message <20220723035223.57cd...@slippy.cwsent.com>, Cy Schubert writes:
> I'm not sure if this is because my obj tree needs a fresh rebuild and
> reinstall or if this is a legitimate problem. Regardless of the dtrace
> command entered, whether it be a fbt or sdt, the fo
Old DTrace scripts I've used months or even years ago also fail with the
same error. It's not this one probe. All probes result in the pr_gid error.
I'm currently rebuilding my "prod" tree from scratch with the hope that
it's simply something out of sync. But,
ntel
laptop?
If my hunch that this may be caused by a malloc() failure, would it be a
good idea to print a nasty warning when malloc failures in loader occur?
Because silently failing, resulting in weird behaviour is more of a POLA
than a nasty message. If not this, a loader variable to enable verbose
messages might help in debugging these kinds of problems. Again, this
assumes my hunch that it's a malloc() failure is what actually happened.
--
Cheers,
Cy Schubert or
FreeBSD UNIX: Web: http://www.FreeBSD.org
NTP: Web: https://nwtime.org
e**(i*pi)+1=0
.html
> >
> > I don't think 2.2.10 is warranted.
>
> Agreed. The upgrade isn't sufficiently important.
>
> How about 2.2.9.1?
I had a different more sinister thought: Announcing that we've moved from
BSDL to GPLv3 to be more like Linux.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
In message <20220319022405.ga29...@lonesome.com>, Mark Linimon writes:
> Anyone objecting to this, be careful, I might ship a pile of such
> things to you from the depths of the closets :-)
<<=1
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP:
A full clean build resolved the problem. It was likely some incompatible
CTF or possibly some other patch that touched DTrace that left my obj tree
in an inconsistent state.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
/dtrace.sh
dtrace: invalid probe specifier fbt::uma_reclaim:entry { printf("in
uma_reclaim\n"); }: "/usr/lib/dtrace/psinfo.d", line 1: cannot translate
from "struct thread *" to "lwpsinfo_t *"
slippy#
I'm not sure if this is related to 2d5d2a986ce or
mh uses only that port
though it can pipe directly to the sendmail binary when built that way. If
dma doesn't support SMTP submission, we may need to review various port
default options or whether ports even support it.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
-nodbg-clang/usr/main-src/arm64.aarch64/tmp/usr/lib/
> libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so )
>
> Again the tmp/usr/lib/libc++.so path but the content has /lib/libc++.so.1 .
>
> Again it was a META_MODE build.
>
> https://ci.freebsd.org and https://ci.fr
x is rebuild it. That usually
fixes any panics I experience here. Of course, make sure your virtualbox
ports subdirs are fully patched, as it's an opportune time to update it too.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
n all my FreeBSD machines, here and
at $JOB, except for only one, I feel this is perfectly reasonable.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
t;
> create_args_wlan0=3D"country BR regdomain FCC"
> [...]
>
> The last fix still works, although `sleep' isn't necessary.
>
> @@ -29,6 +29,7 @@
> }
> =20
> wpa_poststart() {
> + ifconfig ${ifn} down
> ifconfig ${ifn} up
> }
>
d06d7eb09131 has taken care of this.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
Sorry for the breakage.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
The need of the many outweighs the greed of the few.
In message
, Idwer Vollering writes:
> I can confirm this commit has addressed
rks because command associated
>with process 19463 is not really 'display' and the
>symlink isn't resolved to actually kill 'magick'.
>
>So, just chekcing (2), here. Is this a change in behvior
>for FreeBSD?
>
It's likely your app is rep
1 - 100 of 459 matches
Mail list logo
