Macer: truenas got forked into zvault and their webgui might appear as a port for freebsd but it's all wip

oh no kidding.

they're on 13.5? is that in line with freebsd?

13.5 is supported until 2026

getz: That would be interesting.

I might actually prefer that as opposed to it being it's own installation.

i would too but i don't see it in the ports tree or in pkg

that doesn't really sound like something that would be possible unless they were running it on a specific version of fbsd ... i'm sure there are a lot of nuts and bolts there. i liked what they were doing during the 9 to 10 era where they were concentrating on an api and a cli for freenas but then things kind of went backwards

once ix announced scale though the writing was obviously on the wall regardless of their rhetoric

i think i only went a version or two into truenas after the name change before i decided to just get rid of it and use vanilla fbsd instead for the nas

Macer: It hasn't been released yet. If that does come to fruition, it'll likely be a ways down the road.

but Kris Moore of iXsystems opened an issue with that release, claiming that it contained iXsystems' intellectual property, and the zVault project withdrew the ISO in response ... makes me wonder what license it was using now

Macer: Yeah. That was pretty surprising to see.

I thought TrueNAS was open source? I was dead wrong.

wasn't freenas opensource?

FreeNAS was, yes.

yeah lol. maybe that's the real reason for the name change

That could very well be.

And, as far as I know, NAS4Free (for of FreeNAS) was also open source.

So, I'd imagine whatever the new fork of NAS4Free (EnigmaOS or whatever?) is also open source? Dunno.

But, I'm really looking forward to testing zVault.

The operating systems include components released under a proprietary license, GPL and BSD licenses.

well how about that

Which proprietary license? Does it say?

it doesn't. that was wikipedia which only lists it as "BSD licences"

Hrm.

Companies will always find a way to cause issues

well i mean in the case of truenas it was more of just a nice webui for things added into fbsd wasn't it?

with some middleware to facilitate it?

Mostly. That middleware does do a lot of things, though. I'm guessing that's where some or most of their proprietary stuff is.

And, it does work well. It's definitely a tad bloated for my needs. But, it looks nice.

i'd say it worked 'well enough'

i'm sure it worked better on ix hardware

it definitely left a lot to be desired. and bug reporting was pointless at some point in time.

I've tried both iX hardware and just standard SuperMicro and such. I didn't really notice a difference.

the chart showing where the bad disks were seemed like it would be a nice thing to have. especially with the way it named disks.

there were like 3 different identifiers if you had a disk die in non-ix hardware

most people just add labels nowadays in line with their nas on where the disk is that breaks

You talking the gptid stuff?

i know a few times i had an issue finding where a dead disk was

i think it's more of a zfs thing isn't it?

it's been so long but i can't really remember where you did the labeling. i'd have to look it up. at the time it was kind of a big deal for me when i swapped to fbsd from (then) truenas

On current, non-iX hardware, it's just gtpid.

You can find the disk info with part.

gpart*

if the disk is dead?

Well, no. But, you can record the disk info any time and keep it until it's needed.

oh i guess it is a gpt label

i vaguely remember having to do something with zfs though to get them to show

Although, I don't even do that. I just check which disks are alive and swap out out the one that doesn't show up. lol

yeah. but then you're doing process of elimination

Yep.

vs just doing a zpool status and seeing "dead... used to be gpt/F01-03-SEAGATE-SERIAL...

"

As long as there aren't a bunch of dead disks, it only takes a moment to figure out.

That report exists in non-iX hardware TNAS.

in truenas it was a little different. one status screen would show one method of identification... another would show another. it was kind of messy

Ah. I gotcha'.

i definitely had a couple of times where i was going easter egg hunting for a bad drive

I can see that.

i also bumped into issues with detaching a hot spare because of a python error and reported it as a reproducible bug which was ignored because i didn't send them that giant log

so it was nofix.. i ran into a few things that were easily reproducible that had that issue.

overall though it isn't bad. nice interface for sure.

I actually recall having some kind of python error report that I submitted and it also being a nofix. Cannot remember what it was, but, yeah.

For the most part, it works as intended. With any luck, zVault will be better about things like that.

I'm very excited about that. I noticed the register did a nice article. I ended up moving to vanilla FreeBSD.

rtj: I still have some TNAS systems floating around. But, without zVault, I was planning on migrating them to vanilla FBSD in the future.

There's not a chance I'm moving to Scale.

I've had a FreeNAS mini from ix over ten years. Before that I ran nas4free I think on a poweredge.

I guess the hype is what sells.

I suppose.

Although, even in the #truenas channel, there's a lot of Core users that feel the same way. No one wants Scale. Most original TNAS users *ONLY* used it because it was FBSD-based.

If I had to guess, iX will probably lose around 33% of it's users once they drop Core.

People have been jumping ship for a while now.

I've never understood why people don't just run straight FreeBSD for the purpose.

mason: Because multi-administration usually requires ALL admins feel comfortable. :(

Even the mention of FBSD as a NAS storage at my ${JOB} scares people. I say "TrueNAS" and no one bats an eye. Web UI, easy to use, and not a notion that it's FBSD.

You nailed it.

I completely replaced a few VMware and Proxmox hosts with FBSD+Bhyve and it's been seamless. In fact, one person even mentioned that things were running faster on a few of their VM's. "Keep up the good work!"

If I told them what I'd done, I'd probably be fired. But, I'm gonna let it ride out until someone notices.

:) yes it's rock solid

