On May 6, 2025, at 16:07, Simon J. Gerraty wrote:
> Mark Millard wrote:
>> Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to
>> cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX
>> directly, set some other variab
On May 6, 2025, at 13:14, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>> Of course trying to get too clever can end up being counter productive,
>>> but the tools are there...
>>
>> I still have the addition that we found was needed
>> in my exp
On May 6, 2025, at 11:09, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>>> # cd /usr/src
>>>> # make buildworld-jobs buildkernel-jobs
>>
>> The above used older commands and files from before
>> the following install. META_MODE recorded the us
LANG_FULL:
WITHOUT_CLANG_FULL
Avoid building the ARCMigrate, Rewriter and StaticAnalyzer
components of the Clang C/C++ compiler.
Again, possibly avoiding the RPi4B spending the time
building what is not used.
> Cheers,
>
> Mark Millard escreveu (te
On May 6, 2025, at 08:15, Nuno Teixeira wrote:
> Hello Mark,
>
> Definitely I'm not getting the results I want with WITH_META_MODE using BEs
> since most of the times I end up rebuilding almost everything in new BE.
>
> Should I stop using WITH_META_MODES a go straight
of these. But, in the end, it
involved use of experimental code in
share/mk/src.sys.obj.mk to provide a new
definition to use to build some paths with.
The experiments were an unsupported activity that
produced an unsupported change to allow
configurable enabling of taking risks with not
updating files that possibly should be updated.
===
Mark Millard
marklmi at yahoo.com
On Thu, Apr 24, 2025 at 08:56:44AM +0300, Andriy Gapon wrote:
> On 23/04/2025 21:56, Andriy Gapon wrote:
> > BTW, I've been wondering how illumos avoids the problem even though they
> > do not use any special dlopen flags.
> > It turns out that they link almost all system shared libraries with
> >
On Apr 22, 2025, at 21:29, Mark Millard wrote:
> On Apr 22, 2025, at 20:27, Mark Millard wrote:
>
>> Sulev-Madis Silber wrote
>> on
>> Date: Wed, 23 Apr 2025 02:04:28 UTC :
>>
>>> yes, 2 * 8g partitions on separate disks, so i have 16g swap
>>>
Sulev-Madis Silber wrote on
Date: Wed, 23 Apr 2025 06:55:06 UTC :
>
> On April 23, 2025 8:34:36 AM GMT+03:00, Mark Millard
> wrote:
> >On Apr 22, 2025, at 21:59, Mark Millard wrote:
> >
> >> Sulev-Madis Silber
> >> wrote on
&
On Apr 22, 2025, at 21:59, Mark Millard wrote:
> Sulev-Madis Silber wrote
> on
> Date: Wed, 23 Apr 2025 04:31:41 UTC :
>
> https://forums.freebsd.org/threads/server-freezes-when-using-git-to-update-ports-tree.88651/
>
> That, in turn mentions:
>
> the remote co
that that is why you lost control but
it may be a possibility.)
(main [FreeBSD 15] no longer does such swapping out of any
process kernel stacks and the 2 settings have been removed.)
===
Mark Millard
marklmi at yahoo.com
On Apr 22, 2025, at 20:27, Mark Millard wrote:
> Sulev-Madis Silber wrote
> on
> Date: Wed, 23 Apr 2025 02:04:28 UTC :
>
>> yes, 2 * 8g partitions on separate disks, so i have 16g swap
>>
>> . . .
>>
>>>>> Van: Sulev-Madi
oss various updates.)
3.6 * 4 GiBytes == 14.4 GiBytes SWAP, as an example.
Then RAM+SWAP == 4.6*RAM, so 18.4 GiBytes or so as a
memory space.
===
Mark Millard
marklmi at yahoo.com
On Sat, Apr 19, 2025 at 06:06:59AM -0700, David Wolfskill wrote:
> Running:
> FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445
> main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025
> r...@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
>
> af
at ithread_loop+0x29c
#17 0x0046a2b0 at fork_exit+0x78
Starting Network: lo0 vtnet0.
. . .
===
Mark Millard
marklmi at yahoo.com
On Thu, Apr 17, 2025 at 05:37:13PM +0800, Zhenlei Huang wrote:
>
>
> > On Apr 17, 2025, at 5:17 AM, Mark Millard wrote:
> >
> > Context: An aarch64 PkgBase kernel and world boot under Parallels
> > on macOS (M4 MAX):
> >
> > FreeBSD 15.0-CURRENT main-
[Note: Your Email handling rejects my Emails, probably
because of Yahoo being involved.]
On Apr 16, 2025, at 23:46, Chris wrote:
> On 2025-04-16 22:40, Mark Millard wrote:
>> Chris wrote on
>> Date: Thu, 17 Apr 2025 05:06:35 UTC :
>>> In an attempt to take advantage
ontrollers/imcsmb/smbus_if.h
(Some of the naming and upper-level path structure is
unusual. See what is normal in your context.)
So it appears that sys/modules/i2c/controllers/imcsmb/smbus_if.h
needs to have been built first and that a -I PATH or such needs
to be used to find the file.
===
Mark Millard
marklmi at yahoo.com
On Apr 9, 2025, at 07:38, Mark Millard wrote:
> On Apr 9, 2025, at 06:41, Mark Millard wrote:
>
>> On Apr 9, 2025, at 05:05, Mark Millard wrote:
>>
>>> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>>>
>>>> [Somewhat hand correcte
Mark Linimon wrote on
Date: Wed, 16 Apr 2025 20:23:15 UTC :
> This is a known problem.
>
> All package sets are being rebuilt right now. Due to an unforseen
> circumstance, the first attempt to build them on the updated cluster
> machines failed. It appears that this has s
s the change for avoiding
the extra time.]
On Apr 15, 2025, at 03:17, Mark Millard wrote:
> On Apr 14, 2025, at 16:43, Mark Millard wrote:
>
>> On Apr 11, 2025, at 23:55, Mark Millard wrote:
>>
>>> On Apr 11, 202
On Apr 14, 2025, at 16:43, Mark Millard wrote:
> On Apr 11, 2025, at 23:55, Mark Millard wrote:
>
>> On Apr 11, 2025, at 19:28, Mark Millard wrote:
>>>
>>>> . . .
>>>>
>>> . . .
>>>
>>
>> . . .
>>
>>
On Apr 11, 2025, at 23:55, Mark Millard wrote:
> On Apr 11, 2025, at 19:28, Mark Millard wrote:
>>
>>> . . .
>>>
>> . . .
>>
>
> . . .
>
>>
>>
>> Back to the originally intended content . . .
>>
>>
>>
76 Inspected: 12949 Ignored: 981 Built: 1675 Failed: 229
Skipped: 1299 Fetched: 0 Remaining: 1243
ID TOTAL ORIGIN PKGNAME
PHASE TIME TMPFS CPU% MEM%
[01] 12:02:30 graphics/blender | blender-4.2.0_7
build 11:37:29 5.21 GiB
. . .
===
Mark Millard
marklmi at yahoo.com
On Apr 11, 2025, at 19:28, Mark Millard wrote:
>
>> NOTE on something newly noticed while preparing this
>> (a top post to keep it separate):
>>
> . . .
> NOTE on something newly noticed while preparing this
> (a top post to keep it separate):
>
> In loo
uming
compression technique or some such?
Back to the originally intended content . . .
On Apr 11, 2025, at 14:04, Mark Millard wrote:
>
> On Apr 11, 2025, at 11:39, Mark Millard wrote:
>
>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>
>>> . . .
>
On Apr 11, 2025, at 11:39, Mark Millard wrote:
> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>
>> . . .
>> the problem we have is the
>> performance changes depending on what is happening in parallel on the
>> machines.
>
> In separate list mess
ples of lib-depends
with non-parallel timings.
> I know what is new and what causes the performance penalty, but not
> which part is causing the super extra penalty on the cluster.
Various examples reproduce the timing issues
outside the cluster and without the parallel
builds.
===
Mark Millard
marklmi at yahoo.com
On Apr 10, 2025, at 15:36, Mark Millard wrote:
> On Apr 10, 2025, at 10:14, Mark Millard wrote:
>
>> On Apr 10, 2025, at 09:25, Mark Millard wrote:
>>
>>> The following data are from later in the builder seqeunce.
>>> Here I'm not looki
On Apr 10, 2025, at 10:14, Mark Millard wrote:
> On Apr 10, 2025, at 09:25, Mark Millard wrote:
>
>> The following data are from later in the builder seqeunce.
>> Here I'm not looking at builder activity with large Elapsed
>> multiplication factors for the
On Apr 7, 2025, at 10:15, Mark Millard wrote:
> On Apr 7, 2025, at 09:44, Mark Millard wrote:
>
>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>
>>> On Mon 07 Apr 08:07, Mark Millard wrote:
>>>> . . .
>>>
>>> Listing like t
On Apr 10, 2025, at 09:25, Mark Millard wrote:
> The following data are from later in the builder seqeunce.
> Here I'm not looking at builder activity with large Elapsed
> multiplication factors for the build. It is more of a random
> sampling showing examples of build-depends,
devel) during my
investigations and ended up using a non-debug kernel. So the
times on the left below are from when it queued 26014 and then
inspected 7111, not from the start of the original "bulk -c -a"
on the Apple silicon M4 MAX under Parallels on macOS.
===
Mark Millard
marklmi at yahoo.com
On Apr 9, 2025, at 06:41, Mark Millard wrote:
> On Apr 9, 2025, at 05:05, Mark Millard wrote:
>
>> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>>
>>> [Somewhat hand corrected "OCR" conversion of some console image content.]
>>>
>>> VN
On Apr 9, 2025, at 05:05, Mark Millard wrote:
> On Apr 6, 2025, at 19:29, Mark Millard wrote:
>
>> [Somewhat hand corrected "OCR" conversion of some console image content.]
>>
>> VNASSERT failed: vp->v_holdcnt > 0 not true at
>> /home/pk
On Apr 6, 2025, at 19:29, Mark Millard wrote:
> [Somewhat hand corrected "OCR" conversion of some console image content.]
>
> VNASSERT failed: vp->v_holdcnt > 0 not true at
> /home/pkgbuild/worktrees/main/sys/kern/vfs_subr.c:3391 (vget_finish_ref)
> 0xff
s run
debug kernels vs. non-debug ones (15000??).
Any idea how someone with access could find out what
the issue is during official builds?
===
Mark Millard
marklmi at yahoo.com
On Apr 7, 2025, at 13:15, Mark Millard wrote:
> On Apr 7, 2025, at 10:15, Mark Millard wrote:
>
>> On Apr 7, 2025, at 09:44, Mark Millard wrote:
>>
>>> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>>>
>>>> On Mon 07 Apr 08:07, Mark Mi
On Apr 7, 2025, at 09:44, Mark Millard wrote:
> On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
>
>> On Mon 07 Apr 08:07, Mark Millard wrote:
>>> . . .
>>
>> Listing like this is clearly not any useful, the problem we have is the
>> performance ch
On Apr 7, 2025, at 08:14, Baptiste Daroussin wrote:
> On Mon 07 Apr 08:07, Mark Millard wrote:
>> . . .
>
> Listing like this is clearly not any useful, the problem we have is the
> performance changes depending on what is happening in parallel on the
> machines.
I'
On Apr 6, 2025, at 21:11, Gleb Popov <6year...@gmail.com> wrote:
> On Mon, Apr 7, 2025 at 2:44 AM Mark Millard wrote:
>>
>> So: 2 min 31 sec or so difference for overall somewhat over an
>> hour, i.e., 151 sec or so. That is under 1 sec per package
>> built
the rest of the cores are like:
#0 0x008703b0 in ipi_stop (dummy=)
at /home/pkgbuild/worktrees/main/sys/arm64/arm64/mp_machdep.c:342
#1 0xd2e900866b68 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
===
Mark Millard
marklmi at yahoo.com
s, although the factor may be somewhat
smaller than 2 for a non-debug kernel and world being
used.
===
Mark Millard
marklmi at yahoo.com
[Correcting a dumb mistaken reference.]
On Apr 6, 2025, at 16:43, Mark Millard wrote:
> [For the most part the prior history of my notes is not
> important so they are mostly omitted this time.]
>
> It looks like my notes about official bulk package builds
> taking lon
[I thought of another question.]
On Apr 6, 2025, at 10:53, Mark Millard wrote:
> On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote:
>
>> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit
>> :
>>> [This is an update of earlier notes, now that I've n
On Apr 6, 2025, at 08:39, Baptiste Daroussin wrote:
> Le 5 avril 2025 06:58:12 GMT+02:00, Mark Millard a écrit :
>> [This is an update of earlier notes, now that I've noticed what
>> is different for the contexts that not seeing larger time frames
>> in the Mar-29/A
[Attempting to send to the right FreeBSD list this time.]
On Apr 5, 2025, at 09:02, Mark Millard wrote:
Steve Kargl wrote on
Date: Sat, 05 Apr 2025 01:45:53 UTC :
> Anyone using a Samsung T7 external SSD with FreeBSD current?
>
> If I plug the drive into a USB 2.0 po
, and beefy22 had:
(mix of little vs. large time changes)
Host OSVERSION: 1500035
Jail OSVERSION: 1402000
ampere2's main-arm64 has:
(has large time changes)
Host OSVERSION: 1500035
Jail OSVERSION: 1500035
So: The new Host 1500035 use is not the cause. Nor is Jail 1402000 .
===
Mark Millard
On Apr 4, 2025, at 09:04, Mark Millard wrote:
> Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): 171:50:51
> (Host OSVERSION: 1500019)
>
> On going bulk build: Built 11348 Remaining 23676(HHH:MM:SS): 85:57:28
>
> This suggests possibly more lik
Apr 4, 2025, at 20:25, Mark Millard wrote:
> On Apr 4, 2025, at 09:04, Mark Millard wrote:
>
>
>> Longest ever prior bulk build of main-arm64-default (HHH:MM:SS): 171:50:51
>> (Host OSVERSION: 1500019)
>>
>> On going bulk build: Built 11348 Remaining 23676(
On Fri, Mar 21, 2025 at 02:50:58AM -0700, Gleb Smirnoff wrote:
> On Fri, Mar 21, 2025 at 05:34:16AM -0400, Mark Johnston wrote:
> M> On Fri, Mar 21, 2025 at 01:56:01AM -0700, Gleb Smirnoff wrote:
> M> > On Thu, Mar 20, 2025 at 07:52:19PM +, Bjoern A. Zeeb wrote:
> M
On Fri, Mar 21, 2025 at 01:56:01AM -0700, Gleb Smirnoff wrote:
> On Thu, Mar 20, 2025 at 07:52:19PM +, Bjoern A. Zeeb wrote:
> B> He's hitting a ... somewhere in i915kms.ko (here's the two instances I
> B> have):
> B> REDZONE: Buffer underflow detected. 16 bytes corrupted before
> 0xfe089b
s
for:
Host OSVERSION: 1500019
Jail OSVERSION: 1500023
===
Mark Millard
marklmi at yahoo.com
| 25 +++++
2 files changed, 32 insertions(+)
. . .
===
Mark Millard
marklmi at yahoo.com
On Sun, Mar 23, 2025 at 08:18:14AM -0700, Mark Millard wrote:
> Mark Johnston wrote on
> Date: Sun, 23 Mar 2025 14:12:28 UTC :
>
> > On Sat, Mar 22, 2025 at 12:04:25AM -0700, Gleb Smirnoff wrote:
> > > On Fri, Mar 21, 2025 at 11:13:53AM -0700, David
Mark Johnston wrote on
Date: Sun, 23 Mar 2025 14:12:28 UTC :
> On Sat, Mar 22, 2025 at 12:04:25AM -0700, Gleb Smirnoff wrote:
> > On Fri, Mar 21, 2025 at 11:13:53AM -0700, David Wolfskill wrote:
> > D> . . .
> > . . .
> >
> > Mark, can you please push y
it (using a kernel from a week ago,
> D> main-n275966-d2a55e6a9348).
> D>
> D> I then applied Mark's patch (cleanly; no issues), then
> D> rebuilt/installed the kernel, then rebooted... and stuff seems to work;
> D> I get the xdm login banner Just Fine (and I can ss
On Mar 21, 2025, at 17:43, Konstantin Belousov wrote:
> On Fri, Mar 21, 2025 at 02:30:40PM -0700, Mark Millard wrote:
>> Under:
>>
>> # uname -apKU
>> FreeBSD 7950X3D-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #4
>> main-n275926-a54a240c1b57-dirty: Thu Mar 13 00:44
lude
#include
. . .
(So "libc, -lc" is still referenced for errno in the man page.)
(errno is just used as an example above.)
===
Mark Millard
marklmi at # man -K "libc, -l" | more
[Just a resend with the current and stable lists included.]
On Mar 19, 2025, at 13:49, Mark Millard wrote:
Bjoern A. Zeeb wrote on
Date: Wed, 19 Mar 2025 17:55:17 UTC :
> Hi,
>
> I pushed an update to the iwlwifi firmware port today[1] and with the last
> release of FreeBSD 13 b
ev/md10 10485760 3448
> /dev/md11 10485760 2924
>
> I checked all swap devices with (example):
>
> # dd if=/dev/md10 of=/dev/null bs=8m
>
> all "devices" are fine.
>
> The box has 16 GByte RAM.
>
> What else could I check/do?
===
Mark Millard
marklmi at yahoo.com
longer had a libz.so.6
reference but instead:
libmd.so.7 => /lib/libmd.so.7
Thus, overall, pkg ended up with both:
libmd.so.6 => not found (0)
libmd.so.7 => /lib/libmd.so.7
or, if BACKUP_LIBRARIES=true was in use for PkgBase, there ended
up being 2 libmd.so bindings around, which of itself is also
problem such that they can not both be in use.
pkg-static, of course, does not have this problem. But some
scripting in use references pkg instead of pkg-static and so is
subject to this kind of breakage when system updates happen.
===
Mark Millard
marklmi at yahoo.com
-9ef38a01aea8-dirty: Tue Feb 18 19:42:12 PST 2025
root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76
arm64 aarch64 1500031 1500031
So a personal build, not an official one.
===
Mark Millard
marklmi at yahoo.com
On Mon, Feb 24, 2025 at 03:52:14PM +0800, Zhenlei Huang wrote:
>
>
> > On Feb 24, 2025, at 12:42 PM, Ian FREISLICH wrote:
> >
> > Hi
> >
> > Building a kernel today failed with:
> >
> > -Werror /usr/src/sys/net/toeplitz.c
> > In file included from /usr/src/sys/net/toeplitz.c:29:
> > In file i
On Sat, Feb 22, 2025 at 01:06:02PM +0100, Alexander Leidinger wrote:
> Am 2025-02-21 22:31, schrieb Mark Johnston:
> > On Thu, Feb 20, 2025 at 10:27:28AM +0100, Alexander Leidinger wrote:
> > > Hi,
> > >
> > > I get this backtrace:
> > > ---snip---
&
On Thu, Feb 20, 2025 at 10:27:28AM +0100, Alexander Leidinger wrote:
> Hi,
>
> I get this backtrace:
> ---snip---
> [102] panic: invalid local group size 16 and count 16
> [102] cpuid = 17
> [102] time = 1740041984
> [102] KDB: stack backtrace:
> [102] db_trace_self_wrapper() at db_trace_self_wrap
On Feb 19, 2025, at 09:42, Olivier Cochard-Labbé wrote:
> On Wed, Feb 19, 2025 at 6:05 PM Mark Millard wrote:
>>
>> Another example might be if new VM contexts should be added,
>> such as UTM for macOS. What do kenv smbios.system.product ,
>> sysctl kern.vm_guest
On Feb 19, 2025, at 05:24, Jason Bacon wrote:
>
> On 2/18/25 20:13, Mark Millard wrote:
>> Something I possibly should have done --but did not do was to set:
>> kern.hz=100
>
> I stopped doing this under VirtualBox a few years ago, because it was causing
> clock skew
On Feb 18, 2025, at 16:04, Warner Losh wrote:
> On Tue, Feb 18, 2025 at 4:57 PM Mark Millard wrote:
>> On Feb 18, 2025, at 14:01, Warner Losh wrote:
>> >
>> > On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>> >>
>> >> On Sat, Feb 15,
On Feb 18, 2025, at 14:01, Warner Losh wrote:
>
> On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>>
>> On Sat, Feb 15, 2025 at 10:04 AM Mark Millard wrote:
>>> [This seems likely to not be limited to main [so: 15 as stands].
>>> But I'
nts
/usr/src/sys/arm/conf/GENERIC.hints
/usr/src/sys/riscv/conf/GENERIC.hints
with no aarch64 , armv7 , powerpc64* , powerpcspe , or
riscv64 examples?
===
Mark Millard
marklmi at yahoo.com
[I've now tried my UFS context as well.]
On Feb 12, 2025, at 18:24, Mark Millard wrote:
> I use pkg and poudriere-devel in areas that I've chroot'ed into. (This
> may be unusual and so is noted just in case it turns out to be involved.
> I've been doing that for
usr/obj/DESTDIRs/main-ZNV4-chroot-ports-local/
is a personal world build that was installed there. (The system boots
to an official PkgBase installed world.) So this is not just official
materials involved in the activity, unfortunately.
===
Mark Millard
marklmi at yahoo.com
On Wed, Jan 29, 2025 at 05:16:50PM +0200, Konstantin Belousov wrote:
> On Wed, Jan 29, 2025 at 05:29:35AM +, jenkins-ad...@freebsd.org wrote:
> > FreeBSD-main-amd64-test - Build #25976
> > (4da070ce6c015a994ec4ecf3d31ee94810ea19f1) - Still unstable
> >
> > Build information: https://ci.FreeBS
> kernel module old way, and that whole pipeline is broken if it's loaded at
> boot time or included in the kernel directly. There isn't a nice way to defer
> the firmware load attempt until /after/ rootfs is up.
>
Yep.
===
Mark Millard
marklmi at yahoo.com
On Jan 25, 2025, at 02:24, Mark Millard wrote:
> On Jan 25, 2025, at 02:10, Stefan Esser wrote:
>
>> Am 25.01.25 um 10:54 schrieb Mark Millard:
>>> Unfortunately, for now my reporting is based on my personal build
>>> environment,
>>> not on anoffici
On Jan 25, 2025, at 02:10, Stefan Esser wrote:
> Am 25.01.25 um 10:54 schrieb Mark Millard:
>> Unfortunately, for now my reporting is based on my personal build
>> environment,
>> not on anofficial FreeBSD build.
>> Context doing the building:
>
> Hi Mark,
>
'
.PATH='.
/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG'
37.06 real 108.72 user 5.50 sys
make[1]: stopped making "buildkernel" in /usr/main-src
make: stopped making "buildkernel" in /usr/main-src
Script done, output file is
/usr/obj/BUILDs/main-amd64-dbg-clang/sys-typescripts/typescript-make-amd64-dbg-clang-amd64-host-2025-01-25:01:25:05
===
Mark Millard
marklmi at yahoo.com
o (1-deep or whatever), bare if src.txz was
> also unpacked.
> - add a simple script to download as above.
> - people can install whatever git client they want for further work.
>
> git9 doesn't require any kernel code but on freebsd you'd have to
> use plan9port. It is far simpler but has a different interface.
===
Mark Millard
marklmi at yahoo.com
I realise this takes me
> into uncharted waters, as the testing base for these non-default package
> builds is lower than for the default package builds. I am assuming that risk
> on myself by electing to build my own packages via Poudriere.
>
> Straying off the beaten path can sometimes take you to lonely places. :-)
===
Mark Millard
marklmi at yahoo.com
On Jan 17, 2025, at 10:30, Dennis Clarke wrote:
> On 1/15/25 21:20, Mark Millard wrote:
>> Dennis Clarke wrote on
>> Date: Wed, 15 Jan 2025 15:16:58 UTC :
>>> Over the past month or so I see endless fails in builds for the big
>>> three user facing window
webengine-5.15.18p5_1
x11-wm/xfcebeing blocked by vte3-0.70.2_5
x11/xfce4-goodies being blocked by vte3-0.70.2_5
x11/xfce4-terminal being blocked by vte3-0.70.2_5
But I did not see LXDE being blocked.
Note: So far, 134releng-armv7-default had a very early,
global build failure where nothing built.
But I've no clue if any of this matches your example
build failures.
===
Mark Millard
marklmi at yahoo.com
On Fri, Dec 27, 2024 at 08:30:37PM +0700, Yuri Pankov wrote:
> Getting the following debug notifications:
>
> hdacc0: at cad 0 on hdac0
> hdaa0: at nid 1 on hdacc0
> uma_zalloc_debug: zone "malloc-32" with the following non-sleepable
> locks held:
> exclusive sleep mutex hdac0 (HDA driver mutex)
On Tue, Dec 17, 2024 at 12:19:26PM -0700, Alan Somers wrote:
> According to namei(9), namei should return a shared lock when
> LOCKSHARED is specified. But in my experiments, it always seems to
> return an exclusive lock instead. For example:
>
> $ cd /usr/tests/sys/fs/fusefs
> $ sudo dtrace -i
On Dec 15, 2024, at 20:13, Daniel O'Connor wrote:
> Hi Mark,
Hello Daniel,
>> On 16 Dec 2024, at 10:33, Mark Millard wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash
>> problem
>> someone has been having over more than 2 ye
rnel | grep "\-RELEASE"
@(#)FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
13.4-RELEASE-p2
Because it is a rebuild, the kernel ends up with -p2 instead
of the official -p1 ( from -p2 not updating boot/kernel/kernel
in the official distributions ).
===
Ma
On Dec 14, 2024, at 06:21, Ed Maste wrote:
> On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote:
>>
>> I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz
>> for crude bisecting without needing to do builds.
>>
>> Are you saying that such will
We can separately consider
> compression on the release media images themselves.
>
> Feedback Requested:
>
> Is there support for this idea? Are there objections to pursuing this?
> Are there other factors I should consider, especially compatibility concerns?
===
Mark Millard
marklmi at yahoo.com
ntext of -current on Raspberry Pi2,-3 and -4
> if it matters.
===
Mark Millard
marklmi at yahoo.com
On Nov 28, 2024, at 19:54, Sean C. Farley wrote:
> On Thu, 28 Nov 2024, Mark Millard wrote:
>
>> . . .
>
>>> System setup:
>>> - FreeBSD 14.2-STABLE
>>
>> The context that I investigated --and what was fixed by a commit only
>>
ompressed, 3.39:1 Ratio
> Swap: 32G Total, 32G Free
>
> THR USERNAME THR PRI NICE SIZE RES STATE C TIME CPU
> COMMAND
> 13 root 40 187 ki31 0B 640K RUN 0 486.9H 792.70%
> [idle]
> 103554 root 1 156 i0 786M 632M CPU37 37 0:44 99.82%
> /usr/bi
> 101148 root 1 156 i0 1317M 822M CPU2 2 2:20 99.82%
> /usr/bi
I do not understand what about the above indicates any
problem. May be more context about the prior activity
that lead to the above needs to be reported?
===
Mark Millard
marklmi at yahoo.com
Sean C. Farley wrote on
Date: Thu, 28 Nov 2024 18:16:16 UTC :
> On Mon, 25 Nov 2024, Mark Millard wrote:
>
> > On Nov 25, 2024, at 18:05, Mark Millard wrote:
> >
> >> Top posting going in a different direction that
> >> established a way to con
by appending variable sized
records to a file. There are no seeks or overwrites.": Am
I to interpret that as:
) New file with just sequential writes that are variable
sized?
vs.
) Appending to a pre-existing file? (That would involve
seeking and typically merging new data with old data
from the original last-page-with-data and writing that
update back out.)
===
Mark Millard
marklmi at yahoo.com
s.
-a, --sass Treat input as indented syntax.
-v, --version Display compiled versions.
-h, --help Display this help message.
> On 11/26/24 09:52, Mark Millard wrote:
>> On Nov 26, 2024, at 05:38, Konstantin Belousov wrote:
>>
>>> On Tue, N
On Nov 26, 2024, at 05:38, Konstantin Belousov wrote:
> On Tue, Nov 26, 2024 at 01:58:19PM +0100, Dimitry Andric wrote:
>> On 26 Nov 2024, at 13:32, Dimitry Andric wrote:
>>>
>>> On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote:
>>>>
>>>>
On Nov 26, 2024, at 04:58, Dimitry Andric wrote:
> On 26 Nov 2024, at 13:32, Dimitry Andric wrote:
>>
>> On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote:
>>>
>>> Mark Millard writes:
>>>> From inside a bulk -i where I did a manual m
On Nov 25, 2024, at 22:10, Mark Millard wrote:
> On Nov 25, 2024, at 18:05, Mark Millard wrote:
>
>> Top posting going in a different direction that
>> established a way to control the behavior in my
>> context . . .
>
> For folks new to the discoveries: the co
On Nov 25, 2024, at 18:05, Mark Millard wrote:
> Top posting going in a different direction that
> established a way to control the behavior in my
> context . . .
For folks new to the discoveries: the context here
is poudriere bulk builds, for USE_TMPFS=all vs.
USE_TMPFS=no . My test c
what I looked at before trying the
above . . .
On Nov 25, 2024, at 17:05, Mark Millard wrote:
> On Nov 25, 2024, at 15:21, Mark Millard wrote:
>
>> On Nov 25, 2024, at 14:23, Guido Falsi wrote:
>>
>>> On 25/11/24 23:15, Dimitry Andric wrote:
>>>> On 25
On Nov 25, 2024, at 15:21, Mark Millard wrote:
> On Nov 25, 2024, at 14:23, Guido Falsi wrote:
>
>> On 25/11/24 23:15, Dimitry Andric wrote:
>>> On 25 Nov 2024, at 23:12, Mark Millard wrote:
>>>>
>>>> On Nov 25, 2024, at 13:27, Guido Falsi wro
1 - 100 of 2834 matches
Mail list logo
