Hello,
Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: Thu Apr
25 18:48:56
CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at hand).
Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 notebook,
Fujitsu Esprimo Q5XX
(simple desktop, Pentium
ee/frame 0xfe048c204c90
> D> sys_nlm_syscall() at sys_nlm_syscall+0x3d0/frame 0xfe048c204e00
> D> amd64_syscall() at amd64_syscall+0x158/frame 0xfe048c204f30
> D> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe048c204f30
> D> --- syscall (154, FreeBS
Am Tue, 9 Apr 2024 17:10:52 +0200
Rainer Hurling schrieb:
> Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:
> > On Sat 06 Apr 09:23, Rainer Hurling wrote:
> >> Am 06.04.24 um 09:05 schrieb FreeBSD User:
> >>> Hello,
> >>>
> >>> afte
Am Sat, 6 Apr 2024 09:05:00 +0200
FreeBSD User schrieb:
> Hello,
>
> after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0
> on CURRENT and
> 14-STABLE, I can't update several ports:
>
> www/apache24
> databases/redis
>
> pkg core du
Am Thu, 4 Apr 2024 01:14:52 -0500
Kyle Evans schrieb:
> On 4/4/24 00:49, FreeBSD User wrote:
> > Hello,
> >
> > I just stumbled over this CVE regarding xz 5.6.0 and 5.6.1:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
> >
> >
BLE and CURRENT boxes (both OS variants latest
builds, i.e. FreeBSD
15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr 5 20:30:39 CEST 2024
amd64).
After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail
with poudriere)
building packages for 14.0-RELENG, I observed the s
Am Thu, 04 Apr 2024 08:06:26 +0200 (CEST)
sth...@nethelp.no schrieb:
> >> I have to report to my superiors (we're using 14-STABLE and CURRENT
> >> and I do so in private),
> >> so I would like to welcome any comment on that.
> >
> > No it does not affec
ng NFSv3
> >>>
> >>> Peter
> >>>
> >>>
> >>>
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 2; apic id = 04
> >>> fault virtual address = 0x89
> >>> fault
b7e
> > #7 0x804b9d90 at nfs_readdir+0x1f0
> > #8 0x8069c61a at vop_sigdefer+0x2a
> > #9 0x809f8ae0 at VOP_READDIR_APV+0x20
> > #10 0x81ce75de at autofs_readdir+0x2ce
> > #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> > #12 0
Am Sun, 14 Jan 2024 20:34:12 -0800
Cy Schubert schrieb:
> In message om>
> , Rick Macklem writes:
> > On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
> > wrote:
> > >
> > >
> > > Van: FreeBSD User
> > > Datum: 13 januari 2024
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET)
Felix Reichenberger schrieb:
> > Hello,
> >
> > I've got a problem with recent CURRENT, running vnet JAILs.
> > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> > 2024 amd64
> >
> >
Am Sat, 13 Jan 2024 19:41:30 -0800
Rick Macklem schrieb:
> On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
> >
> >
> > Van: FreeBSD User
> > Datum: 13 januari 2024 19:34
> > Aan: FreeBSD CURRENT
> > Onderwerp: NFSv4 crash of CURRENT
> >
>
Hello,
I've got a problem with recent CURRENT, running vnet JAILs.
FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024
amd64
Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP
and ICMP
(ipfw is configured via rc.conf in this case, host
Am Thu, 23 Nov 2023 20:37:26 +0100
FreeBSD User schrieb:
> Hello,
>
> I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge
> built-in into
> a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an
> CP2102, see here:
>
> h
Hello,
at first: observation is below, marked [OBSERVATION].
Running recent CURRENT (FreeBSD 15.0-CURRENT #26 main-n265831-3523f0677ef: Mon
Oct 9 14:00:42
CEST 2023 amd64), I've configured a bridge (bridge0), the hosts's interface
igb0 (I350-T2 two
port Gigabit Network Connection ) is member
Am Fri, 30 Jun 2023 16:45:52 +0200
Pierre Pronchery schrieb:
My apology for the delay.
Shortly after the post here and several patches the problem vanished into thin
air - alos by
using tigervnc as the client and not, as proposed on the FreeBSD Wiki page,
xfreerdp.
Thank you very much
Am Thu, 29 Jun 2023 16:41:51 +0200
Guido Falsi schrieb:
> On 29/06/23 16:35, FreeBSD User wrote:
> > Hello,
> >
> > running a recent CURRENT, 14.0-CURRENT #10 main-n263871-fd774e065c5d: Thu
> > Jun 29 05:26:55
> > CEST 2023 amd64, xfreerdp (net/freerdp) d
in any way.
Is there any way to access the bhyve guest's native graphical interface? As in
the PR shown
above already documented (setup taken from the FreeBSD Wiki/bhyve), a
framebuffer is already
configured.
It would be nice if someone could give a hint.
Thanks in advance,
oh
--
O. Hartmann
On Sun, Jun 25, 2023 at 5:10 PM Kyle Evans wrote:
Hi Kyle,
Thanks for the response.
On 6/24/23 04:06, parv/FreeBSD wrote:
> > On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> >
> > Hi there,
> >
> > I am stuck in "installworld" step due
On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> Hi there,
>
> I am stuck in "installworld" step due to
> ERROR-tried-to-rebuild-during-make-install when going
> from 1cebc9298cf to b98fbf3781 on one host, or from
> 9fbeeb6e3831 to dfa1982352ee on another host.
*sigh* Attachments did not seem to make the list archive ...
On Thu, Jun 15, 2023 at 1:14 AM parv/FreeBSD wrote:
> I am stuck in "installworld" step due to
> ERROR-tried-to-rebuild-during-make-install when going
> from 1cebc9298cf to b98fbf3781 on one host, or from
> 9fbeeb
-m 0755 -o root -g wheel /boot
install -o root -g wheel -m 444 loader.help.efi /boot/loader.help.efi
cc -target x86_64-unknown-freebsd14.0
--sysroot=/build/world/freebsd/src/amd64.amd64/tmp
-B/build/world/freebsd/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common
-Wformat -fshort-wchar -mn
Am Wed, 31 May 2023 12:15:12 -0600
Warner Losh schrieb:
Sorry for the late response.
> On Mon, May 29, 2023 at 2:59 AM FreeBSD User wrote:
>
> > Hello,
> >
> > on CURRENT, enabling in /etc/src.conf
> >
> > WITH_BEARSSL=
> >
> > seems to re
Wrote Dimitry Andric on Fri, 21 Apr 2023 10:38:05 UTC
(via
https://lists.freebsd.org/archives/freebsd-current/2023-April/003556.html )
>
> ... However, I have read that with unicode, you should *never*
> use [A-Z] or [0-9], but character classes instead. That seems to give
> both fi
Am Sat, 15 Apr 2023 07:36:25 -0700
Cy Schubert schrieb:
> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
> FreeBSD Us
> er writes:
> > Am Thu, 13 Apr 2023 22:18:04 -0700
> > Mark Millard schrieb:
> >
> > > On
Am Thu, 13 Apr 2023 22:18:04 -0700
Mark Millard schrieb:
> On Apr 13, 2023, at 21:44, Charlie Li wrote:
>
> > Mark Millard wrote:
> >> FYI: in my original report for a context that has never had
> >> block_cloning enabled, I reported BOTH missing files and
> >> file content corruption in the
Am Sun, 9 Apr 2023 14:37:03 +0200
Mateusz Guzik schrieb:
> On 4/9/23, FreeBSD User wrote:
> > Today, after upgrading to FreeBSD 14.0-CURRENT #8 main-n262052-0d4038e3012b:
> > Sun Apr 9
> > 12:01:02 CEST 2023 amd64, AND upgrading ZPOOLs via
> >
> > zpool up
Am Thu, 30 Mar 2023 17:27:31 +0200
Dag-Erling Smørgrav schrieb:
> FreeBSD User writes:
> > I tried to put the option
> >
> > WITHOUT_MODULE="an"
>
> it's spelled WITHOUT_MODULES, cf. make.conf(5).
>
> DES
Correct, and so I use it ... ;-)
Am Thu, 30 Mar 2023 15:53:19 +0200
Mateusz Guzik schrieb:
> On 3/30/23, FreeBSD User wrote:
> > Hello folks,
> >
> > some strange misbehaviour in a NanoBSD compilation is driving me nuts.
> > Recently I posted some
> > error messages regarding
> >
> &g
Am Thu, 30 Mar 2023 16:56:09 +0200
Mateusz Guzik schrieb:
> On 3/30/23, Mateusz Guzik wrote:
> > On 3/30/23, FreeBSD User wrote:
> >> Hello folks,
> >>
> >> some strange misbehaviour in a NanoBSD compilation is driving me nuts.
> >> Recentl
,-Wdeprecated-non-prototype]
[...]
but being able compiling the kernel was "a lucky shot/mistake" and in the vain
of discussion
it has been revealed that my nanoBSD specific "make.conf/src.conf"
configurations were wrong.
So, again:
The builder host is a recent CURRENT (Fre
Am Wed, 8 Mar 2023 12:13:49 +0100
tue...@freebsd.org schrieb:
> > On 8. Mar 2023, at 11:42, FreeBSD User wrote:
> >
> > Am Wed, 8 Mar 2023 11:28:11 +0100
> > Dimitry Andric schrieb:
> >
> >> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> >>
Am Wed, 8 Mar 2023 11:28:11 +0100
Dimitry Andric schrieb:
> On 8 Mar 2023, at 11:19, FreeBSD User wrote:
> ...
> > But I don't understand why the make environment is trying to compile a
> > piece of code that
> > is disabled via "nodevice" as
Am Thu, 2 Mar 2023 11:13:51 +0100
Dimitry Andric schrieb:
> On 2 Mar 2023, at 06:41, FreeBSD User wrote:
> >
> > Am Mon, 27 Feb 2023 23:46:21 +0100
> > Dimitry Andric schrieb:
> ...
> >
> > I tried to find some documentation on my CURRENT host r
Am Thu, 2 Mar 2023 11:13:51 +0100
Dimitry Andric schrieb:
> On 2 Mar 2023, at 06:41, FreeBSD User wrote:
> >
> > Am Mon, 27 Feb 2023 23:46:21 +0100
> > Dimitry Andric schrieb:
> ...
> >
> > I tried to find some documentation on my CURRENT host r
Am Mon, 27 Feb 2023 23:46:21 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 22:23, Paul Mather wrote:
> >
> > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote:
> >
> >> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >>>
> >>>
Am Mon, 27 Feb 2023 20:57:19 +0100
Dimitry Andric schrieb:
> On 27 Feb 2023, at 19:19, FreeBSD User wrote:
> >
> > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23
> > main-n261147-b8bb73ab724b: Sun
> > Feb 26 17:39:38 CET 2023 amd64), and nanoBSD (recent 13
Hallo everybody,
a week ago I compiled a new 13-STABLE (FreeBSD 13.2-STABLE #77
stable/13-n254681-44a6088278ea:
Sat Feb 25 07:44:36 CET 2023 amd64, custom kernel, same happens with the recent
regular
GENERIC kernel). ZFS root installation.
Graphics driver:
drm-510-kmod-5.10.163_2
e I hope I can provide
you with a
backtrace. cpu-data has been updated recently, I use this on these two
IvyBridge methusalem
riggs, I may disable this first and see what happens ...
Regards
oh
>
> rick
>
> On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote:
> >
> > Hel
Am Sun, 19 Feb 2023 13:30:13 +0300
"Andrey V. Elsukov" schrieb:
> 18.02.2023 18:42, FreeBSD User пишет:
> > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN
> > interface. We use NPTv6 to translate ULA addresses for the inner
> > IPv6 networks.
Hello,
most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode,
used after
repairing failed FFS filesystems, is all right). The crashes go on since
roughly a 1/2 week
from now. The boxes involved are all cumtomized kernels (in most cases hard
linked modules
into kernel).
Hello,
running a small nanoBSD firewall/router appliance, the WAN interface (tun0) is
confugred via
SLAAC when it comes to IPv6. The allpliance is running in-kernel compiled IPFW.
The OS is
FreeBSD 13-STABLE, compiled on a recuurant weekly basis.
On a 24 hour basis, the ISP changes the IPv4
I should have requested in OP to CC to me as I have subscribed to
-current@ list without receiving email.
So here is my attempt to craft a reponse from the web page ...
https://lists.freebsd.org/archives/freebsd-current/2023-January/003142.html
> Oleksandr Kryvulia wrote on 20230131-092
Hi there,
Since around 2022-11, I am unable to change display brightness
of the display of a Framework laptop (Intel i5-1135G7, Iris
Xe iGPU) with "i915kms" module (from "drm-510-kmod" package/port)
& "acpi_video" (FreeBSD) kernel module.
Earlier I
Hello,
well, the aim of my post sounds strange, but I'm serious.
Background: I run at home a 14-CURRENT based server with a ZFS volume (RAIDZ)
comprised from
4x 4 TB HDD. A couple of days I had to exchange the HGST NAS drives since one
got a permanent
SMART error. So all HDDs have been replaced
Hello folks,
I ran today into a problem, that the reolveer option "edns0" isn't documented
(as well as some
others). Searching the net reveals, that there is a PR open with exactly that
issue since
January 2016, since then, code has changed I presume.
Could someone please take care of that
illing to commit it.
>
> We have a few options on the table and probably more. The ports
> infrastructure option is probably the most work. Adding functionality to
> all the ports that use /var/run is also a lot of work and if relying on
> individual porters, will likely take some time and be varied in
> implementation and robustness.
>
>
I'd like to add a sidenote here, if one may please.
Checking today NanoBSD based projects, i.e. XigmaNAS, which also let /var
reside on a memory
disk and the way NanoBSD handles /var, contradicts some claims that is is
'unsupported' to put
/var on a volatile memory infrastructure.
On the other hand, there are only few ports which create subfolders to, i.e.,
/var/run not
congruent what the specific metree sketch implies, the port security/clamav is
one of those
few.
The question that bothers me most and this is just from the pratical point of
view as stated
initially and from a second view, just out of curiosity:
what (fatal?) implications does it have to create some folders by port's
rc-script in /var/run
or whatever folder is needed to be on a volatile memory device for FreeBSD base
system's mtree
infrastructure?
--
O. Hartmann
Am Sat, 27 Aug 2022 13:16:43 +0200
tue...@freebsd.org schrieb:
> > On 27. Aug 2022, at 08:30, FreeBSD User wrote:
> >
> > Hello,
> >
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> >
> > Port security/clamav is without doubt for man
Am Sat, 27 Aug 2022 11:21:40 +0200
Michael Gmelin schrieb:
> > On 27. Aug 2022, at 08:31, FreeBSD User wrote:
> >
> > Hello,
> >
> > I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> >
> > Port security/clamav is without doubt for man
Hello,
I'm referencing to Bug 259699 [2] and Bug 259585 [1].
Port security/clamav is without doubt for many of FreeBSD users an important
piece of security
software so I assume a widespread usage.
It is also a not uncommon use case to use NanoBSD or any kind of
low-memory-footprint
Hello,
I'm running a FreeBSD 13.1-RELENG-p1 zroot-based guest in a VirtualBox
4.1.24/26 (do not know
exactly). The host is a special system based on Linux und VirtualBox and I have
no chances to
configure the VBox.
Somehow the VBox crashed and hung up the complete computer, so I had to cold
Am Sun, 3 Jul 2022 11:57:33 +0200
FreeBSD User schrieb:
Sorry for the noise, the learning process is still in progress and I learned
about the
until-now-not-fully-understood V4: entry in /etc/exports.
Thanks for reading and patience.
regards,
oh
> Hello folks,
>
>
> Trying to
Hello folks,
Trying to mount a NFS filesystem offered by a FreeBSD 12.3-p5 (XigmaNAS) from a
recent CURRENT
(FreeBSD 14.0-CURRENT #19 main-n256512-ef86876b846: Sat Jul 2 23:31:53 CEST
2022 amd64) via
:/etc # mount -t nfs -o vers=4 192.168.0.11:/mnt/NAS00/home /tmp/mnt
results in
mount_nfs
Hello,
the problem I'm about to report is not specific to CURRENT, I report this to
CURRENT
because I'm list member. The problem occurs on FreeBSD 12.3-RELEASE-p5.
Setup: connecting to vnet jails bound to a dedicated NIC via if_bridge results
in an
erratic behaviour (from my point of view
On Thu, 28 Apr 2022 13:36:21 -0600
Alan Somers wrote:
> On Thu, Apr 28, 2022 at 1:29 PM Marek Zarychta
> wrote:
> >
> > W dniu 28.04.2022 o 21:21, FreeBSD User pisze:
> > > Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to
> > >
Running XigmaNAS 12.3.0.4.9009 on amd64 hardware, we try to mount HDD to rescue
them and
store the data on ZFS volumes. Mounting of the HDD doesn't work, FreeBSD 12.3
obviously
lack in some etx2 features, namely "needs_recovery". The kernel reports:
WARNING: mount of da4p3
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
On Fri, 1 Apr 2022 12:09:21 -0400
Ed Maste wrote:
> On Fri, 1 Apr 2022 at 12:04, FreeBSD User wrote:
> >
> > I tried the patch given at the URL above (Phabricator). Patch applied on
> > recent CURRENT and trying to "make installworld" leaves me with this error
-RELENG on a
CURRENT host (recent 14-CURRENT!) works without problems.
On 13-STABLE (FreeBSD 13.1-STABLE #26 stable/13-n250478-bb8e1dfbff3: Thu Apr 14
10:47:51 CEST 2022 amd64) building either 13.0-RELENG or 13.1-RELENG fails!
On building from sources 13.0-RELENG I receive while in installworld
g, pam_env isn't available on FreeBSD)?
If this is a trivial issue and caused by lack of my personell knowledge, please
excuse.
Kind regards,
O. Hartmann
Am Fri, 1 Apr 2022 10:08:11 -0400
Ed Maste schrieb:
> On Fri, 1 Apr 2022 at 10:00, Jens Schweikhardt
> wrote:
> >
> > Hello *,
> > Looks like a semicolon is missing after the "fi".
>
> Indeed, and there was a close bracket missing as well. I've put a
> (hopefully) fixed version in review at
Am Fri, 1 Apr 2022 16:00:10 +0200 (CEST)
Jens Schweikhardt schrieb:
> Hello *,
> Looks like a semicolon is missing after the "fi".
> Jens
>
> - Ursprüngliche Mail -
> Von: "Ed Maste"
> An: "FreeBSD User"
> CC: "freebsd-curr
On 14.0-CURRENT #134 main-n253938-4ef6e56ae80: Thu Mar 24 16:11:07 CET 2022
amd64, it is without any problem possible to build most recent 13-STABLE
sources as of today (stable/13-n250195-26e8bb3a4e1).
On 14.0-CURRENT #18 main-n254160-4fc5a607fdf: Fri Apr 1 08:30:10 CEST 2022
amd64 this is not
On Mon, 28 Feb 2022 17:11:27 +0100
Michael Gmelin wrote:
[...]
schnipp
[...]
> >
> > poudriere jail -l:
> >
> > # poudriere jail -l
> > JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
> > 123-amd64 12.3-RELEASE amd64
> > url=https://download.freebsd.org/releases/a ... 3-RELEASE/ 2022-02-24
> >
the native CURRENT "jailed poudriere" builder
and also
following this reference (for those who want to check on this)
https://www.mimar.rs/blog/host-your-own-services-with-freebsd-jails-part-3-poudriere
which seems quite recent and with the exception, that we use "vnet" on
With mergin a recent commit today involving /usr/src/sys/x86/x86/tsc.c of
FreeBSD
13-STABLE, compiling the kernel results in the error shown below:
[...]
cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -shared -O3 -pipe
changing the defaults, but you need to ensure
that reasonable scenarios, like the changed FreeBSD client mounting
from v3-only server, still work correctly. The change should be made in a
way that only affects client that connects to the server that has both
v4 and v3.
A particular test case that needs
t_nfs.8 8.3 (Berkeley) 3/29/95
.\" $FreeBSD$
.\"
-.Dd July 10, 2021
+.Dd January 10, 2022
.Dt MOUNT_NFS 8
.Os
.Sh NAME
@@ -216,8 +216,8 @@ This option requires the
.Cm nfsv4
option.
.It Cm nfsv2
-Use the NFS Version 2 protocol (the default is to try version 3 first
-then version 2
; binary.
>>> The resulting binary has the associated paths (/lib/libc++.so.1 and
>>> /usr/lib/libcxxrt.so.1) in its DT_NEEDED. So it is fine for the .so to be
>>> in /usr/lib. This is the same with /usr/lib/libc.so vs /lib/libc.so.7.
>>>
>>> Howev
7.
>>
>> However, your point about libcxxrt.so.1 is valid. It needs to also be moved
>> to /lib if libc++.so.1 is moved to /lib. Doing so will also require yet
>> another
>> depend-clean.sh fixup (well, probably just adjusting the one I added to
>> check th
; in /usr/lib. This is the same with /usr/lib/libc.so vs /lib/libc.so.7.
>
> However, your point about libcxxrt.so.1 is valid. It needs to also be moved
> to /lib if libc++.so.1 is moved to /lib. Doing so will also require yet
> another
> depend-clean.sh fixup (well, probably just
fic, detailed
issue(s) the move to /lib/libc++.so.1 covers vs. not,
given the /usr/lib/libc++.so and /usr/lib/libcxxrt.so
paths.
I'm not using anything with /usr/lib/ being on a different
file system than /lib so I'll definitely not observe any
problems. And it might be a waste to try to clear my
confu
b/libc++.so.1
>
> Because for libc++.so we don't just symlink to the current version of the
> library
> (as we do for most other shared libraries) to tell the compiler what to link
> against
> for -lc++, instead we use a linker script that tells the compiler to link
> against
> bo
ect (or hope) for META_MODE use.
>
Dumb mistake on my part above: I paid only attention to the build,
and not to what was installed (or left in place) by installworld .
Despite the buildworld activity indicated above, installworld had
left in place:
# more /usr/lib/libc++.so
/* $FreeBSD$ *
On 2021-Dec-30, at 13:27, Mark Millard wrote:
>> Dear all,
>>
>> on a system updated yesterday I get
>>
>> tuexen_at_head:~/freebsd-src % git branch
>> * main
>> tuexen_at_head:~/freebsd-src % git pull
>> Already up to date.
>> tuexen
30:43 2021 /usr/obj/BUILDs/main-amd
>> 64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so
>>>
>>> So lib/libc++/libc++.ld and tmp/usr/lib/libc++.so both had been
>>> updated.
>>>
>>> I used META_MODE.
>>>
>>> So I do not get a full ma
> Dear all,
>
> on a system updated yesterday I get
>
> tuexen_at_head:~/freebsd-src % git branch
> * main
> tuexen_at_head:~/freebsd-src % git pull
> Already up to date.
> tuexen_at_head:~/freebsd-src % uname -a
> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRE
On 2021-Dec-30, at 13:05, Mark Millard wrote:
> This asks a question in a different direction that my prior
> reports about my builds vs. Cy's reported build.
>
> Background:
>
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
> (
This asks a question in a different direction that my prior
reports about my builds vs. Cy's reported build.
Background:
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP
( /lib/libc++.so.1 /usr/lib/libcxxrt.so
and:
lrwxr-xr-x 1 root wheel23
ported but the use of
> the tmp/usr/lib/libc++.so path does seem odd.
>
> I've not looked at what a system from before the first move of
> libc++.so.1 does. I may be able to check that in a while.
So I've now looked at a build (not installed) that was done on:
# uname -apKU
FreeBSD CA7
> This commit results in a different error.
>
> ld: error: /export/obj/opt/src/git-src/amd64.amd64/tmp/usr/lib/libc++.so:2:
> cannot find /usr/lib/libc++.so.1 inside /export/obj/opt/src/git-src/amd64.am
> d64/tmp
> >>> GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )
> >>> ^
> c++:
Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing
and rebooting did not put in place a /lib/libc++.so.1 but
delete-old-libs removed the /usr/lib/libc++.so.1 .
(Luckily my environment has sufficient recent near-redundancy
to recover easily by putting in place a /usr/lib/libc++.so.1 .)
ndex 3a708805d3ea..74bed2ecd314 100644
--- a/usr.bin/clang/llvm.prog.mk
+++ b/usr.bin/clang/llvm.prog.mk
@@ -25,6 +25,7 @@ PACKAGE= clang
.if ${.MAKE.OS} == "FreeBSD" || !defined(BOOTSTRAPPING)
LIBADD+= execinfo
LIBADD+= tinfow
+LIBADD+= z
.endif
LIBADD+=
On Wed, 29 Dec 2021 09:10:02 +0200
Daniel Braniss wrote:
> > On 29 Dec 2021, at 01:25, FreeBSD User wrote:
> >
> > On Mon, 20 Dec 2021 14:35:10 +0100
> > Marc Fonvieille mailto:black...@freebsd.org>> wrote:
> >
> >>
On Mon, 20 Dec 2021 14:35:10 +0100
Marc Fonvieille wrote:
> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
> >
> >
> > > On 19. Dec 2021, at 12:18, FreeBSD User wrote:
> > >
> > > environment. Since I'm interested in coding for some smaller
Confirmed. The kernel at ..
FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021
.. boots successfully.
The kernel at ..
FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021
.. fails immediately after printing something like ..
Timecounters tick every 1.000 msec
/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law
Am Mon, 20 Dec 2021 14:35:10 +0100
schrieb Marc Fonvieille :
> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
> >
> >
> > > On 19. Dec 2021, at 12:18, FreeBSD User
> > > wrote:
> > >
> > > environment. Since I'm interested in coding f
Hi Oliver,
I'm working on this small [1] project using FreeBSD only. Software part is based
on FreeRTOS v10.2.1. You can also find some pieces of the development history on
hackaday [2].
Regards,
Dmitry
[1] https://github.com/mcusim/Xling
[2] https://hackaday.io/project/165726-xling
> He
than simply clicking a host base from a menu, I'm not
afraid of
doing some larger basic setup if needed. But I have so far almost no experience
in cross
compiling on FreeBSD and I'd like to ask whether someone out here has already
done
setting up an environment based on the basic tools FreeBSD
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-src/
>
> You need to exclude the ones with SPDX
e: 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
Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for
readability):
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25
main-n251456-22c4ab6cb015-dirty:
Tue Dec 7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main
From: FreeBSD User wrote on
Date: Wed, 15 Dec 2021 18:55:09 +0100 :
> . . .
>
> It is spooky, if not to say "buggy", if ZFS is capable of freezing the whole
> box even if
> the essential operating system stuff is isolated on a dedicated UFS
> filesystem.
I wou
On Mon, 13 Dec 2021 09:30:50 +0200
Andriy Gapon wrote:
> On 12/12/2021 18:45, Alan Somers wrote:
> > You need to look at what's causing those errors. What kind of disks
> > are you using, with what HBA? It's not surprising that any access to
> > ZFS hangs; that's what it's designed to do when
On Fri, 10 Dec 2021 19:41:07 +1030
Daniel O'Connor via freebsd-current wrote:
> > On 25 Nov 2021, at 18:50, FreeBSD User wrote:
> >
> > Running CURRENT (FreeBSD 14.0-CURRENT #7 main-n250911-a11983366ea7: Mon Nov
> > 22
> > 18:17:54 CET 2021 amd64) troubles
thing like this will improve things.
if (0 == print "test\015\012") {
return;
}
Regards and happy hacking,
Ronald.
PS: I think this does not have to do a lot with freebsd-current. Might move it
to https://lists.freebsd.org/subscription/freebsd-perl or some
send" and "man 2 socket" for a lot more information.
So it depends a bit on the type of socket you created.
Regards and happy hacking,
Ronald.
Van: Piper H
Datum: woensdag, 15 december 2021 07:52
Aan: freebsd-current@freebsd.org
Onderwerp: question on socket server
Hello
I have litt
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
>>
>>
On 2021-Dec-14, at 16:54, Alexander Motin wrote:
> Mark,
>
> Support for edonr checksums was added to FreeBSD main about a month ago:
> https://github.com/openzfs/zfs/pull/12735 . In 13 it is indeed still
> not supported. But you should not worry too much about it, since
1 - 100 of 5923 matches
Mail list logo