When they do, I'll tell them about the user's praise and they can kick rocks with their anti-BSD, scaredy-cat BS.

Not to mention the VM host resources have dropped dramatically. Like, 36% on average. That's pretty incredible.

God forbid someone learns some commands, though! "Where's my fancy interface!?" Piss off!

I've been overly impressed with Bhyve. I'll never look back.

Bhyve looks interesting, first I'm hearing of it. Do you just manage everything from the command line or is there some sort of gui you use?

rmatte: I only use command line. But, I am using sysutils/vm-bhyve as a command line kind of "shortcut" interface to Bhyve itself.

Super easy.

nice

I did hear someone was attempting (or maybe already did?) to create a gui for Bhyve. I think it was related to cbsd in some way? I dunno. I haven't tried it or looked for it (yet.)

bhyve.npulse.net <--- this is a popular one apparently

vm-bhyve gives you the "vm" command with all kinds of options. Man page is solid. It does everything I need.

I mostly just use containers nowadays.

rmatte: Interesting! I'll have to look into it.

mason: Instead of VM's or instead of jails on FBSD?

Also, are you using containers on BSD? Podman or something?

ek: Instead of VMs. I do LXC containers set up like jails on Debian, and Jails on FreeBSD.

mason: Gotcha'.

I just use docker personally

Dang. I've had to use docker quite a few times and I wanted to kill myself.

lol, I'm just used to it at this point

Don't get me wrong. It's easy to deploy stuff. I get that. But, man... I did not like the command line layout.

Or the command output layout.

And, most certainly, did NOT like the networking setup. That was nearly impossible to troubleshoot.

yeah, the networking stuff is quite the learning curve with it

"Here's 18 randomly selected (and might already be used) RFC1918 addresses on this system. And, we'll go ahead and include 296 IPTables rules so this little container can reach out for updates! Congrats!"

Oh... Kill me now.

lol

yeah, and you need to make sure that the addresses don't overlap with existing network space within your org. I have to override them in the config when we setup docker on hosts at work because of that

but I'm so used to all of this stuff now that it's pretty routine for me, even if something breaks, I've pretty much seen it all

rmatte: Yep. That's exactly my point. Vendors would supply something, we'd deploy. Have uncountable network issues in the lab due to overlap. And the troubleshooting was so insanely difficult.

yeah, it's definitely a fun time

Meanwhile, a jail is like 5 commands and I'm done. Someone just gimme a jail in tgz and I'm moving on to more important work. :)

Looking forward to using sparse zvols in Bhyve.

I haven't used FreeBSD since version 8 or 9, I forget which. Used to be my main OS back in the day. Been planning to throw it on a VM and mess around with it but haven't gotten around to it yet. Jails don't really have the concept of images though like docker does though do they? They didn't back in the day when I used to use them.

rmatte: You can build jails from ZFS snapshots and ship those around.

ah ok

Never used this one. I think they talked about it on BSDNow github.com/alonsobsd/bhyvemgr

Yeah. There's been quite a few projects mentioned as far as Bhyve interfaces. I'm certainly curious, but I also don't need them at the moment.

