00:02:20 <mjp> bystander: hey, there are flames pooring out of the windows on your house
00:02:23 <mjp> home owner: well if you expect me to do anything about it, you'll need to lodge a formal request for me to look into it
00:03:42 <ant-x> Wrong analogy, methinks.
00:04:07 <ant-x> By the way, I have had good experience with that bug tracker: a problem I reported was fixed after 1.5 years or so.
00:04:49 <mjp> if you give that page a read, you can see that the project has serious resource and governance problems. to the point where i'm questioning if the operating system is even safe to run anymore
00:04:57 <heston76> Tinhead bot seems to have lost it's marbles in #freebsd-bugs
00:07:11 <mjp> i love freebsd and have used it for decades, but if the project cannot address or at least respond to these issues, i'll have to seriously consider moving to a more mature/supported os like debian
00:07:22 <ant-x> mjp, if it is your won article -- great. You could initiate  a productive discussion of it on the mailing lists, more suitable to lengthy discourse than IRC. (my personal opinion)
00:07:43 <ant-x> mjp, there are other BSDs, as well.
00:09:08 <mjp> i'm a user/sysadmin with a full time job and a family, i don't have time to contribure to the project
00:09:20 <LXGHTNXNG> talking a high and mighty game about governance issues makes you sound like a strasserite
00:10:23 <mjp> i think if the project is not able or willing to take security seriously, state it and make everyone aware, don't pretend otherwise
00:11:40 <ant-x> mjp, reporting a problem is a tiny fraction of effort of having it fixed.
00:13:36 <mjp> i dont think anyone would disagree with that
00:14:14 <LXGHTNXNG> you might be right, but you are at this juncture a disruptive presence
00:14:26 <mjp> i dont see the project even acknowledging long standing problems, let alone having a plan to address them
00:14:44 <mjp> wake up calls usually are disruptive
00:14:49 <mjp> that is the point?
00:15:36 <LXGHTNXNG> linking master→main under «political commits» really does stand you out as a fascist. please just leave.
00:15:57 <mjp> bystander: hey, there are flames pooring out of the windows on your house. home owner: you are at this juncture a disruptive presence
00:16:00 <mjp> ok
00:16:31 <LXGHTNXNG> analogy incorrect
00:17:36 <LXGHTNXNG> if you're going to switch to a different OS because of this - switch
00:17:48 <LXGHTNXNG> it's that simple. if you don't want to visit the house you think is burning, don't visit the house
00:17:55 <mewt> building stuff as root doesn't seem great
00:18:05 <mewt> i will probably apply some of their recommendations, at least
00:18:43 <mjp> i like the house, i have lived here for decades, i dont want to leave
00:19:21 <heston76> mjp: Then the solution is to constructively contribute.  End of story.
00:19:26 <mjp> i also have a landlord advising me "well if you dont like burning to death, just leave!"
00:20:08 <mjp> i don't think if fair to blame users of the OS for not fixing its shortcomings, its perfectly valid to just be a user and not contribute
00:20:36 <ant-x> mjp, no contribution -- no complaint.
00:21:02 <mjp> is that an offical rule of the freebsd project?
00:21:06 <mewt> i also like it, i can't yet evaluate the difficulty of each proposed change here but running any WAN-facing freebsd i probably should put it on to-do...
00:21:15 <mjp> or some BOFH quip from the 90s?
00:21:52 <ant-x> mjp, I think it is common sense. And of course, reporting bugs in the tracker counts as a contribution.
00:22:22 <LXGHTNXNG> do we have literally an moderator on deck right now
00:23:07 <mewt> i will agree some of the listed things are not really "bugs" per se
00:23:12 <mjp> if you read the article. many problems have been reported to the project, and ignored? how would creating a bug report for an ignore bug report help?
00:23:40 <mewt> like, if you have configured swap not to be encrypted, and it's not encrypted, that is correct behavior for the setting
00:23:51 <LXGHTNXNG> also you have included your X account name at the top of this page of yours. in 2026. that puts you in the lunduke set
00:24:00 <mjp> i'm not attacking the people or the project, but I think an honest conversation and response is warranted
00:24:20 <mjp> encrypted swap is what i would consider one of the lesser problems raised here
00:24:21 <ant-x> mjp, a bug report /will/ help, because it will stay open and sore the eyes of the developers.
00:24:23 <mewt> (this is a recommendation i will probably take)
00:25:12 <mewt> yeah, was first example, not necessarily most important. i just mean reporting as bugs seems wrong for some of them, so I wouldn't know where it would be considered constructive to raise the issue etc etc
00:26:03 <mjp> i don't see how making developers have even more sore eyes than they already do would help them when they are already overwhelmed and overworked
00:27:07 <mewt> now i'm a bit confused, what are you advocating if not for the issues to be fixed?
00:27:19 <ant-x> mewt, report /any/ problem to the bug tracker. Mine was not a bug, either: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941> .
00:27:31 <mewt> interesting, ok
00:28:20 <LXGHTNXNG> mewt: basically telling us to stop using freeBSD while advertising his (he's a he. i just know it. no woman writes a web like that and is also openly christian.) website with linux hardening tips to us.
00:29:08 * LXGHTNXNG sets a stopwatch
00:30:03 <mewt> hmm
00:30:54 <mjp> most of the article touches on more than "bugs" suitable for reporting in a tracker, they touch on the stated priorities and goals of the project vs actual reality on the ground, it needs high level evaluation and intevention
00:31:32 <mjp> LXGHTNXNG: if you are talking about me, you are making some very bad assumptions and are not good at trying to doxx people
00:31:42 <LXGHTNXNG> I'm not interested in doxing you.
00:32:06 <mjp> I don't even use X btw, so not sure who's X acct you are talking about?
00:32:44 <LXGHTNXNG> We're assuming that you wrote the article because you passed it us without any indication that you got it from somewhere else.
00:32:59 <mewt> the author is not mjp i don't think, the author is a name i've seen around as an arch maintainer before
00:33:17 <LXGHTNXNG> blakkheim iirc
00:33:19 <mewt> yes
00:33:41 <LXGHTNXNG> for some reason there's some negative emotional valence stored against tha name in my memory banks but I can't know what it is
00:33:56 <LXGHTNXNG> okay. mjp you're forgiven, but all of my comments apply to blakkheim
00:34:51 <LXGHTNXNG> consider the source before you send things
00:34:55 <LXGHTNXNG> that's all I will say.
00:35:32 <mewt> i think my comments on the Xitter profile are off topic, i do find it a bit off-putting. i'm willing to entertain the recommendations given anyways
00:36:00 <mjp> LXGHTNXNG: you (no one else, not 'we') made wrong assumptions. I have not done anything wrong, i dont need your forgiveness. maybe ease up on the ad hominems though?
00:37:08 <LXGHTNXNG> unforgiven then. and ignored
00:43:14 <ant-x> mjp, try the mailing lists with those higher-level concerns.
00:47:47 <mjp> I just realised today that the article was first published over 3 years ago
00:49:40 <ant-x> I doubt lots all of the problems mentioned in it are fixed now.
00:50:07 <mason> Oh, hm. blakkheim used to be a regular in here, and was a FreeBSD person, but it was years ago. Anyway, most of the things in that article can be taken as hints for how to configure things. I think there are things in there worthy of being formal bugs, but it'll take some research. Not everything he says there is valid.
00:50:31 <mason> IIRC, he was, among other things, the first audio engineer for BSD Now.
03:00:10 <siracha> o
04:49:44 <Koston> well, this is novel. my small router PC likes to f*ing REBOOT randomly when a network cable is physically disconnected O_o
13:23:05 <jmnbtslsQE> mjp: to be honest, as a random user/admin, i think your overall stance is reasonable, but that article if you look more deeply into some items they're exagerated, and many of the issues relate to many years ago and are no longer applicable
13:23:49 <jmnbtslsQE> but i think it's good for everyone to fundamentally reconsider and re evaluate their security in the current era, with what's happening with AI
13:24:41 <jmnbtslsQE> (to what you saida bout the publish date, yea i think it was quite some years ago that it was published)
13:24:42 <vkarlsen> RoL, reboot on lan
13:32:07 <Koston> jmnbtslsQE: I recall first seeing this rant years ago, like a decade or more - "freebsd defaults are insecure". at least back then it was too far detached from objectivity to be taken seriously by anyone except those who already had something against freebsd and wanted to reinforce their stance
13:33:36 <hodapp> and "$project owes me something, I would like to speak to a manager" reaction rarely gets anywhere
13:42:07 <Koston> yep, there's a curious illusion among users and many devs too that having more users has any intrinsic value
13:56:35 <CrtxReavr> I'm at 13.4-RELEASE-p1 on this one box. . . can I build & install 14.x, or should I stop at a later 13.x first?
14:00:39 <ivy> CrtxReavr: if you're using installworld, you should be fine to upgrade directly.  if you're using freebsd-update, upgrade to the latest 13.x release and make sure you have all freebsd-update errata installed
14:48:11 <CrtxReavr> bah
14:48:16 <CrtxReavr> So rusty on this. . .
14:49:34 <CrtxReavr> So according to ./sys/conf/newvers.sh I have a 13.4-RELEASE-p5 tree.
14:50:43 <CrtxReavr> How do I get it to 14.4-R in the age of git?
14:51:25 <CrtxReavr> There's also this ./stand/common/ tree.
14:52:38 <jmnbtslsQE> is it already a git repository? you could git pull then checkout the git tag for 14.4 release
14:52:38 <nxjoseph> is it a git-cloned tree? /usr/src. what does git status say?
14:52:55 <CrtxReavr> It is a git repo.
14:53:02 <CrtxReavr> er - git clone
14:53:30 <nxjoseph> try this - git checkout releng/14.4
14:53:57 <nxjoseph> also `git pull` to update
14:54:30 <CrtxReavr> git status: https://termbin.com/5ooe
14:55:16 <nxjoseph> i see
14:55:24 <nxjoseph> you seem to have modified some files, is that you or freebsd-update done it? probably the latter.
14:55:26 <CrtxReavr> # git checkout releng/14.4
14:55:26 <CrtxReavr> error: pathspec 'releng/14.4' did not match any file(s) known to git
14:55:48 <CrtxReavr> nxjoseph, that was the patch for the recent dhclient RCE.
14:56:00 <nxjoseph> Ah I see, thanks
14:56:10 <nxjoseph> git pull origin releng/14.4
14:56:11 <nimaje> hm, try  git fetch  first
14:56:35 <CrtxReavr> hehe
14:56:42 <CrtxReavr> Can we get an agreement on commands?
14:56:52 <nxjoseph> all sort of works the same :D
14:57:34 <CrtxReavr> 'git pull origin releng/14.4' is 'Receiving objects'
14:58:18 <CrtxReavr> Half way there.
14:58:24 <nxjoseph> Good
14:58:57 <CrtxReavr> 'resolving deltas'
14:59:22 <nimaje> git pull is git fetch + git merge, it brings your local branch up to date too (but I think in this case it makes a mess, because your local branch is releng/13.4 and the one you are pulling is releng/14.4)
14:59:40 <nxjoseph> nimaje, right, thanks
15:00:43 <CrtxReavr> https://bpa.st/KMUQ
15:01:14 <CrtxReavr> Just follow those three commands, or. . .
15:01:17 <nxjoseph> i believe git checkout should work now - git checkout releng/14.4
15:02:36 <CrtxReavr> nimaje, you have input on that?
15:03:44 <CrtxReavr> nxjoseph, that based on what you saw in my bpaste link?
15:03:50 <nxjoseph> yes
15:04:18 <CrtxReavr> error: pathspec 'releng/14.4' did not match any file(s) known to git
15:04:32 <nxjoseph> hmm, git checkout origin/releng/14.4
15:04:59 <CrtxReavr> error: pathspec 'origin/releng/14.4' did not match any file(s) known to git
15:05:10 <CrtxReavr> I think I'll try those three commands.
15:05:15 <nxjoseph> :/
15:05:40 <nxjoseph> can you share output of git branch -r
15:05:55 <nimaje> git switch  is a bit nicer there as it only takes branches, so git can't confuse if you meant a branch or a path
15:06:13 <nxjoseph> hmm, maybe try switch then
15:07:05 <CrtxReavr> https://termbin.com/1qyzz
15:07:41 <nxjoseph> thanks, it seems like the pull command didn't work or what? :/
15:07:53 <nxjoseph> maybe nimaje can help better, sorry
15:08:17 <nimaje> probably the  fetch  part of the pull didn't happen then as it detected it can't put the branches together
15:08:21 <CrtxReavr> The three commands from the "hints" I pasted compeleted without error or output.
15:09:13 <CrtxReavr> nimaje, 'fetch part of the pull that didn't happen'?  How do I do that.
15:11:21 <nimaje> try  git fetch   and if that doesn't give you the releng/14.4 in  git branch -r   then try  git fetch origin releng/14.4
15:12:16 <CrtxReavr> 'k
15:12:42 <CrtxReavr> 'git fetch' running.
15:15:26 <CrtxReavr> branch -r still showing origin/releng/13.4
15:15:52 <nxjoseph> > then try  git fetch origin releng/14.4
15:16:25 <CrtxReavr> Okay, apparently this is a mess: https://bpa.st/7PUA
15:17:09 <nxjoseph> sorry for the bad experience
15:17:18 <CrtxReavr> Dont' appologize.
15:17:35 <CrtxReavr> Should I 'rm -rf /usr/src/*' and start over?
15:18:55 <nimaje> hm, what does   ls .git/refs/remotes/origin/releng   say?
15:19:26 <CrtxReavr> 13.4
15:23:08 <CrtxReavr> When I ran 'git fetch' it did print:
15:23:09 <CrtxReavr>  * [new tag]                 release/14.4.0-p4           -> release/14.4.0-p4
15:23:16 <CrtxReavr> Amonst lots of other output.
15:23:58 <nimaje> hm, strange what is configured as origin in  .git/config  ?
15:24:30 <CrtxReavr> https://termbin.com/8dlh
15:25:01 <nxjoseph> oh, i think fresh start might be better :p
15:25:12 <nxjoseph> it seems to be configured only for the specific branch releng/14.3
15:25:35 <nxjoseph> i am not that pro to manually edit .git/config
15:25:57 <nimaje> try changing that to   fetch = +refs/heads/*:refs/remotes/origin/*   instead of hard coding 13.4 there
15:25:58 <CrtxReavr> nimaje, you concur?
15:26:42 <nxjoseph> hmm, hope that fixes it
15:26:57 <CrtxReavr> Like this: https://termbin.com/v97s
15:27:25 <nimaje> yes
15:27:39 <CrtxReavr> Oh, should I nuke that [branch "releng/13.4"] stanza?
15:29:06 <nimaje> no, you can leave that, it just tells git that your local releng/13.4 branch comes from the one from the remote origin
15:29:27 <CrtxReavr> Okay, so now what - git fetch again?
15:29:56 <CrtxReavr> git fetch origin releng/14.4
15:29:59 <CrtxReavr> That one?
15:30:03 <nimaje> yes
15:30:42 <CrtxReavr> https://bpa.st/4TEQ
15:30:58 <nxjoseph> cool!
15:32:30 <nimaje> now   git switch releng/14.4   should create a local branch releng/14.4 from the one from origin I think, if it doesn't try with -c
15:32:30 <nxjoseph> i think it's time to switch/checkout now
15:33:33 <CrtxReavr> Griping about the patch to sbin/dhclient/dhclient.c
15:35:09 <nimaje> ah, yeah, there was that. What patch is that? do you still need it?
15:35:24 <CrtxReavr> RCE in dhclient
15:35:30 <CrtxReavr> Just last week.
15:35:43 <CrtxReavr> Actualy, maybe a couple weeks ago.
15:36:16 <CrtxReavr> Do I checkout releng/14.4 or origin/releng/14.4 ?
15:38:47 <CrtxReavr> I'm gonna try just releng/14.4
15:38:52 <CrtxReavr> git checkout releng/14.4
15:39:02 <nxjoseph> good luck! :)
15:43:01 <CrtxReavr> Switched to a new branch 'releng/14.4'
15:43:13 <nxjoseph> congratz!
15:43:32 <CrtxReavr> Can I start building?
15:44:42 <heston76> Does git status show you are up to date?
15:45:32 <CrtxReavr> https://termbin.com/z5bz
15:45:45 <nxjoseph> > Your branch is up to date with 'origin/releng/14.4'.
15:45:56 <nxjoseph> it seems so.
15:45:57 <CrtxReavr> Bitches about an old kernel config file, but I guess that's fine - gonna update that anyways.
15:58:51 <CrtxReavr> so this is a remote upgrade. . . should I install and boot the the new kernel before doing installworld & mergemaster, or should I be okay to do them both together for the first boot?
15:59:36 <CrtxReavr> feels like 13.4 to 14.4 is a big leap.
16:01:23 <kevans_> you will want to be booted into the new kernel before installing world, yes
16:01:45 <kevans_> otherwise things will be quickly hosed on the running system and it'll be considerably more annoying to work through the remaining steps
16:10:41 <CrtxReavr> kevans_, even though my only access is via ssh?
16:12:36 <kevans_> CrtxReavr: maybe especially because your only access is via ssh
16:12:57 <kevans_> userland will almost certainly cease to function as soon as installworld is finished, if not in the middle of it
16:35:52 <skered> I get the feeling that my env. is corrupt some how.  For the past week buildworld buildkernel has been failing with from what appears to be may failing bison and/or crunchgen mainly resuce.mk.  I don't think it's -j issue or WITH_CCACHE_BUILD issue.  yet it always errors.
16:36:14 <skered> I see from ci.freebsd.org the build of main and 14.4 are fine.
16:36:24 <skered> So I'm guessing it's something on my side.
17:37:35 <CrtxReavr> How's it failing?  sig11?
17:42:56 <skered> CrtxReavr: https://gist.githubusercontent.com/derekschrock/548a8271f8002eabb9cb9b5df8e470ee/raw/9a7918cc27b33c1afa4bc576de353d15fbd1e0d1/gistfile0.txt
17:43:15 <skered> It seem to between that and crunchgen error 1
23:19:33 <kerneldove> o/
23:22:21 <kerneldove> i'm getting back into server stuff, got a freebsd server installed. now i'm trying to get bhyve-vm up and running. i have a guest installed and running but it can't get network access. i realized i don't have a bridge created and bhyve-vm is configured with switch_list="bridge0", type_bridge0="manual", bridge_bridge0="bridge0", so i gotta create my
23:22:21 <kerneldove> own. i remember in the past there was a lot of conflicting info on whether the vm host should keep its ip on its interface, or if the ip should be moved to the bridge interface. any guidance greatly appreciated, i want to make sure to do everything right this time
23:29:43 <kerneldove> "To  allow  the  host  to	 communicate with bridge members, IP addresses should be assigned to  the  if_bridge  interface	 itself,  not  to  the bridge's	 member	 interfaces." (https://man.freebsd.org/cgi/man.cgi?query=bridge&sektion=4&manpath=freebsd-release-ports) but then "The bridge(4) interface doesn't need an IP address."
23:29:43 <kerneldove> (https://forums.freebsd.org/threads/bridge-configuration-confusion-or-my-understanding-of-bridge-use.86747/post-584354)
23:29:46 <ivy> kerneldove: the IP address should be on the bridge interface or a vlan subinterface of the bridge, not on a member
23:30:51 <kerneldove> so was SirDice wrong there or am i misunderstanding something?
23:34:18 <ivy> he's correct to say it doesn't *need* an IP address.  but if you want the host to have an IP address in the bridged subnet(s), that IP address goes on the bridge
23:35:37 <kerneldove> my lan is 10.1.1.0/24. my server is 10.1.1.15, and the vms will use 10.1.1.16-19. what are the "bridged subnet(s)" there?
23:35:47 <kerneldove> sorry, my lan's subnet is*
23:36:13 <ivy> 10.1.1.0/24 is a subnet
23:36:27 <kerneldove> and that's the same as "bridged subnet"?
23:37:14 <ivy> when i say "bridged subnet", i just mean a subnet with traffic going through the bridge.  does traffic in 10.1.1.0/24 go though the bridge?  then yes
23:37:35 <luser> I'm assuming ivy means: if the server interface is igc0 and typically gets the IP address 10.1.1.15, then you'd assign that IP to bridge0 and igc0 no longer gets an IP.
23:38:49 <kerneldove> and igc0 becomes a member of bridge0
23:38:50 <kerneldove> ok got it
23:39:01 <kerneldove> tyvm for clearing the confusion for me
23:39:04 <luser> kerneldove yes, I forgot that bit.
23:39:38 <kerneldove> my server has 4 phsyical ports that i make a lagg0 over and assign an ip to. i assume that i make lagg0 the bridge0 member and move the ip assignment to bridge0, correct?
23:40:25 <luser> Yes.
23:40:59 <kerneldove> ok thx a lot ppl