Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On Dec 7, 2023, at 01:19, Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: >> >> man arch reports: >> >> QUOTE >>Some machines support more than one FreeBSD ABI. Typically these are >>64-bit machines, where the “native” LP64 execution environment is >>

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On Thu, Dec 7, 2023, 2:19 AM Dimitry Andric wrote: > On 7 Dec 2023, at 05:31, Mark Millard wrote: > > > > man arch reports: > > > > QUOTE > > Some machines support more than one FreeBSD ABI. Typically these are > > 64-bit machines, where the “native” LP64 execution environment is > >

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

aarch64 will support execution of armv6 or armv7 binaries if the CPU > implements AArch32 execution state, however older armv4 and armv5 > binaries aren't supported. > END QUOTE > > (I take "armv6 or armv7 binaries" as what was built targeting a FreeBSD > architectu

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On 7 Dec 2023, at 05:31, Mark Millard wrote: > > man arch reports: > > QUOTE > Some machines support more than one FreeBSD ABI. Typically these are > 64-bit machines, where the “native” LP64 execution environment is > accompanied by the “legacy” ILP32 environment, which was the

aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

binaries aren't supported. END QUOTE (I take "armv6 or armv7 binaries" as what was built targeting a FreeBSD architecture triple for one of those. FreeBSD keeps them distinct.) However, the armv6 part of that is wrong: The infrastructure supports only one 32-bit alternative for a gi

Re: What is rc.d/opensm?

