Don Lewis truckman at FreeBSD.org wrote on
Sat Jan 20 02:35:40 UTC 2018 :
> The only real problem with the old CPUs is the random segfault problem
> and some other random strangeness, like the lang/ghc build almost always
> failing.
At one time you had written
(
On 2018-Jan-21, at 12:17 PM, Don Lewis wrote:
> On 20 Jan, Mark Millard wrote:
>> Don Lewis truckman at FreeBSD.org wrote on
>> Sat Jan 20 02:35:40 UTC 2018 :
>>
>>> The only real problem with the old CPUs is the random segfault problem
>>> and some other random strangeness, like the lang/ghc
Mike Tancsa mike at sentex.net wrote on:
Wed Jan 17 14:31:50 UTC 2018 :
> On 1/17/2018 8:46 AM, Nimrod Levy wrote:
> > I've been seeing similar issues on Ryzen and asked some questions,
> > here
> > https://lists.freebsd.org/pipermail/freebsd-stable/2017-December/088121.html
> >
> > My previous
Mike Pumford michaelp at bsquare.com wrote on
Wed Jan 24 12:03:04 UTC 2018 :
> I've run into this on modern Intel systems as well. The RAM is sold as
> 2400 but thats actually an overclock profile. If I actually enabled it
> (despite both board and RAM being qualified for that) the system ends
Don Lewis truckman at FreeBSD.org wrote on
Sat Jan 27 08:23:27 UTC 2018 :
> PIDTID COMMTDNAME CPU PRI STATE WCHAN
>
> 90692 100801 python2.7 --1 124 sleep usem
>
> 90692 100824 python2.7 -
Brandon Allbery allbery.b at gmail.com wrote on
Sat Feb 3 21:18:53 UTC 2018 :
> Swapping whole processes out is not really a thing any more. Individual
> pages are paged to/from memory; if a memory page has no backing file, it
> will be allocated a block in swap space as its backing storage.
>
>
OFED in head lead to the following in order for ci.freebsd.org's
FreeBSD-head-amd64-gcc builds to not fail/stop in
all_subdir_lib/ofed :
Author: jhb
Date: Mon Aug 6 23:51:08 2018
New Revision: 337399
URL:
https://svnweb.freebsd.org/changeset/base/337399
Log:
Make the system C11 atomics
Eugene Grosbein eugen at grosbein.net wrote on
Mon Mar 5 12:20:47 UTC 2018 :
> 05.03.2018 19:10, Dimitry Andric wrote:
>
>>> When no boot drive is detected early enough, the kernel goes to the
>>> mountroot prompt. That seems to hold a Giant lock which inhibits
>>> further progress being made.
[I built based on WITHOUT_ZFS= for other reasons. But,
after installing the build, Hyper-V based boots are
working.]
On 2018-Oct-20, at 2:09 AM, Mark Millard wrote:
> On 2018-Oct-20, at 1:39 AM, Mark Millard wrote:
>
>> I attempted to jump from head -r334014 to -r339076
>> on a threadripper
On 2018-Oct-21, at 8:30 PM, Warner Losh wrote:
> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>
> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable
> wrote:
>> [I built based on WITHOUT_ZFS= for other reasons. But,
>> after installing the bu
at 13:58, Mark Millard wrote:
>>>>>
>>>>> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote:
>>>>>>
>>>>>>> On 22 Oct 2018, at 06:30, Warner Losh wrote:
>>>>>>>
>>>>>>> On Sun, Oct 21,
[Building and installing based on WITHOUT_ZFS= allows the
resulting loader to work correctly on the 1950X.]
On 2018-Oct-21, at 12:05 AM, Mark Millard wrote:
> On 2018-Oct-20, at 10:32 PM, Warner Losh wrote:
>
>> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote:
>> [I found what change
;>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
>>>>> freebsd-stable@freebsd.org> wrote:
>>>>>
>>>>>> [
On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote:
>
>> On 22 Oct 2018, at 06:30, Warner Losh wrote:
>>
>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>>
>>>
>>>
>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable
>>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote:
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable <
>> >>>>> freebsd-stabl
[I found what change lead to the 1950X boot crashing
with BTX halted.]
On 2018-Oct-20, at 12:44 PM, Mark Millard wrote:
> [Adding some vintage information for a loader
> that allowed a native boot.]
>
> On 2018-Oct-20, at 4:00 AM, Mark Millard wrote:
>
>> I attempted to jump from head
On 2018-Oct-20, at 10:32 PM, Warner Losh wrote:
> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote:
> [I found what change lead to the 1950X boot crashing
> with BTX halted.]
>
>> On 2018-Oct-20, at 12:44 PM, Mark Millard wrote:
>>
>> > [Adding some vintage information for a loader
>> >
I note that https://pkg.freebsd.org/ does not list FreeBSD:12:aarch64
under the Tier-2 support Package sets but instead on the list with
i386 and amd64. But the same is true for FreeBSD:11:aarch64 .
FreeBSD:12:armv7 is listed in the Tier-2 support package sets list.
The same is true for
Lev Serebryakov lev at FreeBSD.org wrote on
Tue Oct 30 18:37:14 UTC 2018 :
> I have disk with GPT scheme and three partitions:
>
> p1 - freebsd-boot
> p2 - freebsd-ufs
> p3 - freebsd-ufs
>
> pmbr is installed on this disk, and gptboot is installed on p1. Both p2
> and p3 contains valid
On 2018-Oct-20, at 1:39 AM, Mark Millard wrote:
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the boot fails.
> This is both native booting and under Hyper-V,
> same machine and root file system in both cases.
I did my investigation under Hyper-V
I attempted to jump from head -r334014 to -r339076
on a threadripper 1950X board and the native
FreeBSD boot failed very early. (Hyper-V use of
the same media did not have this issue.)
But copying over an older /boot/loader from another
storage device with a FreeBSD head version that has
not been
[Adding some vintage information for a loader
that allowed a native boot.]
On 2018-Oct-20, at 4:00 AM, Mark Millard wrote:
> I attempted to jump from head -r334014 to -r339076
> on a threadripper 1950X board and the native
> FreeBSD boot failed very early. (Hyper-V use of
> the same media did
I attempted to jump from head -r334014 to -r339076
on a threadripper 1950X board and the boot fails.
This is both native booting and under Hyper-V,
same machine and root file system in both cases.
It fails just after the FreeBSD/SMP lines,
reporting "kernel trap 9 with interrupts disabled".
It
On 2020-Jun-29, at 14:12, Donald Wilde wrote:
> On 6/29/20, Mark Millard wrote:
>> [I'm now subscribed so my messages should go through to
>> the list.]
>>
>> On 2020-Jun-29, at 06:17, Donald Wilde wrote:
>>
>>> . . .
>>
>> You report using:
>>
>> # For possibly insufficient swap/paging
[I'm now subscribed so my messages should go through to
the list.]
On 2020-Jun-29, at 06:17, Donald Wilde wrote:
> [adding maintainers of synth and ccache]
>
> On 6/29/20, Mark Millard wrote:
>> Based on "small arm system" context experiments
>> mostly . . .
>>
>> If your console messasges
On 2021-May-5, at 17:01, Yuri Pankov wrote:
> Mark Millard via freebsd-current wrote:
>> Context:
>>
>> # gpart show -pl da0
>> => 40 468862048da0 GPT (224G)
>> 40 532480 da0p1 efiboot0 (260M)
>> 532520 2008 - free - (1.0M)
>> 534528
Context:
# gpart show -pl da0
=> 40 468862048da0 GPT (224G)
40 532480 da0p1 efiboot0 (260M)
532520 2008 - free - (1.0M)
534528 25165824 da0p2 swp12a (12G)
25700352 25165824 da0p4 swp12b (12G)
50866176 417994752 da0p3 zfs0
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL REFER MOUNTPOINT
>>> . . .
>>>
[I warn that I'm a fairly minimal user of NFS
mounts, not knowing all that much. I'm mostly
reporting this in case it ends up as evidence
via eventually matching up with others observing
possibly related oddities.]
I got the following odd sequence (that I've
mixed notes into). It involved a diff
[main test example and main/releng/13 mixed example]
On 2021-May-20, at 20:36, Mark Millard wrote:
> [stable/13 test: example ends up being odder. That might
> allow eliminating some potential alternatives.]
>
> On 2021-May-20, at 19:38, Mark Millard wrote:
>>
>> On 2021-May-20, at 18:09,
[Direct drive connection to machine: no problem.]
On 2021-May-20, at 21:40, Mark Millard wrote:
> [main test example and main/releng/13 mixed example]
>
> On 2021-May-20, at 20:36, Mark Millard wrote:
>
>> [stable/13 test: example ends up being odder. That might
>> allow eliminating some
[stable/13 test: example ends up being odder. That might
allow eliminating some potential alternatives.]
On 2021-May-20, at 19:38, Mark Millard wrote:
>
> On 2021-May-20, at 18:09, Rick Macklem wrote:
>>
>> Oh, one additional thing that I'll dare to top post...
>> r367492 broke the TCP
On 2021-May-20, at 22:19, Rick Macklem wrote:
> Ok, so it isn't related to "soft".
> I am wondering if it is something specific to what
> "diff -r" does?
>
> Could you try:
> # cd /usr/ports
> # ls -R > /tmp/x
> # cd /mnt
> # ls -R > /tmp/y
> # cd /tmp
> # diff -u -p x y
> --> To see if "ls
> On 2021-May-20, at 18:09, Rick Macklem wrote:
>
> Oh, one additional thing that I'll dare to top post...
> r367492 broke the TCP upcalls that the NFS server uses, such
> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
> This has not yet been resolved in "main" etc and
[Looks like the RPi4B genet0 handling is involved.]
On 2021-May-20, at 22:56, Mark Millard wrote:
>
> On 2021-May-20, at 22:19, Rick Macklem wrote:
>
>> Ok, so it isn't related to "soft".
>> I am wondering if it is something specific to what
>> "diff -r" does?
>>
>> Could you try:
>> # cd
Having used bsdinstall to make a USB3 SSD on a RPi4B
(zfs-on-root, GPT parition, RPi4B materials copied
copied to msdos file system), booting gets error notices:
newsyslog: malformed 'at' value:
/var/log/all.log600 7 *@T00 J
newsyslog: malformed 'at' value:
On 2021-May-23, at 00:44, Mark Millard wrote:
> On 2021-May-21, at 17:56, Rick Macklem wrote:
>
>> Mark Millard wrote:
>> [stuff snipped]
>>> Well, why is it that ls -R, find, and diff -r all get file
>>> name problems via genet0 but diff -r gets no problems
>>> comparing the content of files
On 2021-May-21, at 17:56, Rick Macklem wrote:
> Mark Millard wrote:
> [stuff snipped]
>> Well, why is it that ls -R, find, and diff -r all get file
>> name problems via genet0 but diff -r gets no problems
>> comparing the content of files that it does match up (the
>> vast majority)? Any clue
On 2021-May-23, at 01:27, Mark Millard wrote:
> On 2021-May-23, at 00:44, Mark Millard wrote:
>
>> On 2021-May-21, at 17:56, Rick Macklem wrote:
>>
>>> Mark Millard wrote:
>>> [stuff snipped]
Well, why is it that ls -R, find, and diff -r all get file
name problems via genet0 but
On 2021-May-21, at 09:00, Rick Macklem wrote:
> Mark Millard wrote:
>> On 2021-May-20, at 22:19, Rick Macklem wrote:
> [stuff snipped]
>>> ps: I do not think that r367492 could cause this, but it would be
>>>nice if you try a kernel with the r367492 patch reverted.
>>>It is currently
Is stable/13 going to start getting snapshot builds?
(As stands, main , stable/12 , and stable/11 are getting them.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
I did 2 test buildworld's based on:
# ~/fbsd-based-on-what-freebsd.sh
branch: releng/13.0
merge-base: ea31abc261ffc01b6ff5671bffb15cf910a07f4b
merge-base: CommitDate: 2021-04-09 00:14:30 +
ea31abc261ff (HEAD -> releng/13.0, tag: release/13.0.0, freebsd/releng/13.0)
13.0: update to RELEASE
# etcupdate -?
Illegal option -?
usage: etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball]
[-A patterns] [-D destdir] [-I patterns] [-L logfile]
[-M options]
etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options]
On 2021-Apr-25, at 08:14, Graham Perrin wrote:
> On 23/04/2021 08:39, Mark Millard via freebsd-current wrote:
>
>> [3]
>
>
> With regard to mounting ZFS file systems in single user mode
>
> What's currently footnote 3 will probably become footnote 4, please
Using an example to illustrate problems finding artifacts,
the problems not being limited to the example's specifics.
I have historically used https://artifact.ci.freebsd.org/snapshot/
to do build-less approximate bisecting (and other things). Such
use is very messed up since the git-related URL
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G -
[The first buidlworld is still in process. So while waiting . . .]
On 2021-May-4, at 10:31, Mark Millard wrote:
> I probably know why the huge count of differences this time
> unlike the original report . . .
>
> Previously I built based on a checked-in branch as part of
> my experimenting.
On 2021-May-4, at 13:38, Mark Millard wrote:
> [The first buidlworld is still in process. So while waiting . . .]
>
> On 2021-May-4, at 10:31, Mark Millard wrote:
>
>> I probably know why the huge count of differences this time
>> unlike the original report . . .
>>
>> Previously I built
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G
On 2021-May-4, at 20:26, Mark Millard wrote:
> On 2021-May-4, at 13:38, Mark Millard wrote:
>
>> [The first buidlworld is still in process. So while waiting . . .]
>>
>> On 2021-May-4, at 10:31, Mark Millard wrote:
>>
>>> I probably know why the huge count of differences this time
>>>
On 2021-May-3, at 07:47, Ed Maste wrote:
> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
> wrote:
>>
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
On 2021-May-3, at 19:26, Mark Millard wrote:
> On 2021-May-3, at 10:51, Mark Millard wrote:
>
>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>
>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>> wrote:
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
On 2021-May-3, at 10:51, Mark Millard wrote:
> On 2021-May-3, at 07:47, Ed Maste wrote:
>
>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>> wrote:
>>>
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>>>
On 2021-May-3, at 21:27, Mark Millard wrote:
> On 2021-May-3, at 19:26, Mark Millard wrote:
>
>> On 2021-May-3, at 10:51, Mark Millard wrote:
>>
>>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>>
On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
wrote:
>
>
On 2021-May-4, at 08:51, Mark Millard wrote:
> On 2021-May-4, at 06:01, Ed Maste wrote:
>
>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>>
>>> But I'll note that I've built and stalled py37-diffoscope
>>> (new to me). A basic quick test showed that it reports:
>>>
>>> W:
[Just adding readelf -S info since it seems to show more.]
On 2021-May-4, at 10:01, Mark Millard wrote:
> On 2021-May-4, at 08:51, Mark Millard wrote:
>
>> On 2021-May-4, at 06:01, Ed Maste wrote:
>>
>>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
But I'll note that I've
On 2021-May-4, at 06:01, Ed Maste wrote:
> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the
I probably know why the huge count of differences this time
unlike the original report . . .
Previously I built based on a checked-in branch as part of
my experimenting. This time it was in a -dirty form (not
checked in), again as part of my experimental exploration.
WITH_REPRODUCIBLE_BUILD=
I had reported in the reproducable build list messages:
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode
On 2021-Mar-22, at 22:51, Kevin Oberman wrote:
> On Mon, Mar 22, 2021 at 8:19 AM Adrian Chadd wrote:
>> On Mon, 15 Mar 2021 at 14:58, Kevin Oberman wrote:
>>
>> > >
>> > > It appears that the messages are associated with reading
>> > > the disk(s), not directly with writing them, where the
When I looked at https://www.freebsd.org/platforms/ I noticed
that "64-bit little-endian PowerPC" powerpc64le is not listed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
On 2021-Mar-15, at 14:57, Kevin Oberman wrote:
> Responses in-line.
>
> On Sun, Mar 14, 2021 at 3:09 PM Mark Millard wrote:
>
>> On 2021-Mar-14, at 11:09, Kevin Oberman wrote:
>>
>> > . . .
>> >
>> > Seems to only occur on large r/w operations from/to the same disk. "sp
>> > big-file
On 2021-Mar-14, at 11:09, Kevin Oberman wrote:
> . . .
>
> Seems to only occur on large r/w operations from/to the same disk. "sp
> big-file /other/file/on/same/disk" or tar/untar operations on large files.
> Hit this today updating firefox.
>
> I/O starts at >40MB/s. Dropped to about
Warner Losh imp at bsdimp.com wrote on
Fri Feb 26 00:23:15 UTC 2021 :
> Before I get into the blow by blow (which can sound nit-picky, despite my
> best efforts), I would like to apologize. It wasn't completely appreciated
> how clearly the dependencies that the nX number being generated
Christos Chatzaras chris at cretaforce.gr wrote on
Thu Mar 4 21:41:01 UTC 2021 :
> After finding slow filesystem operations with 13.0-BETA2 I did more tests.
>
> All tests done with same hardware (Seagate ST4000NM0245 4TB HDD - 2 disks
> with RAID-1 using gmirror).
>
> Filesystem mounted with
Kevin Oberman rkoberman at gmail.com wrote on
Mon Mar 1 07:11:32 UTC 2021 :
> On Sun, Feb 28, 2021 at 12:49 PM Christos Chatzaras
> wrote:
>
> > Did someone test if this is fixed in BETA4?
> >
>
> Just tried to "make extract" on firefox and I am still seeing transfer
> rates around 1.7M when I
Konstantin Belousov kostikbel at gmail.com wrote on
Fri Mar 5 23:12:13 UTC 2021 :
> On Sat, Mar 06, 2021 at 12:27:55AM +0200, Christos Chatzaras wrote:
. . .
> > Command: /usr/bin/time -l portsnap extract (these tests done with 2
> > different idle servers but with same 4TB HDDs models)
> >
>
On 2021-Feb-23, at 18:08, Chris wrote:
> On 2021-02-23 17:42, Mark Millard wrote:
>> (Warner is only CC'd here.)
>> Warner Losh imp at bsdimp.com wrote on
>> Wed Feb 24 01:04:13 UTC 2021 :
>>> On Tue, Feb 23, 2021, 4:51 PM Chris wrote:
>>> > Given this is a pkg(8) error, I brought it up on
(Warner is only CC'd here.)
Warner Losh imp at bsdimp.com wrote on
Wed Feb 24 01:04:13 UTC 2021 :
> On Tue, Feb 23, 2021, 4:51 PM Chris wrote:
>
> > Given this is a pkg(8) error, I brought it up on ports@
> > but it was suggested I (also?) bring it up here on stable@
> >
> > OK awhile back I
On 2021-Mar-4, at 14:16, Mark Millard wrote:
> Christos Chatzaras chris at cretaforce.gr wrote on
> Thu Mar 4 21:41:01 UTC 2021 :
>
>
>> After finding slow filesystem operations with 13.0-BETA2 I did more tests.
>>
>> All tests done with same hardware (Seagate ST4000NM0245 4TB HDD - 2
Booted RPi4 via micrsd card dd'd from:
FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
I attempted a bsdinstall onto a USB3 SSD. The following
reports what happened.
# bsdinstall
default keymap Select
Hostname OK
ftp mirror OK
Auto (ZFS) OK
Install Select
stripe OK
[*] da0 OK
Last Chance! da0 YES
mike tancsa mike at sentex.net wrote on
Thu Feb 18 10:33:14 UTC 2021 :
> On 2/17/2021 12:10 PM, Warner Losh wrote:
> > On Feb 17, 2021, at 6:05 AM, mike tancsa wrote:
> >> I noticed on a box that I update RELENG_12 via git there are more
> >> recent commits then if I use svnlite to track.
On 2021-Feb-12, at 23:03, Mark Millard wrote:
> Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on
> Sat Feb 13 06:04:52 UTC 2021 :
>
>> The main list we used was:
>>
>> https://lists.freebsd.org/pipermail/svn-src-stable-12/
>>
>> but that appears dead.
>> . . .
>>
On 2021-Feb-18, at 05:33, Mark Millard wrote:
> mike tancsa mike at sentex.net wrote on
> Thu Feb 18 10:33:14 UTC 2021 :
>
>> On 2/17/2021 12:10 PM, Warner Losh wrote:
>>> On Feb 17, 2021, at 6:05 AM, mike tancsa wrote:
I noticed on a box that I update RELENG_12 via git there are
Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on
Sat Feb 13 06:04:52 UTC 2021 :
> The main list we used was:
>
> https://lists.freebsd.org/pipermail/svn-src-stable-12/
>
> but that appears dead.
> . . .
> https://lists.freebsd.org/pipermail/svn-src-release/
>
> suspect also dead.
tech-lists tech-lists at zyxst.net wrote on
Sat Feb 13 04:11:46 UTC 2021 :
> Basically I'm asking "which is the source for truth now".
The official answer for 12 as I understand it: git,
where the commits are initially made before they are
converted into svn. (Thus svn is time delayed.)
But
> As subject, where to get sources for 12-stable upgrade now? Is it still
> svn or is it git?
Probably your choice. But one thing that could
bias towards svn is that the svn information
spans identifying both the svn and the git
material but the git commit does not identify
the svn material. For
FYI: The default bsdinstall result for auto ZFS that I tried
has a separate zroot/usr/src dataset, which zfs mounts at
/usr/src .
UPDATING and such places indicate sequences like:
(think etcupdate where it lists mergemaster and ignore
-F and -Fi)
make buildworld
make
78 matches
Mail list logo
