On Jun 28, 2024, at 19:32, Mark Millard wrote:
> Looking at:
>
> https://lists.freebsd.org/archives/freebsd-snapshots/2024-June/000419.html
> ( Date: Fri, 21 Jun 2024 00:42:00 UTC )
>
> and at:
>
> https://lists.freebsd.org/archives/freebsd-snapshots/2024-June/00041
[stable/14's 28 Jun 2024 22:42:13 UTC also has its files missing.]
On Jun 28, 2024, at 20:26, Mark Millard wrote:
> On Jun 28, 2024, at 19:32, Mark Millard wrote:
>
>> Looking at:
>>
>> https://lists.freebsd.org/archives/freebsd-snapshots/2024-June/000419.html
&
ives/freebsd-pkgbase/2024-July/000416.html
pkg with -d for the https context had its debug output
reporting:
* SSL certificate problem: certificate is not yet valid
It happened to be using 204.15.11.66:443 for the https
activity.
===
Mark Millard
marklmi at yahoo.com
On Jul 3, 2024, at 17:47, Philip Paeps wrote:
> On 2024-07-04 01:27:03 (+0800), Mark Millard wrote:
>> Bootstrapping pkg from
>> pkg+https://pkg.FreeBSD.org/FreeBSD:14:aarch64/quarterly, please wait...
>> Certificate verification failed for /CN=pkg.freebsd.org
>> 0020
rts,
apparently thinking of it as a poudriere related issue, see
https://github.com/freebsd/poudriere/issues/1168 ).
(I'm simplifying the discord message history here. But the
general question for 13.4 seems good to explicitly ask.)
===
Mark Millard
marklmi at yahoo.com
i may reject the upgraded zpool
since it does not automatically understand some new features.
See loader.efi(8) and uefi(8) for more details.
END QUOTE
===
Mark Millard
marklmi at yahoo.com
On Sep 9, 2024, at 00:14, Scott Bennett wrote:
> Mark Millard wrote:
>
> Thanks much for this reply. It looks quite interesting.
>
>> Scott Bennett wrote on
>> Date: Mon, 09 Sep 2024 02:13:19 UTC :
>>
>>> a...@disroot.org
. . .
) stop trying to have stable/14 armv6 builds
or:
) get the stable/14 armv6 builds working again
Note: I do not use armv6 builds. I just happened to notice this
when I was looking at https://ci.freebsd.org/tinderbox/ for
other reasons.
===
Mark Millard
marklmi at yahoo.com
On Oct 20, 2024, at 10:41, Mark Millard wrote:
> The build just after the last successful one for stable/14 armv6 looks to be:
>
>
> https://ci.freebsd.org/job/FreeBSD-stable-14-armv6-build/1008/
>
> #1008 (Mon Sep 09 21:44:50 GMT 2024)
> 755e773877e9f3abab3bed2d46d9d8797
[Looks like it is not going to be a great day . . .]
On Oct 20, 2024, at 11:20, Mark Millard wrote:
> On Oct 20, 2024, at 10:41, Mark Millard wrote:
>
>> The build just after the last successful one for stable/14 armv6 looks to be:
>>
>>
>> https://ci.fre
GiByte RAM system did not
reproduce the problem, despite being well below the
512 GiBytes for the files. (32 FreeBSD cpus.)
This context had Optane media via PCIe, not via USB3.
This AMD 7950X3D context is far faster generally.
===
Mark Millard
marklmi at yahoo.com
operational for running
FreeBSD. Its output stops after the mask line for the efi
buffer reporting. (Hyper-V indicates 12% cpu usage. 1 core
of 8 busy?) I was looking for any extra instructions that
I'd not previously found. (I had remembered that eficom
activity had happened --but not all the detail.)
===
Mark Millard
marklmi at yahoo.com
years.
So it looks to me like releng/13.4 possibly should have "Expected
EOL" listed as something like "13.5-RELEASE + 3 months", much like
releng/14.1 lists "14.2-RELEASE + 3 months". In other words: it
probably should mention the next 13.* release number (13.5) in
some way.
===
Mark Millard
marklmi at yahoo.com
: 1536+1590+306+1371+221 == 5024
So it still does not total close to 8192 .
===
Mark Millard
marklmi at yahoo.com
unless I'm missing something
]
On Nov 17, 2024, at 10:50, Mark Millard wrote:
[Not that they could be timed for 14.2-RELEASE at this point.]
Given an update to the bootstrap lang/rust compiler that has
already been fixed, the below fixes why lang/rust has not
built on the official package build se
@@ CFLAGS+=${CANCELPOINTS_CFLAGS}
# Use a more efficient TLS model for libc since we can reasonably assume that
# it will be loaded during program startup.
-.if ${LIBC_ARCH} == "aarch64" || ${LIBC_ARCH} == "amd64" || \
-${LIBC_ARCH} == "i386" || ${LIBC_ARCH} == "riscv" || \
-${LIBC_ARCH:Mpowerpc*} != ""
CFLAGS+= -ftls-model=initial-exec
-.endif
#
# Link with static libcompiler_rt.a.
===
Mark Millard
marklmi at yahoo.com
ver.
On Nov 8, 2024, at 04:49, Michal Meloun wrote:
> On 08.11.2024 4:15, Mark Millard wrote:
>> [I narrowed the artifact kernel range for the change in the type of
>> failure that happens.]
>> On Nov 7, 2024, at 17:43, Mark Millard wrote:
>>> [The change to LLVM
On Dec 2, 2024, at 23:38, Mark Millard wrote:
> Top post of identifying a new context:
>
> Now that stable/14 is based on LLVM19, stable/14 is broken
> like main [so: 15] was, at least in part.
While I've not tested stable/13 for the failure, it also got
an update to use LL
s. a set of the *.txz for
the "same" 14.2-RELEASE are not a full match, apparently with:
) pad byte differences
) Differences in memory layout for .rodata through .eh_frame .
(File paths are recorded that have differing lengths, for
example.)
===
Mark Millard
marklmi at yahoo.com
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 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
has ${VERSION_VERSION} instead of using ${VERSION_MINOR}:
FreeBSD-kmods {
url:
pkg+https://pkg.freebsd.org/${ABI}/kmods_quarterly_${VERSION_VERSION}
signature_type: "fingerprints"
fingerprints: "/usr/share/keys/pkg"
mirror_type: "srv"
enabled: yes
}
===
Mark Millard
marklmi at yahoo.com
[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
have been fixed when I
did a quick test but I reported a different problem.
(Once a "bulk -a" finishes, there is is the time for
distribution of the build to the distribution servers
around the world.)
===
Mark Millard
marklmi at yahoo.com
ba05c2c778
By contrast 142i386 got Status == "done:" with Remaining == 0:
default (a.k.a. latest) 25bf3a3260c7
quarterly 20ba05c2c778
(Same pair as crashed for 142amd64.)
I do not know if there are some logs that could be copied for
reference or not.
===
Mark Millard
marklmi at yahoo.com
lume of support questions.
Getting a notable volume of such notices at some stage after
starting a boot sequence would likely justify sending in a
report about it with notes about the kind of context that
got the issue.
===
Mark Millard
marklmi at yahoo.com
g the likes, of, for example, llvm, including the likes
of 20 -> 21 and such? (More generally: Update some contributed
materials that are not normally security updates but tend to get
updates over time, even if not much else changes part of the
time?)
===
Mark Millard
marklmi at yahoo.com
fallout?port=%2Flibrewolf&maintainer=&env=&category=build%2Frunaway&flavor=
shows as having such failures for www/librewolf:
135i386-default
main-i386-default
142i386-quarterly
135i386-quarterly
134i386-default
134i386-quarterly
Interestingly, 142i386-default is not showing up ther
*.pkg files involved. And there are
hundreds of *.pkg files. So comparisons could be messy to deal with.
Has the technique for this subject area been decided yet? If yes, what is the
intended technique?
===
Mark Millard
marklmi at yahoo.com
On Jul 5, 2025, at 01:23, Konstantin Belousov wrote:
> On Fri, Jul 04, 2025 at 11:01:22PM -0700, Mark Millard wrote:
>> Some package builds are failing on the port-packages build cluster
>> machines that do i386 builds during the following code. The analysis
>> is from repl
On Jul 5, 2025, at 10:08, Mark Millard wrote:
> On Jul 5, 2025, at 01:23, Konstantin Belousov wrote:
>
>> On Fri, Jul 04, 2025 at 11:01:22PM -0700, Mark Millard wrote:
>>> Some package builds are failing on the port-packages build cluster
>>> machines that do i3
en I discovered this.)
===
Mark Millard
marklmi at yahoo.com
Kyle Evans wrote on
Date: Mon, 21 Jul 2025 04:24:11 UTC :
> On 7/20/25 23:02, Mark Millard wrote:
> > Something I ran into (I did not look at older history
> > but older releng/14.* may have the same issue):
> >
> > stable/13/ and releng/13.5/ have (via kevans@
oice between a thing that works for users, or something that *can*
> work for users but comes with a bunch of footguns that they need to avoid,
> I’d pick the former.
>
> David
>
> [1] I’ve noticed on fresh installs, the default shell no longer has working
> persistent history, which is a *big* POLA violation, if people want to
> complain about something.
>
===
Mark Millard
marklmi at yahoo.com
/GENERIC-NODBG-CA72
arm64 aarch64 1300520 1300520
It is a root-on-ZFS context on Optane media in the PCie slot.
I've no clue if this will repeat. I've never gotten
this before.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
On 2021-Nov-21, at 11:26, Mark Millard wrote:
> Starting file system checks:
> /dev/gpt/CA72opt0EFI: 41 files, 242 MiB free (15469 clusters)
> FIXED
> /d x0: 00e43ec8 (blocked_lock + 0)
> x1: 00013efa9f50
> x2: 0090e39a (cam_status_table + 1d132)
>
On 2021-Nov-21, at 11:36, Mark Millard wrote:
> On 2021-Nov-21, at 11:26, Mark Millard wrote:
>
>> Starting file system checks:
>> /dev/gpt/CA72opt0EFI: 41 files, 242 MiB free (15469 clusters)
>> FIXED
>> /d x0: 00e43ec8 (blocked_lock + 0)
. . .
Local branches configured for 'git pull':
mainmerges with remote main
releng/13.0 merges with remote releng/13.0
stable/13 merges with remote stable/13
So I'm not sure if I have anything that is messed up
or not. Nothing looks odd to me, other than the
source code updated to
accurately match some specific commit.
I did not investigate anything beyond the example difference
above.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
ta Notice FreeBSD-EN-21:21.ipfw
FreeBSD Errata Notices
• [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-21:22.linux_futex
FreeBSD Errata Notices
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
S issue is still
present in stable/13 .)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
e:
These experiments are from attmpting to reproduce
hangups seen during pourdiere-devel builds that have
USE_TMPFS=all and builders that are generating
indefinitely growing log files. (This was actually
under main targeting main .)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
64 context, in
case that matters.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
On 2021-Dec-14, at 16:36, Mark Millard wrote:
> I just noticed that main reports that my pools were created
> implicitly matching openzfs-2.1-freebsd (and without
> an explicit compatibility assignment) but, under main, zpool
> import and zpool status for those pools report a n
at would have the final
version?
> On 14.12.2021 19:36, Mark Millard via freebsd-current wrote:
>> I just noticed that main reports that my pools were created
>> implicitly matching openzfs-2.1-freebsd (and without
>> an explicit compatibility assignment) but, under main, zp
On 2021-Dec-14, at 17:35, Alexander Motin wrote:
> On 14.12.2021 20:21, Mark Millard wrote:
>> I presume that because of FreeBSD's releng/13.0 and stable/13 (and
>> releng/13.? futures) that:
>>
>> /usr/share/zfs/compatibility.d/openzfs-2.1-freebsd
>>
>
e-base: 22c4ab6cb015dc99eb82504e5fd957662cded3c3
merge-base: CommitDate: 2021-12-07 19:29:26 +
22c4ab6cb015 (HEAD -> main, freebsd/main, freebsd/HEAD) sys/_bitset.h: Fix
fall-out from commit 5e04571cf3c
n251456 (--first-parent --count for merge-base)
===
Mark Millard
marklmi at yahoo.com
On 2021-Dec-18, at 09:30, Ed Maste wrote:
> On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote:
>>
>> I'm confused, beyond just LGPL claims in the (fairly
>> current) source code, but GPL more generally:
>>
>> # grep -rl "SPDX.*GPL" /usr/main-
101 - 148 of 148 matches
Mail list logo