24.11.23 12:20, Alexander Leidinger: Hi, for my work on service jails (https://reviews.freebsd.org/D40370) I try to find out what opensm is. On my amd64 system I don't have a man page nor the binary (and man.freebsd.org doesn't know either about opensm). Bye, Alexander. See man /usr/src

What is rc.d/opensm?

Hi, for my work on service jails (https://reviews.freebsd.org/D40370) I try to find out what opensm is. On my amd64 system I don't have a man page nor the binary (and man.freebsd.org doesn't know either about opensm). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP

Re: what do I do when git cherry-pick works, but results are bogus?

On Wed, May 17, 2023, at 9:44 AM, Rick Macklem wrote: > So, the subject line basically says it. > I do a git cherry-pick to MFC. It works, but the resultant file(s) are not > correct. What do I do to fix this? > (If the merge fails, then it's easy, but there doesn't seem to

Re: what do I do when git cherry-pick works, but results are bogus?

On Wed, 17 May 2023, 17:44 Rick Macklem, wrote: > So, the subject line basically says it. > I do a git cherry-pick to MFC. It works, but the resultant file(s) are not > correct. What do I do to fix this? > (If the merge fails, then it's easy, but there doesn't seem to be an option

Re: what do I do when git cherry-pick works, but results are bogus?

On Wed, May 17, 2023 at 9:44 AM Rick Macklem wrote: > > So, the subject line basically says it. > I do a git cherry-pick to MFC. It works, but the resultant file(s) are not > correct. What do I do to fix this? > (If the merge fails, then it's easy, but there doesn't seem

what do I do when git cherry-pick works, but results are bogus?

So, the subject line basically says it. I do a git cherry-pick to MFC. It works, but the resultant file(s) are not correct. What do I do to fix this? (If the merge fails, then it's easy, but there doesn't seem to be an option on cherry-pick that forces it into "merge failed", so you ca

Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]

Mark Millard writes: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >> > ... >> > There is no feasible way we are going to make the branch point of >> > stable/14 in time, with that scheduled for May 12, 2023

Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]

On May 3, 2023, at 08:57, Mark Millard wrote: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >>> ... >>> There is no feasible way we are going to make the branch point of >>> stable/14 in time, with that

What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]

Alexey Dokuchaev wrote on Date: Wed, 03 May 2023 07:53:09 UTC : > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: > > ... > > There is no feasible way we are going to make the branch point of > > stable/14 in time, with that scheduled for May 12, 2023 with the above > > points. That

Re: What to do about a few lines in vfs_domount() never executed?

ting mountd/nfsd to run in a vnet > > prison, I came across the following lines near the > > beginning of vfs_domount() in sys/kern/vfs_mount.c: > > > > if (fsflags & MNT_EXPORTED) { > > error = priv_check(td, PRIV_VFS_MOUNT_EXPORTED); > > if (error

Re: What to do about a few lines in vfs_domount() never executed?

cal to one of the functions in vfs_mount.c and a search shows > it never gets set.) > > I suppose you could argue that priv_check(td, PRIV_VFS_MOUNT_EXPORTED) > should check for caller being root, since that is what ancient code did. > Or, you could argue that, if a non-root user is a

Re: What to do about a few lines in vfs_domount() never executed?

exports). (As I noted, MNT_EXPORTED never gets set in fsflags. The variable is local to one of the functions in vfs_mount.c and a search shows it never gets set.) I suppose you could argue that priv_check(td, PRIV_VFS_MOUNT_EXPORTED) should check for caller being root, since that is

Re: What to do about a few lines in vfs_domount() never executed?

_EXPORTED); > if (error) >return (error); > } > > #1 - Since MNT_EXPORTED is never set in fsflags, this code never > gets executed. > --> I am asking what to do with the above code, since that > changes for the patch that allows mountd t

Re: What to do about a few lines in vfs_domount() never executed?

er set in fsflags, this code never > gets executed. > --> I am asking what to do with the above code, since that > changes for the patch that allows mountd to run in a vnet > prison. > #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always

What to do about a few lines in vfs_domount() never executed?

#1 - Since MNT_EXPORTED is never set in fsflags, this code never gets executed. --> I am asking what to do with the above code, since that changes for the patch that allows mountd to run in a vnet prison. #2 - priv_check(td, PRIV_VFS_MOUNT_EXPORTED) always re

Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine

On Tue, 19 Apr 2022 06:48:04 -0600 Warner Losh wrote: Hello again, I'm on 13-STABLE, version FreeBSD 13.1-STABLE #30 stable/13-n250552-364a69a529b: Tue Apr 26 07:32:42 CEST 2022 amd64 (builder host). Sources for a NanoBSD of 13.0-RELENG (latest as of today) doesn't build, still the reported

Re: 13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine

The vdso error is fixed by cherry-picking b3b462229f972e2ed24d450d7d2f8855cdd58a87. I'm not sure about the second error, though if it's a general profile error, you make need WITHOUT_PROFILE=t in both the build and install phases. On Tue, Apr 19, 2022 at 5:46 AM FreeBSD User wrote: > I regular

13-STABLE: can not cross build 13.0-RELENG and 13.1-RELENG, what on CURRENT works fine

I regular build for a NanoBSD appliance 13-STABLE, 13.0-RELENG and 13.1-RELENG on either 14-CURRENT and 13-STABLE. Several days ago, some changes has been made to /usr/src/Makefile.inc1, first on CURRENT and shortly after on 13. As with today, building from sources either 13.1-RELENG and

Re: What are the in-kernel functions to print human readable timestamps (bintime)?

Quoting Warner Losh (from Fri, 11 Mar 2022 08:57:33 -0700): On Fri, Mar 11, 2022 at 2:52 AM Alexander Leidinger wrote: Hi, I'm looking for a function to convert bintime to a human readable format in the kernel... and what is the usual format we use? Yes. We don't generally log

Re: What are the in-kernel functions to print human readable timestamps (bintime)?

Warner Losh wrote: > since we already add stuff to what's printed for the priority. We could say > <3,seconds-since-boot.fracsec> instead of just <3> and hack dmesg > to print the right thing. Isn't that what kern.msgbuf_show_timestamp does already? I use that, along wit

Re: What are the in-kernel functions to format time?

On 3/11/22 12:20, Gary Jennejohn wrote: Do you mean the %zd? kvprintf() checks for a zflag and handles the argument as size_t or ssize_t, depending on whether the sign is positive or negative. Hi, Given that time is a 64-bit value, then probably "%llu", and (unsigned long long)bintime would

Re: What are the in-kernel functions to print human readable timestamps (bintime)?

On Fri, Mar 11, 2022 at 2:52 AM Alexander Leidinger wrote: > Hi, > > I'm looking for a function to convert bintime to a human readable > format in the kernel... and what is the usual format we use? > Yes. We don't generally log it. > > The use case for this is: if someth

Re: What are the in-kernel functions to format time?

On Fri, 11 Mar 2022 11:01:03 +0100 Hans Petter Selasky wrote: > On 3/11/22 10:49, Alexander Leidinger wrote: > > Hi, > > > > I'm looking for a function to convert bintime to a human readable format > > > in the kernel... and what is the usual format we u

Re: What are the in-kernel functions to format time?

On 3/11/22 10:49, Alexander Leidinger wrote: Hi, I'm looking for a function to convert bintime to a human readable format in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel about a signal, I want to know when

What are the in-kernel functions to print human readable timestamps (bintime)?

Hi, I'm looking for a function to convert bintime to a human readable format in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel about a signal, I want to know when it happened, or in terms of code see below (tabs

What are the in-kernel functions to format time?

Hi, I'm looking for a function to convert bintime to a human readable format in the kernel... and what is the usual format we use? The use case for this is: if something throws a log from the kernel about a signal, I want to know when it happened, or in terms of code see below (tabs

Re: WITH_ASAN= vs. vfork: ASAN can not deal with vfork in a reliable manor, so what to do to avoid vfork fairly generally, including for kyua?

h for FreeBSD should > also be using: > > # define ASAN_INTERCEPT_VFORK 1 > > but it currently is not. Well, looking around there does not seem to be a FreeBSD-supporting implementation to go with use of "# define ASAN_INTERCEPT_VFORK 1". So there would be more to it t

WITH_ASAN= vs. vfork: ASAN can not deal with vfork in a reliable manor, so what to do to avoid vfork fairly generally, including for kyua?

ASAN is documented to not be able to deal reliably with vfork use (inaccurate results, result mixing interpretations of the old and new contexts, and so on). [There may be other routines sufficiently analogous to vfork to have the same sorts of issues. I'll write only of vfork explicitly.] It

Re: What to do about tgammal?

Le 21.12.2021 08:47, Steve Kargl a écrit : > Not at the moment. tlibm only handles math functions with > a single real agrument [1]. I've been thinking about adding > the 2 argument functions such as atan2 and complex argument > function, but lack the time. I also need to improve the man > page

Re: What to do about tgammal?

On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote: > Le 20.12.2021 16:48, Steve Kargl a écrit : > > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > > > I assume what Steve is talking about is the corresponding value in > &g

Re: What to do about tgammal?

Le 20.12.2021 16:48, Steve Kargl a écrit : > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > I assume what Steve is talking about is the corresponding value in > > decimal of the number of ULP. > > > > Bad assumption. Please read Goldbe

Re: What to do about tgammal?

On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > I assume what Steve is talking about is the corresponding value in > decimal of the number of ULP. > Bad assumption. Please read Goldberg's paper. I am talking about ULP in the underlying floating point format. -- Steve

Re: What to do about tgammal?

rounding error)". > Hi, ULP (Unit in the last place) is at first the weight of the least significant bit of the mantissa. E.g., in IEEE 754 single precision = 2^-23. It can also be seen as the distance between 2 consecutive significands (which is not the distance between 2 consec

Re: What to do about tgammal?

> On 18 Dec 2021, at 17:51, Steve Kargl > wrote: > > On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote: >> >> Hmm. I think my understanding of ULP is missing something? >> >> I thought that ULP could not be greater than the mantissa size >> in bits? >> >> I.e., I thought it

Re: What to do about tgammal?

On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote: > > Hmm. I think my understanding of ULP is missing something? > > I thought that ULP could not be greater than the mantissa size > in bits? > > I.e., I thought it represents average rounding error (compared with > "perfect

Re: What to do about tgammal?

WIP is already better than the imprecise.c > kludge from theraven@. I need to work out the details of > computing logl(x) in extra precision or see if I can leverage > what Bruce did a few years ago. Anywho, current results: > > Interval tested for tga

Re: What to do about tgammal?

or > > Extra diffs most welcome! > Hi Mark, Don't know if you noticed, but I borroewed a few cpu cycles from grimoire. My WIP is already better than the imprecise.c kludge from theraven@. I need to work out the details of computing logl(x) in extra precision or see if I can le

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote: > On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > > > On 14 Dec 2021, at 21:51, Steve Kargl > > wrote: > > > Interval max ULP x at Max ULP > > > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > > >

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl > wrote: > > Interval max ULP x at Max ULP > > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > > [1.0662,6]0.861508 at 1.999467927053585410537e+00 > >

Re: What to do about tgammal?

On 14 Dec 2021, at 21:51, Steve Kargl wrote: > Interval max ULP x at Max ULP > [6,1755.1]0.873414 at 1.480588145237629047468e+03 > [1.0662,6]0.861508 at 1.999467927053585410537e+00 > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > [-1.,-1.0001]

Re: What to do about tgammal?

ed at this again. I cannot tell from the > diff whether you've 'git mv' src/imprecise.c to > ld128/b_tgammal.c. This is need to still get the > mapping of tgammal -> tgamma. Fixed, thanks! Thats what I get from checking only on an ld80 machine! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > I see imp lamented that that fact that he is not sufficiently versed in the numerical methods used (neither am I!). bde

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Just looked at this again. I cannot tell from the diff whether you've 'git mv' src/imprecise.c to ld128/b_tgammal.c.

Re: What to do about tgammal?

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Thanks! I looks okay to me (but, of course, I wrote the patch ;-) BTW, I'll probably take a shot at ld128 tgammal(x)

Re: What to do about tgammal?

> On 13 Dec 2021, at 02:22, Steve Kargl > wrote: > > On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote: >> >> >>> On 4 Dec 2021, at 18:53, Steve Kargl >>> wrote: >>> >>> >>> So, is anyone interested in seeing a massive patch? >> >> Me, please! >> > > So, I have the ld80

Re: RFC: What to do about Allocate in the NFS server for FreeBSD13?

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

Re: RFC: What to do about Allocate in the NFS server for FreeBSD13?

MFC'ng commit f0c9847a6c47. Normally 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

RFC: What to do about Allocate in the NFS server for FreeBSD13?

to have agreed that NFS4ERR_NOTSUPP can be returned by a NFSv4.2 server on a 'per file system basis" instead of globally, since the Linux knfsd already does this. --> As such, Allocate can be enabled by default in main and could be enabled by default in FreeBSD13, if #1 or #2 was

Re: What to do about tgammal?

I'll open a PR if on does not exist. The pr will contain 1) Diff for nonfunctional changes to code for tgamma(x). This is a re-organization of the code so I could reverse it. Some cleanup of comments and documentations. A move towards style(9) 2) Advice on what to do about tgammal(x)

Re: What to do about tgammal?

I'll clean things up and create a diff over the next few days. The patch will disconnect imprecise.c from the build. So, if you like what you see and pursue committing the patch(es), one pre-requisite will be to copy src/imprecise.c to ld128/b_tgammal.c. In the good old day, one would use % svn

Re: What to do about tgammal?

> On 4 Dec 2021, at 18:53, Steve Kargl > wrote: > > > So, is anyone interested in seeing a massive patch? Me, please! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP

Re: What to do about tgammal?

On Sat, Dec 04, 2021 at 08:40:56PM +0100, Hans Petter Selasky wrote: > On 12/4/21 19:53, Steve Kargl wrote: > > What to do about tgammal? (trim some history) > > > >Interval | Max ULP > > ---+ > > [6,171]

Re: What to do about tgammal?

On 12/4/21 19:53, Steve Kargl wrote: What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das

What to do about tgammal?

What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das reviews) provided Intel 80-bit (ld80

Re: what does "failed to read progbits" mean?

On Mon, Oct 25, 2021 at 11:46:49AM -0400, Michael Butler via freebsd-current wrote: > This seems to have gone away after > https://freshbsd.org/freebsd/src/commit/70f51f0e474ffe1fb74cb427423a2fba3637544d > > Not sure if the bug that commit fixes was the underlying cause, Yes, that commit fixes

Re: what does "failed to read progbits" mean?

This seems to have gone away after https://freshbsd.org/freebsd/src/commit/70f51f0e474ffe1fb74cb427423a2fba3637544d Not sure if the bug that commit fixes was the underlying cause, Michael On 10/25/21 11:40, Nuno Teixeira wrote: Same here: kldxref /boot/kernel failed to read progbits

Re: what does "failed to read progbits" mean?

Same here: kldxref /boot/kernel failed to read progbits But kernel failed to install. I will include log tomorrow, I'm doing a clean build with /usr/obj/.. deleted. Michael Butler via freebsd-current escreveu no dia quinta, 21/10/2021 à(s) 20:14: > Well this is different .. I did a full

what does "failed to read progbits" mean?

Well this is different .. I did a full rebuild (after "rm -rf /usr/obj/*") this morning and now see .. ===> linux_common (install) install -T release -o root -g wheel -m 555 linux_common.ko /boot/kernel/ install -T dbg -o root -g wheel -m 555 linux_common.ko.debug

Re: How do I find out what changed for an freebsd release update?

See https://cgit.freebsd.org/src/log/?h=releng/12.2 Everything on 2021-06-29. Regards, Ronald. Van: Rick Macklem Datum: 16 oktober 2021 01:49 Aan: FreeBSD Current Onderwerp: How do I find out what changed for an freebsd release update? Hi, PR#259163 reports a problem w.r.t. the NFSv3

Re: How do I find out what changed for an freebsd release update?

On Fri, Oct 15, 2021 at 11:48:01PM +, Rick Macklem wrote: > Hi, > > PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when > the server was upgraded from 12.2-p8 to 12.2-p9. > I know that nothing changed in NFS server code, but how can I find out > wh

How do I find out what changed for an freebsd release update?

Hi, PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when the server was upgraded from 12.2-p8 to 12.2-p9. I know that nothing changed in NFS server code, but how can I find out what did get changed by that update? Thanks in advance for any help, rick

Re: What happen to mailing list archives?

e Daroussin wrote on >>>> Date: Sun, 6 Jun 2021 10:53:49 +0200 : >>>>   >>>>> What has happended: >>>>> plan A: we migrated everything off mailman/pipermail seamlessly >>>>> with redirection and so on. We patched the new archiver t

Re: What happen to mailing list archives?

On Mon, 7 Jun 2021 22:35:20 +0200 Baptiste Daroussin wrote: > On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote: > > On 2021-Jun-6, at 13:25, Mark Millard wrote: > > > > > Baptiste Daroussin wrote on > > > Date: Sun, 6 Jun 2021 10:53:49

Re: What happen to mailing list archives?

On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote: > On 2021-Jun-6, at 13:25, Mark Millard wrote: > > > Baptiste Daroussin wrote on > > Date: Sun, 6 Jun 2021 10:53:49 +0200 : > > > >> What has happended: > >> plan A: we migrated e

Re: What happen to mailing list archives?

On 2021-Jun-6, at 13:25, Mark Millard wrote: > Baptiste Daroussin wrote on > Date: Sun, 6 Jun 2021 10:53:49 +0200 : > >> What has happended: >> plan A: we migrated everything off mailman/pipermail seamlessly with >> redirection >> and so on. We patched the

Re: What happen to mailing list archives?

Baptiste Daroussin wrote on Date: Sun, 6 Jun 2021 10:53:49 +0200 : > What has happended: > plan A: we migrated everything off mailman/pipermail seamlessly with > redirection > and so on. We patched the new archiver to produce the same file names has > pipermail > >

Re: What happen to mailing list archives?

Hi Steve, Am 06.06.21 um 01:13 schrieb Steve Kargl: > On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote: >> >> >>> On 6. Jun 2021, at 00:53, Steve Kargl >>> wrote: >>> >>> It seems someone has tried to migrate the mailing list archives >>> from mailman to some new fangle code.

Re: What happen to mailing list archives?

> > with reviews of libm patch's I sent the list. Those reviews and > > his detailed analysis of the libm code are now gone or sufficiently > > hidded that I cannot find them. > > > > > Bapt was working on this stuff today. He said something about the archive >

FreeBSD service bug 256182 (was: What happen to mailing list archives?)

On 06/06/2021 00:28, Steve Kargl wrote: Hundreds of emails from me are now gone or sufficiently hidden that I cannot find them. More importantly, Bruce Evans often replied with reviews of libm patch's I sent the list. Those reviews and his detailed analysis of the libm code are now gone or

Re: What happen to mailing list archives?

There is also this useful and efficient form of archive/mirror to include in the update so that it does not remain broken for too long... https://lists.freebsd.org/pipermail/freebsd-questions/2021-June/294104.html https://lists.freebsd.org/archives/freebsd-hubs/2021-June/00.html

Re: What happen to mailing list archives?

> On 6. Jun 2021, at 01:44, Warner Losh wrote: > >  > > >> On Sat, Jun 5, 2021, 5:29 PM Steve Kargl >> wrote: >> On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote: >> > >> > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click >> > FreeBSD-net and then

Re: What happen to mailing list archives?

On Sat, Jun 5, 2021, 5:29 PM Steve Kargl wrote: > On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote: > > > > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click > FreeBSD-net and then "Archives from mailman’s time", you get to a list that > brings you to

Re: What happen to mailing list archives?

On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote: > > p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click > FreeBSD-net and then "Archives from mailman’s time", you get to a list that > brings you to https://lists.freebsd.org/pipermail/freebsd-net/. So the old >

Re: What happen to mailing list archives?

On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote: > > > > On 6. Jun 2021, at 00:53, Steve Kargl > > wrote: > > > > It seems someone has tried to migrate the mailing list archives > > from mailman to some new fangle code. This has broken the archives > > for at least

Re: What happen to mailing list archives?

> On 6. Jun 2021, at 01:00, Michael Gmelin wrote: > >  > > >>> On 6. Jun 2021, at 00:53, Steve Kargl >>> wrote: >>> >> It seems someone has tried to migrate the mailing list archives >> from mailman to some new fangle code. This has broken the archives >> for at least

Re: What happen to mailing list archives?

> On 6. Jun 2021, at 00:53, Steve Kargl > wrote: > > It seems someone has tried to migrate the mailing list archives > from mailman to some new fangle code. This has broken the archives > for at least freebsd-numerics@, freebsd-office@, freebsd-net@ > > As a comparison, simply go to > >

What happen to mailing list archives?

It seems someone has tried to migrate the mailing list archives from mailman to some new fangle code. This has broken the archives for at least freebsd-numerics@, freebsd-office@, freebsd-net@ As a comparison, simply go to https://lists.freebsd.org/mailman/listinfo and follow the links to

Re: What is OpenZFS doing during boot?

bug.cgi?id=255514 for that though > (I > never had such trouble with mergemaster, just even understanding what > etcupdate is trying to do and how to bootstrap it is a mystery to me). > > Anyway, I have a data zpool on 2x encrypted GELI providers that I can only > unlock (and zp

What is OpenZFS doing during boot?

world/kernel build and ran etcupdate, merging in my local changes. This bricked the system again, as it removed the -x bit on /etc/rc.d/netif, I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255514 for that though (I never had such trouble with mergemaster, just even understanding what

Re: Old PowerMacs, Giant, and stable/13 branch and other futures: What is the intent?

FreeBSD 13.0. > > There could be more than I'm reporting. Such warnings are from > post-git-conversion builds that I've done (given the lack of > artifacts.ci.freebsd.org materials to test with). > > The 13 "Code slush" started on 2021-Jan-08. stable/13 is scheduled >

Old PowerMacs, Giant, and stable/13 branch and other futures: What is the intent?

on builds that I've done (given the lack of artifacts.ci.freebsd.org materials to test with). The 13 "Code slush" started on 2021-Jan-08. stable/13 is scheduled to branch on 2021-Jan-22. What is the intended status for these old powerc64 and 32-bit powerpc machines, given that the Giant use still e

Re: What is the zstreamdump command in OpenZFS?

On 9/1/20 2:13 PM, Ryan Moeller wrote: On 9/1/20 1:32 PM, Thomas Laus wrote: Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD.  I run the zstreamdump utility on the file and record the

Re: What is the zstreamdump command in OpenZFS?

On 9/1/20 1:32 PM, Thomas Laus wrote: Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on

What is the zstreamdump command in OpenZFS?

Group: Whenever I perform a major upgrade to any of my ZFS pools, I make a habit of sending the most recent snapshot to a file and then to a DLT tape or DVD. I run the zstreamdump utility on the file and record the checksum. I also run zstreamdump on the archive media and compare checksums.

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

; > > if you have more than one ZFS in your boot environment then: > > > >beadm create FOO > > > > is actually equivalent to > > > >bectl create -r FOO > > > > ie. turning on the recursive functionality in bectl. > > > > Howe

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

hat the system now comes with bectl(8) which is very > similar to beadm? As far as I can tell, the biggest difference is that > if you have more than one ZFS in your boot environment then: > >beadm create FOO > > is actually equivalent to > >bectl create -r F

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

beadm? As far as I can tell, the biggest difference is that > if you have more than one ZFS in your boot environment then: > >beadm create FOO > > is actually equivalent to > >bectl create -r FOO > > ie. turning on the recursive functionality in bectl. >

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

nager. > > Thanks again! > Refind will find all the bootable EFI "elements" in the EFI partition and menu them.  The question then becomes whether multiple efi loaders can be told to each use a *different* partition to load the kernel from (and thus the loader file, which in turn can t

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

: beadm create FOO is actually equivalent to bectl create -r FOO ie. turning on the recursive functionality in bectl. However, this is not really what the OP was asking about. As I understand it, they were looking for something that would allow choosing between several independent installati

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On Tue, 17 Mar 2020 01:31:59 +0300 Andrey Fesenko wrote: > On Tue, Mar 17, 2020 at 1:24 AM Chris wrote: > > > > I'm attempting to boot multiple versions of FreeBSD. > > I started with an install of older 11 with a (u)efi > > boot partition installed. I then grabbed an current 11 > > usbstick,

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On 16.03.20 23:33, Chris wrote: > For the record. I'm *only* using FreeBSD in this situation. I > only mentioned Windows above, for the use of it's boot manager. If you only use FreeBSD, and also use ZFS, you might find beadm[1] interesting. [1]: https://www.freshports.org/sysutils/beadm

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

elements" in the EFI partition and menu them.  The question then becomes whether multiple efi loaders can be told to each use a *different* partition to load the kernel from (and thus the loader file, which in turn can tell it where the root filesystem is.) Reading through the man page it a

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On Mon, 16 Mar 2020 17:24:24 -0500 Karl Denninger k...@denninger.net said On 3/16/2020 17:23, Chris wrote: > I'm attempting to boot multiple versions of FreeBSD. > I started with an install of older 11 with a (u)efi > boot partition installed. I then grabbed an current 11 > usbstick, and

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On Tue, Mar 17, 2020 at 1:24 AM Chris wrote: > > I'm attempting to boot multiple versions of FreeBSD. > I started with an install of older 11 with a (u)efi > boot partition installed. I then grabbed an current 11 > usbstick, and installed that. Which stated it needed to > install a (u)efi boot

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On 3/16/2020 17:23, Chris wrote: > I'm attempting to boot multiple versions of FreeBSD. > I started with an install of older 11 with a (u)efi > boot partition installed. I then grabbed an current 11 > usbstick, and installed that. Which stated it needed to > install a (u)efi boot partition. I let

  1   2   3   4   5   6   >