It will certainly be more interesting once Bhyve has the whole redundant host/VM migration/cluster thing going on (I'd imagine somewhat soon-ish.)

Then, Bhyve will be my recommendation even in corporate settings. And, they will most certainly require a gui of some type.

Just to make happy the masses!

Nice anything to get more users using it is good. Yes 100% lol

Absolutely. And, the proof of performance will be easy to present. Without any proprietary requirements, thus far, FBSD+Bhyve wins.

ek: wins vs what?

SponiX: Wins vs VMware and Proxmox (which are my ${JOB}'s go-to standards.)

I'm hoping to experience similar also "soon"

Well, I will mention that importing pre-made provided, non-UEFI linux VM's can be troublesome. The grub stuff can be tricky.

SponiX: I think you'll be pleasantly surprised.

right now though my FreeBSD vm hosted on Linux has an nvme ssd. And my FreeBSD bhyve host doing a FreeBSD vm is on a standard SSD. So kinda of an apples to oranges situation

Oh, and the chip on the Linux rig also has a few more cores

so, at present Linux qemu/kvm wins. But it isn't close to fair

SponiX: Are you using the nvme option on the Bhyve host for the VM?

I'm certainly not saying a non-NVME host will perform the same as an NVME host. But, I'm definitely curious to see what the same Bhyve disk driver kicks back on the same host.

For example, I had Proxmox on an SSD host previously and disk I/O speeds and usage was pretty decent. No issues.

ek: Okay, for my FreeBSD vms right now the Linux Host and its vm are on NVME. The FreeBSD Host and its vm are on a regular sata SSD

so as I said not really "fair" at all

NVME gets like 2.5GB/s and the sata SSD is like 500MB/s

Migrated to FBSD+Bhyve on the same host and with the same VM's (using the Bhyve nvme disk option) performs such faster and with less noticeable I/O wait.

SponiX: Yeah. I understood what you were saying. I'm just hoping at some point in the future you can compare apples to apples instead of apples to oranges. :)

I'm very curious what the difference may be.

well, I also recently did some Desktop oriented performance tweaks to my FreeBSD and it made a HUGE difference

SponiX: Like what?

Haven't re-ran any of the test with these in play yet

SponiX: And, also, is the FBSD you made the changes on a VM or metal?

@mason I can post my loader.conf rc.conf and sysctl.conf if you like

SponiX: sure

ek: the I/O and Desktop performance tweaks have been doing on my FreeBSD 14.2-RELEASE host. I've not done any of these tweaks to any of my FreeBSD CURRENT vms yet

loader.conf -> termbin.com/1zeh

sysctl.conf -> termbin.com/04d5

rc.conf -> termbin.com/q8t3

ty, looking

SponiX: Gotcha'. This is a desktop that's also running VM's via Bhyve? (I'm just guessing based o the loading of "vmm")

these configuration files also include a bridge0 device for use with my vms

Got it.

SponiX: Hrm, I need to learn about what some of that is. autobridge_interfaces for instance.

ek: Yes, FreeBSD 14.2-RELEASE host doing a bhyve guest vms of 15-CURRENT

@mason I searched the interwebs for that bridge device config. Out of about 5-10 documents of others, none of them worked completely on their own for me. I ended up just mixing and matching and testing until I got lucky

SponiX: You have some duplication between loader.conf and rc.conf

@mason Yeah, I'm aware

there are probably some dupes within same config files also lol

I hit a weird issue with bridging over the weekend.

mason: Care to elaborate?

the Desktop and I/O tweaks in place now cut my Video load time for 4K and 1080p Porno in half or better. Seriously

Faster, stronger porno is always a good thing.

prior the load and seek times were so bad I was actually switching over to my Linux rig to watch stuff

Now it is on part or better than the Linux box

On par or better

ek: I guess it wasn't all that weird, but I wasn't able to force a route to a non-matching IP. I thought there was a way to do that - for instance, say, arbitrarily, that, that -net 10.0.0.0/24 going through -face foo0 even if foo0 doesn't have a 10-net address.

ek: Tried to use my general wiki.freebsd.org/MasonLoringBliss/JailsEpair plan and it fell over hard.

SponiX: Awesome! Glad to hear you got that performing nicely.

mason: Ah, okay.

mason: What was the resolution that you came up with?

Because, I'm not sure why that wouldn't work?

ek: I lifted an IP address in the required range and set it on my host-side epair.

How does one make a wiki.freebsd.org page?

farhan: Sign up for an account and you can start making them.

farhan: Best bet is to join #freebsd-wiki and ask.

I keep wanting to put my FreeBSD Host on CURRENT also. BUT, I really have no need for it, and I enjoy 14.2-RELEASE and its pkgs

Words are HARD

stupid English

mason: Ah! Okay. That makes sense.

SponiX: I have quite a few hosts running -CURRENT and have had no issues yet.

However, they are not production or anything and not running anything crazy or really out of the ordinary (mail server, web server, database, etc...)

I very much want to figure this out though. Linux has rp_filter and I have to think there's some equivalent for FreeBSD.

But, -CURRENT sure seems solid so far.

mason: What does rp_filter do?

ek: reverse path filtering - it's what requires an interface and a route to be related.

Only mention I'm finding is forums.freebsd.org/threads/disable-rpf-rp_filter-on-interface.72880 and that's not a hopeful mention.

PF has the option for unicast?

Maybe more. I remember reading something about that a while back for a v6 video stream test things I was working with ${JOB}

Err... Hang on. I'm sure I can find it.

URPF

*uRPF

wtap missing a man page...

Maybe sounds like what you're looking for?

ek: Except, that looks like pf just uses it as a way describe a packet, rather than overriding the kernels' unwillingness to pass packets.

...from the description at man.freebsd.org/cgi/man.cgi?pf.conf(5) anyway.

But yeah, that's what I want to turn off and I figured I could, but now I'm not quite sure.

Yeah. It'll perform differently.

farhan: I'm not familiar with wrap. Sorry. But, feel free to report the missing man page (or provide one?) on bugs.freebsd.org

s/wrap/wtap/

Yeah, I might have to...if I get stuck on my current project, I'll take a first cut at the man page.

The diff to get it to build is in review..

Well, I wish you the best of luck!

farhan: Languishing in review, or getting attention in review?

I believe it is getting attention, but I'll ping you if it stagnates

Have another diff that I need to ping folks about, updating something in net80211

farhan: Well. I've got no commit bit, but I could suggest places to be active to get attention on it.

Not that I seek it, but how does one get a commit bit?

farhan: Get involved: freebsdfoundation.org/contributing-to-freebsd-as-a-programmer

I don't think there's an explicit process like what, for instance, FreeBSD has.

s/FreeBSD/Debian/

It's always seemed to me if you have consistent and correct patch submissions, it's kind of a shoe-in for committer status. And, obviously, the more trustworthy committers FBSD can get, the better!

security.opensuse.org/2025/05/12/screen-security-issues.html "FreeBSD still uses version 4.9.1. If Screen were to be upgraded to 5.0.0 then FreeBSD would be affected as well, since Screen is installed as setuid-root by default."

MRniceMR on #freebsd-irc is sending people bat files

nice

wsky: for free?

:D

I do wonder, am I the only one who's bother by our 9 months life cycle?

antranigv: for having a baby?

I wish it was at least a year, or maybe if there was a way to deploy and update -STABLE better and faster.

SponiX well, that one I would prefer if it was shorter, but no I'm talking about the FreeBSD release cycle.

antranigv: you have looked into pkgbase?

SponiX I have, yes. while pkgbase is awesome and stable now, the tooling around it is still missing. For example, will we have base.txz in the future? will I be able to migrate a jail to pkgbase if it was installed via base.txz? which pkg path is what? etc. basically, some docs are just missing.

well, it is a solution for that problem. even if it isn't fully implemented yet

I just learned that -STABLE has pkgbase.

I mean, a pkgbase repo that is.

YES

that is what I am saying lol

you just changed my life. lemme check now. I guess I can't run -stable jail on -release kernel. I might need -current host.

pkgbase is the future

+1

I'm hoping by the time 15 hits release it will have bectl integration like freebsd-update has now

ah, I see

I wonder if pkg audit is integrated yet

I'm a bit excited. I got a 20 core Xeon to replace this 16 core for only $55 USD

and a 2TB NVME on the way

nice

only FreeBSD on the host?

On this machine yes. It is 14.2-RELEASE Host, and bhyve 15-CURRENT build vm

debating going 15-CURRENT on the Host when the nvme gets here

right now I like running release though because I get great uptime. on CURRENT or STABLE with pkgbase I end up applying updates frequently and it is best to reboot to apply them

antranigv: so you are on 14.2-STABLE?

SponiX I am on 14.2-RELEASE, but I want to run 14-STABLE. I will probably use bhyve for testing for now.

why the desire to be on STABLE?

STABLE runs fine, I am using STABLE in production since 2001

mzar: for your needs. what makes stable more desirable vs release ?

why the desire to be on STABreset

SponiX: the ability to add own patches, apply fixes quickly, and, what is most important: simplified and faster update

some people run CURRENT in production, it's even better, but it has one drawback: ABI instability

so to follow, sometimes whole software has to be reinstalled after upgrade

mzar: aren't those advantages of building from source rather than using stable? you'd get most of that with a releng branch, i think

the main advantage of stable is you don't need to apply your own patches in the first place since someone else already did :-)

ivy: everything is built from sources, but I like to be in controll of STABLE and sometimes do MFCs on my own schedule

antranigv: base.txz is not going away, yes you can migrate an existing system/jail with pkgbasify, although this is still very experimental, yes some of the docs are still lacking but a lot of this is being done at the last minute, i expect it to improve in the next couple of months

Anyone using KDE 6.3.x on Wayland?

I'm constantly have 3-5 second freezes on X11 with KDE, and I'm pretty sure with XFCE also

re: "base.txz is not going away", apparently we'd like it to go away but it won't be happening soon (certainly not for 15.0R). but it's kind of redundant since you can just extract the packages to get the same files

hrmph. trying to zfs send/recv from my zroot to back it up to my... non-zrooty-spinny-rust-pool, and I want to preserve everything on zroot (so I am using -R), but problem is that means 'canmount' is set all over and then the backup is subsequently being mounted all over top of all the same mount points for everything in my zroot

I can add '-o canmount=noauto' to zfs send but then it's only set at the top level and none of the derived datasets inb it

hodapp: Just create a different dataset on the receiving side and send there instead?

Ex: send zroot to server:zroot/backup or something.

ek: this is already into a different dataset, but this doesn't change the mount points already set - they're still /home and blahblahblah

the issue isn't which dataset they're in, it's the mount points & canmount received

I haven't tried this myself, but, if you change the mountpoint setting on the recv side, does it keep that change after another send/recv?

AFAIK all of this is blown away with recv

hodapp: So, just change the mountpoint on the recv side during the recv using "-o".

That would seem to be the easiest solution.

ek: hm, that may work provided I've a way to easily patch those mount points back to their original values if I do need to restore

may need -x

Sure. Just use "zfs set" to change them back after a restore.

Or, when you zfs send the restore back, just change the mountpoint= back.

though it may end up with: setting all mountpoints to the same thing on multiple descendant filesystems, and still trying to mount them all

not sure how that'll go

and I am not sure if -o will work with canmount as expected since canmount doesn't inherit

As long as the mountpoints don't overlap, I'd imagine it's fine? Of course, I know nothing about your layout or anything. So, I guess give it a try and see what you can make work.

if the mountpoint is being set to the same thing across all filesystems (how else would -o work?), I don't see how it could do anything but overlap

Because you would change the mountpoint during the recv. You can change it to anything. That should ensure no overlap.

but all datasets would inherit the same mountpoint

regardless of what mountpoint I make it

On the recv side, yes.

do you mean no overlap with the zroot's mount points? I meant overlapping with each other

It should ensure no overlap anywhere on the recv side. Both zroot mountpoints and the datasets themselves.

If you backup zroot to backup/zroot/backup and change the mountpoint during the recv using -o mountpoint=zroot/backup (or whatever you want) it should place the datasets in zroot/backup (not zroot/) and mount to /zroot/backup/* and not /zroot/*)

hmm, I am likely missing something with how mount points are inherited

e.g. for zroot/var/log, its mountpoint is /var/log which is inherited from zroot/var; likewise for zroot/var/mail and so on. If I overwrite those mount points (e.g. to /zroot/backup), they'll no longer inherit, they'll all just be /zroot/backup

hodapp: How are you performing the send/recv's? What's the exact command(s)?

ek: last I tried was: zfs send -R zroot@snapshot_whatever | zfs recv -v -d -F -o canmount=noauto tank/zroot_backup

hodapp: So, I just double-checked a system I do incremental snaps and send/recv's on to a backup server and I don't have this problem.

I'm using, for example: "zfs send -RI zfs1/home@snap_1 zfs1/home@snap_2 | ssh backup-server zfs recv -Fv zfs2/backup/home"

And the mountpoints are inherited by the child datasets. If I look at the backup-server, I see the mountpoints for zfs2/backup/home are exactly that.

So, all this discussion of pkgbase since yesterday... Is it becoming the default for 14.3 or something?

It's in current now for 15 I think?

Yeah. Not going to be default in 14,x AFAIK.

Hm, and 15 is currently slated for late this year. That's actually pretty fast, all told.

mason: pkgbase will be the default for 15.0R, nothing is changing for 14.x

i think the release schedule for 15.0R is as expected based on the new release cadence, which i agree is fairly quick, but i like that

mason: lists.freebsd.org/archives/freebsd-pkgbase/2025-May/000516.html

ek: but I don't see any -o mountpoint=... in your commands

hodapp: Exactly. I don't even use that and I'm getting the expected results.

ek: this is where I started in the first place, and how I was seeing mount points like /home

ek: I suspect that your command only works as planned when *all* mount points are inherited

ivy: i got a prompt to use legacy or tradtional

ivy: i really dont think they will go all the way in 15.0R

er experimental

honestly should I said experiment to test pkgbase

cpet: we are definitely going with pkgbase in 15.0R unless something terrible goes wrong

cpet: the only thing that's really missing is proper bsdinstall support and isaac/ed are working on this atm

running a recent install snapshot it gives you the option to use tradtinal or experimental

just for now the old way won't be removed in case we get to release and discover some last minute thorny problem

would make sense to keep it that way until 15.1

ivy: I was waiting for a long time to read documentation on pkgbase and it sounds like that's being done. So, that's awesome!

that's complicated, there isn't enough room on the install media to fit both ways and we don't want to have two separate ISOs

It was kind of difficult to find info. I wanted to make sure I was prepared.

the plan, we are going with pkgbase, if some problem comes up during BETA/RC that we really can't fix, we will revert to dist sets, but that is not expected

pkgbase has been going on for years now

It sure has.

right, in 14.x it basically worked fine, we just didn't have the installer support

cpet: fwiw i also did not expect this to happen for 15.0R but a //lot// of progress is being made really quickly

pkgbase is going to be awfully nice. Not to disparage freebsd-update, but it's way out on the bell curve in terms of time it takes to analyze updates and upgrades, compared to everything else out there. Makes yum/dnf look fast, and that's worrisome. :)

so i believe it will actually happen now

mason: even the guy who wrote freebsd-update hates it :-D

I've used it quite a few times and I've never had any major trouble. So, I'd expect when it does hit in 15.0R, it'll hit the ground running hard and be widely accepted.

ivy: Haha. Yeah. I've seen him mention that many times.

btw, "CFG: pkgbase support in 15.0" - lists.freebsd.org/archives/freebsd-pkgbase/2025-May/000516.html

s/CFG/CFT

not a real fan of ML's

My only actual complaint about freebsd-update is that it can get awfully confused sometimes if you're upgrading a jail inside a host that's already been upgraded.

I'm too clueless to have real complaints about it

never had any issues with it

cpet: you don't need to use the list, you can report bugs in bugzilla

FWIW, to cope with freebsd-update getting it wrong, I learned about uname -U and the --currently-running flag. \o/

But pkgbase will obviate this.

would be nice to create jails with the bare minimum to get things running

we dont need bluetooth in a jail now do we ?

cpet: pkg -r /jail/myjail install -r FreeBSD-base FreeBSD-runtime FreeBSD-utilities FreeBSD-syslogd FreeBSD-newsyslog FreeBSD-cron FreeBSD-rc

this is exactly what pkgbase is intended to make possible

Yep. It's going to be super helpful in that regard.

blames ek

i get the feeling using pkgbase will break the system easier than the other

idea - rather than freebsd-update, make the base system a package.

farhan: that idea is called pkgbase

dstolfa: oh wow...that already exists.

dvl: could i persuade you to update freebsd/freebsd-src #1603 so i can land it, pretty please? :-)

dvl: or i will just do it myself if you're okay with that

ivy: Please proceed, I'm swamped.

dvl: ack

ivy: Thank you.

[this will be my first src commit in a long time, I think. the last one was SCSI related, about 20 years ago, related to EOF markers on tape)

ivy: do we use github??

I would be really happy if we did

farhan: yes you can submit patches to src on github, not docs or ports without prior approval though

oh wow, I use phabricator

what is preferred?

uh, complicated

I would prefer github...

if you're happy using phabricator you can keep using that, the problem with that is there's no workflow to get approved changes actually committed

but if you're working with a committer who will commit your changes, phab is fine

that's what I'm doing. I have no commit bit.

github is good for new contributors who don't really know how to get something committed on phab... but most committers prefer working with phab because the tooling is much betters

define better?

if you have someone in mind to commit your patches i'd suggest asking them

farhan: better = "exists" :-)

landing github patches is basically entirely manual right now, it's a huge pain

imp is working on improving this but it's still not great

it is convenient in the sense that the --author metadata is already there, but I guess git-arc may paper over that complaint anyways

basically, phab is better if you want people to review your change, github is better if you want your change to actually be committed

ha!

the fact we don't have one solution that achieves both of these goals is an open issue

that seems disjointed.

i think everyone agrees that the current situation is not ideal :-)

anyone know if there is a plan for use of bectl with pkgbase similar to how freebsd-update does now?

what does phab offer that github doesn't have?

besides not being owned by Microsoft?

lol

sure, but you can have a commercial account so its not a negative ownership

ie, you pay them

we don't want freebsd to depend on github, there is discussion about setting up a freebsd forgejo/gitlab/something to do this in a bit better way, but we'd still like a better workflow to ingest patches from github

I suppose that's reasonable from an independence perspective.

but I Guess its a question of how far do we want to take that? For example, should freebsd be independent of the datacenter that the servers are hosted on?

Its an arbitrary line -- and as long as we're aware of that, then its perfectly reasonable to not use github to be independent.

well, if NYI were to withdraw their support the project could move to another DC with a reasonable amount of effort

if Microsoft start doing something with GitHub we don't like...

Why do I feel like there's a rush to make FreeBSD more like all the shitty Linux distros?

this is my personal opinion, not official opinion of freebsd, fwiw. i just don't think core services like the source tree should depend on Microsoft

CrtxReavr: i don't know, why do you?

github is also annoying because it wouldn't be the first time it blocked certain countries, so contributors and users from there couldn't fetch the sources just because github got a request from the government to do something

So far I think MS has done a good job of being platform agnostic.

dstolfa: as we just found out when surveymonkey blocked Russian users...

That said, however, there's plenty of source repo platforms that interact well with git.

ivy: yeah, incredibly annoying

CrtxReavr: Some of Linux's ideas are worth emulating, no?

dstolfa: I totally forgot about that...

this is not the first time recently i've heard "freebsd is turning into linux" and i don't really understand it

And to answer your question, Ivy, pkgBase seems like a step in the linux distro direction.

farhan, don't confuse popularity with worth emulating.

Sure, but popularity is a sign of business demand.

CrtxReavr: it's really not, though. consider that commercial Unixes (Solaris, HP-UX, AIX, ...) have had their own "pkgbase" for 30+ years, we're just switching to it like they do - we're not going to split src into 200 different source trees so there's one for "df" and one for "grep" and ...

farhan, Windows is popular.

right! And windows solved some problems that others could learn from.

to me "like linux" would mean there's no "freebsd source tree", and you have to build "freebsd" from a bunch of different upstream sources like you need to do to create a linux distribution

we're absolutely not doing that and no one wants to do that

agreed...

ivy: also very different ABI stability expectations

well not sure how others feel about it, but I like pkgbase. being able to stay current without having to compile all the time is nice IMHO

Well. . . I spent a good bit of yesterday cleaning up after a pkg fuckup. . . . becuse it chose to remove a bunch of stuff, rather than upgrade it.

CrtxReavr: I'll put it this way...I suggested FreeBSD to a few teams I work with. All thought it was interesting, but it could not do some fundamental features that they needed, it could not "tap into" an existing ecosystem, even in an OS-agnostic way.

I would like to see FreeBSD improve on those areas

And I'm glad it was only user apps, and not core OS components.

as far as github and Microsoft. Have a look at their latest moves with vscode if you want more reasoning not to trust Microsoft

well, i'm sorry you had a problem with pkg and you should probably report a bug, but that was probably not intentional

this is why we want people to test pkgbase, fwiw...

And I would not consider that "chasing shiny things", but rather, chasing market demands...

the reason you don't see as many bugs with the base system is because most developers are using the current workflow of "buildworld + buildkernel + install...". if a lot of developers start using pkgbase, those issues will get ironed out before they reach you

I am specifically speaking about containerization...

it's all down to active testing as ivy says

dstolfa: +

CrtxReavr: I've had a couple failed attempts to pkgbase my 14.2-RELEASE to 15-CURRENT. But I've had it work good when I just implement it within the same branch

i guess that's one way to look at it

bah, I was scrolled up

ivy: I went back to find commit references, and didn't find anything for tape drivers, but here's what I find. Most of which I've forgotten. bin.langille.org/?24fdd3f2d0bc90ea#…uq4ununjGGbndVmG8c5nHrCYghJwoGMtHBq

Honstly. . . I feel like the ports sytem has been largely wreck.

largely what?

There's way too much of it that won't build outside of poudriere.

well, there was a lot of it that wouldn't even build with poudriere recently. that just got ironed out

portmaster should would.

Period.

A manual ``cd /usr/ports/this/that && make install clean`` should work.

Period.

does it...not?

(And it did for many FreeBSD major versions (with little exception).

I never use the ports tree

I use pkg for everything

Not when builds won't build outside of poudriere.

farhan: a fair amount of folks are like that. I do pretty much the same on my 14.2-RELEASE machine

Some of us still like to compile

CrtxReavr: what doesn't build that way if you start with a clean installation on freebsd without installing packages that have mismatched versions?

CrtxReavr: i appreciate your frustration but understand that as someone who manually installs ports with make install, you are in the minority nowadays, so... this might be a case of patches welcome

I'm a sysadmin, not much of a software developer.

cpet: I don't think that the build systems are going away anytime soon

cpet: no one is removing support for compiling anything

compiling is required to produce the binary package so obviously we cannot remove that

CrtxReavr: what is not building outside of poudriere?

That seems to change by the day.

(Maybe if the pkg build system didn't use poudriere, things would be better.)

anyone good with the basics of pf? I'm gonna do my setup with it after this next reboot

all it does is create a jail with a fresh install so not a lot of trickery there

I do it manually sometimes when lazy in a vm or so and havent had issues

Your definition of "all it does" is probably not very read world.

CrtxReavr: no, that would make everything much worse, the only reason we keep "make install" around is that too many people would complain if it was removed

not sure why we are hating on poudriere besides the horrible name. the FreeBSD Desktop Team for KDE Plasma uses it on my build vms and it does well for them

honestly it just sounds like you have mismatched versions of packages with the version of whatever port you're trying to build so it's failing. you need to ensure that the packages you have installed match the versions in the ports tree you're using

pkg are mostly great. . . until you need a non-default build option.

Yeap

tbh, i don't know how to reasonably respond to "i have an issue, i didn't file a bug, i won't provide any examples, but it would be better if freebsd.org completely changed how they build packages to fix this issue i'm having"

i'm not even sure what that change would look like. poudriere just spins up a jail and builds the port

i've done make install for ports on an experimental architecture and it worked fine so long as it had the right versions in the right places

i've not once seen it break for a port that wasn't already broken with poudriere

CrtxReavr: check out a ports tree corresponding to the package versions you have installed and your issues will go away

Sounds like a lot of non-real-world navel gazing.

understand that most "real world" freebsd users are using poudriere, because it's fundamentally a better way of building packages

i agree 'make install' from a port should work, and if it doesn't, please report a bug

but... if you are using this method of building ports, you are in a minority, you may need to put some work into making it work properly. this is the nature of a community-supported, open source platform

I liked the port master building

The standard reaction in #freebsd-ports (or #bsdports on EFnet) to such a complaint is "You should build in poudriere."

great discussion, btw really enjoying this.

CrtxReavr: yes, you should be using poudriere. but if you find a bug in make install, it's still a bug, you can report it.

This is just infuriating and I have work to do.

what doesn't build outside of poudre?

I like the way openbsd does it it's all build into ports buy the backend is perl using fakeroot

Poudriere is too complex for simple port testing

But I normally get kicked for being a troll so bleh

no one is going to kick you from here for saying you prefer some other way of doing something

it's just frustrating when people complain about something and won't provide specifics so it can be fixed

sure cpet, now this channel is liberated

cpet: there is in fact a "testport" option for pourdriere ;)

I'm just learning the basics on poudriere myself though

still can't spell it correctly most of the time

SponiX: alias p = poudriere ... or something? :P

it should probably be called poudriëre

dstolfa: well on system I can type poud->TAB

I will admit, I turned off process isolation so I can see what commands the builders are running in my vms. If it wasn't for taking a peak at their commands, I would still be lost in the provided poudriere documentations

I use poudriere but it shouldn't be this complex to test a port

SponiX: i may be misunderstanding you but poudriëre doesn't use VMs, you can see the command in `ps` on the host

commands

"ps axd" may be informative here

or i gues we're meant to spell this "ps Ad" now

kevans: does ps(1) conform to POSIX?

ivy: I have "FreeBSD Builders vms" on my Linux and FreeBSD machines. the FreeBSD Desktop Team (See #FreeBSD-Desktop) uses those with poudriere to validate that packages will build properly before submitting them to the main build boxes

I understand that poudriere itself uses FreeBSD Jails

SponiX: yes, but jails could be nested, so you can have poudriere running in the jail

I use the vms for several reasons. mainly resource segmentation

anyway, I have to run. Be back later

segmentation? jails could be limited too

mzar: well, the build team told me that I can't run a 15-CURRENT jail on 14.2-RELEASE

that is another reason for the vms

but poudriere runs build only on demand, and it's better to give it more resources to complete builds faster

ivy: safe to assume no

Poudriere is too complex for average new user to start contributing just like the doc was hell before

cpet: I mostly agree with that

SponiX: yeah, a 15-CURRENT jail userspace will be assuming a 15-CURRENT kernel ABI and API, and obviously 14.2-RELEASE can't magically be forward-compatible with 15-CURRENT

dstolfa: Yes, that is one big reason for the vm use...

SponiX: but when running poudriere on CURRENT you can have 14 and 13 jails

But uh well if I have to run my ports through that I'll do it but still

> Poudriere is too complex for average new user

it's probably not for newbies

Does an average new user even should know of and be bothered with poudriere?

I think I did something wrong during an upgrade, because bhyvectl is now failing with: ld-elf.so.1: Shared object "libvmmapi.so.5" not found

I've got libvmmapi.so.6 though

yeha but little timmy who wants to update fceu

should be able too without complexity of poudrere

cpet: this is what binary packages are supposed to be fore

Poudriere is a tool for edge-cases use: building stuff for multiple archs or to release it with different options or whatever, or building ports with custom options to get packages ready to be deployed on a fleet of virtual machines, or otherwise when it's more reasonable to build them once and deploy to multiple target systems.

most users should have no reasons to build ports from source, i realise they do, but they shouldn't

if you are updating a port most if not all commiters will ask for a poud build log

so again if little timmy wants to build port he would have to do all that

timmy can fail

so who cares about timmy

yes, nobody cares about timmy

that mentality is what me me go from maintaing 700 ports to moving to OpenBSD

go ahed cpet

I've never looked into these build systems - what exactly is poudriere?

cpet: issue command /j #openbsd && /part #freebsd

openbsd is cool, I'm sure they would be happy to have you.

farhan: it's a tool that spins up a clean build environment for you (usually a jail) and builds ports you ask it to build, producing packages

you can then pkg add those or you can serve them to your server fleet or whatever

how is that different from /usr/ports/this/that make clean?

its a clean install

it does so in a clean environment and picks up the right versions of dependencies for a given ports tree

with nothig that can intefere with it

i think its over kill but

so you don't end up building foo that depends on libbar.2.so but you have libbar.1.so installed which has a completely different interface

and you don't end up with broken software

or build failures.

ow security holes you aren't aware of. that kind of thing.

s/ow/or

the whole point of that is to build the port using the current ports

this is why mixing pkgs and ports is bad

it's nothing bad with it, only some people are bad cpet

dstolfa: hm...so, can you build versions, rather than using the base system? For example, libXXX.1.so is placed in /usr/obj/ports/libXXX.1.so and that's the version that is based on?

and same for libXXX.2.so

mzar: Yeah, I might go to CURRENT when my new nvme drive gets in

farhan: the usual confusion that happens is that you might pkg install something from a package repository and get a specific version of some library. then you want to tune a specific port and do it via make install without realising that the port's build picked up a dependency you have installed on your system, but it's actually the wrong version and then you run into issues

SponiX: give it a try

isn't this called dependency hell?

Is there some command I can run to repair the parts of base that are incorrect? my bhyve is broken after the upgrade :-(

farhan: sort of, but it's relatively easily managed through tools like poudriere and using pkg. alternatively, you manage it manually in which make install should succeed and the software should run fine

deepy: bhyve is broken? perhaps it was incomplete upgrade ?

deepy: you could try fetching base.txz from here: download.freebsd.org/releases/amd64

for your version

mzar: freebsd-update isn't letting me progress in any way :-(

dstolfa: I'm currently comparing the result of freebsd-update IDS with that, but was hoping there'd be something more automagic :')

deepy: OK, follow dstolfa's guidance then

mzar: I've ran current before. but there was a problem crashing the main build systems. and when things got resolved 14.2-RELEASE was the priority. when I did this install the meta packages for "kde" and "xfce" and so forth didn't even exist in CURRENT

I'll continue the base + IDS dance, thanks for the help both of you :-)

CURRENT is rolling release, it's probably to jump on this rollercoaster at the end of month, arround Gleb's stab-week, build system and kernel without debugging, and you will be fine SponiX

s/probably/probably best

and although my machines are setup for building packages. I normally don't tie up resources building them myself lol

OK, you can install packages for CURRENT from official repos

If I go CURRENT again, it will probably be with pkgbase

mzar: I'm aware. I've ran CURRENT on my systems before

to be honest though, I am fairly happy with my setup now. I might switch it up though

reason for resource segmentation being needed is the machine isn't 100% dedicated to FreeBSD pkg building. It also runs a Minecraft server and will be doing Plex also if I ever get that figured out (performance problems)

anyway.. gotta run again errands are calling me

I tend to update and reboot CURRENT way too much. That is a part of why I'm on RELEASE right now

hmmm... burnt with CURRENT

the trick with running -CURRENT is realising you don't actually need to update that often if tehre are not security fixes (and you can cherry-pick those to a local branch)

find a good commit, stay on that for a few months, update later

CURRENT was completely unstable and unreliable just a few versions ago. Nowadays I have 15-CURRENT on ThinkPad and I switched directly from 14-CURRENT. It's stable, works, I update it often and it consider it more stable than some Linux distros trying to be "cutting edge".

ivy: I tend to apply any system updates blindly as soon as they become available without researching them

SponiX: yeah, you should not run -CURRENT :-P

case in point, unix(4) is kind of broken right now

oh, I tend to procrastinate doing updates until I realize that my FreeBSD has been out of support since Bush was in office

Which one?

not answering that

I like the appeal of STABLE and CURRENT. But honestly think RELEASE is the best fit for my uses right now

i think with the "new" release cadence it's pretty reasonable to use -RELEASE now

you get a stable release and you get a pretty good window in which you can upgrade to the next release

WTF

CrtxReavr: why is this "wtf"? are you perhaps looking for the mtr-nox11 package?

Well. . . maybe. . . but then why does 'mtr' need CUPS?

at a guess, gtk2 probably requires it

Don't you want to print your routes on paper for later reference?

i did once print out a copy of the EDU zone file on a dot matrix printer...

I'm happy I wasn't in the same room at the time

ivy: why not run CURRENT?

regis: context? i run CURRENT everywhere including production systems

ivy: CURRENT dot matrix printer? I dunno.

SponiX: I've worked for a hosting company some ~12 years back and not updating RELEASE and keeping STABLE was based on (judge this by yourself...): users see it in phpversion() and "STABLE" looks more professionally than "RELEASE"

ivy: Hey, mee to.

is there a branch for 15-current ?

hernan604: "main"

-CURRENT is always the "main" branch

i want to install it in parallel with 14.2-RELEASE

as a 15-current boot environment

i think i can install "main" branch boot environment, but will it break if i git pull and rebuild workd and "main" has already turned 16-current

well i guess i will have to test

and activate a different environment if it breaks

hernan604: the switch from 15.0-CURRENT to 16.0-CURRENT is meaningless, it's just a version number change

so nvm

ok

it's the same branch

-CURRENT is always "main"

got it

thanks ivy