00:30:26 Macer: truenas got forked into zvault and their webgui might appear as a port for freebsd but it's all wip 00:53:32 oh no kidding. 00:54:34 they're on 13.5? is that in line with freebsd? 01:11:08 13.5 is supported until 2026 01:48:28 getz: That would be interesting. 01:49:10 I might actually prefer that as opposed to it being it's own installation. 01:54:57 i would too but i don't see it in the ports tree or in pkg 01:56:17 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 01:57:03 once ix announced scale though the writing was obviously on the wall regardless of their rhetoric 01:58:04 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 02:00:03 Macer: It hasn't been released yet. If that does come to fruition, it'll likely be a ways down the road. 02:00:12 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 02:01:10 Macer: Yeah. That was pretty surprising to see. 02:01:25 I thought TrueNAS was open source? I was dead wrong. 02:01:28 wasn't freenas opensource? 02:01:37 FreeNAS was, yes. 02:01:43 yeah lol. maybe that's the real reason for the name change 02:01:55 That could very well be. 02:02:20 And, as far as I know, NAS4Free (for of FreeNAS) was also open source. 02:02:44 So, I'd imagine whatever the new fork of NAS4Free (EnigmaOS or whatever?) is also open source? Dunno. 02:02:54 But, I'm really looking forward to testing zVault. 02:03:10 The operating systems include components released under a proprietary license, GPL and BSD licenses. 02:03:36 well how about that 02:04:16 Which proprietary license? Does it say? 02:06:26 it doesn't. that was wikipedia which only lists it as "BSD licences" 02:07:17 Hrm. 02:10:34 Companies will always find a way to cause issues 02:13:56 well i mean in the case of truenas it was more of just a nice webui for things added into fbsd wasn't it? 02:14:08 with some middleware to facilitate it? 02:16:01 Mostly. That middleware does do a lot of things, though. I'm guessing that's where some or most of their proprietary stuff is. 02:16:49 And, it does work well. It's definitely a tad bloated for my needs. But, it looks nice. 02:19:35 i'd say it worked 'well enough' 02:19:45 i'm sure it worked better on ix hardware 02:20:16 it definitely left a lot to be desired. and bug reporting was pointless at some point in time. 02:20:37 I've tried both iX hardware and just standard SuperMicro and such. I didn't really notice a difference. 02:21:10 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. 02:21:35 there were like 3 different identifiers if you had a disk die in non-ix hardware 02:22:12 most people just add labels nowadays in line with their nas on where the disk is that breaks 02:22:39 You talking the gptid stuff? 02:22:43 i know a few times i had an issue finding where a dead disk was 02:22:56 i think it's more of a zfs thing isn't it? 02:23:35 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 02:24:08 On current, non-iX hardware, it's just gtpid. 02:24:15 You can find the disk info with part. 02:24:21 gpart* 02:24:36 if the disk is dead? 02:25:05 Well, no. But, you can record the disk info any time and keep it until it's needed. 02:25:13 oh i guess it is a gpt label 02:25:29 i vaguely remember having to do something with zfs though to get them to show 02:25:32 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 02:25:56 yeah. but then you're doing process of elimination 02:26:18 Yep. 02:26:27 vs just doing a zpool status and seeing "dead... used to be gpt/F01-03-SEAGATE-SERIAL... 02:26:33 " 02:26:34 As long as there aren't a bunch of dead disks, it only takes a moment to figure out. 02:27:13 That report exists in non-iX hardware TNAS. 02:27:17 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 02:27:31 Ah. I gotcha'. 02:27:51 i definitely had a couple of times where i was going easter egg hunting for a bad drive 02:28:15 I can see that. 02:29:34 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 02:30:07 so it was nofix.. i ran into a few things that were easily reproducible that had that issue. 02:30:31 overall though it isn't bad. nice interface for sure. 02:39:55 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. 02:40:27 For the most part, it works as intended. With any luck, zVault will be better about things like that. 02:44:53 I'm very excited about that. I noticed the register did a nice article. I ended up moving to vanilla FreeBSD. 02:47:21 rtj: I still have some TNAS systems floating around. But, without zVault, I was planning on migrating them to vanilla FBSD in the future. 02:47:36 There's not a chance I'm moving to Scale. 02:47:51 I've had a FreeNAS mini from ix over ten years. Before that I ran nas4free I think on a poweredge. 02:48:12 I guess the hype is what sells. 02:48:34 I suppose. 02:49:55 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. 02:50:23 If I had to guess, iX will probably lose around 33% of it's users once they drop Core. 02:51:05 People have been jumping ship for a while now. 02:53:51 I've never understood why people don't just run straight FreeBSD for the purpose. 02:55:25 mason: Because multi-administration usually requires ALL admins feel comfortable. :( 02:56:16 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. 02:56:42 You nailed it. 02:58:07 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!" 02:58:34 If I told them what I'd done, I'd probably be fired. But, I'm gonna let it ride out until someone notices. 02:58:53 :) yes it's rock solid 02:59:04 When they do, I'll tell them about the user's praise and they can kick rocks with their anti-BSD, scaredy-cat BS. 03:00:21 Not to mention the VM host resources have dropped dramatically. Like, 36% on average. That's pretty incredible. 03:01:25 God forbid someone learns some commands, though! "Where's my fancy interface!?" Piss off! 03:02:36 I've been overly impressed with Bhyve. I'll never look back. 03:07:05 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? 03:09:03 rmatte: I only use command line. But, I am using sysutils/vm-bhyve as a command line kind of "shortcut" interface to Bhyve itself. 03:09:08 Super easy. 03:09:19 nice 03:10:38 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.) 03:11:35 https://bhyve.npulse.net/ <--- this is a popular one apparently 03:11:36 vm-bhyve gives you the "vm" command with all kinds of options. Man page is solid. It does everything I need. 03:12:53 I mostly just use containers nowadays. 03:13:10 rmatte: Interesting! I'll have to look into it. 03:13:38 mason: Instead of VM's or instead of jails on FBSD? 03:13:53 Also, are you using containers on BSD? Podman or something? 03:14:15 ek: Instead of VMs. I do LXC containers set up like jails on Debian, and Jails on FreeBSD. 03:14:33 mason: Gotcha'. 03:14:53 I just use docker personally 03:15:19 Dang. I've had to use docker quite a few times and I wanted to kill myself. 03:16:34 lol, I'm just used to it at this point 03:17:27 Don't get me wrong. It's easy to deploy stuff. I get that. But, man... I did not like the command line layout. 03:17:51 Or the command output layout. 03:18:17 And, most certainly, did NOT like the networking setup. That was nearly impossible to troubleshoot. 03:18:49 yeah, the networking stuff is quite the learning curve with it 03:19:40 "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!" 03:19:45 Oh... Kill me now. 03:19:55 lol 03:20:28 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 03:22:10 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 03:22:11 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. 03:22:42 yeah, it's definitely a fun time 03:23:29 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. :) 03:24:17 Looking forward to using sparse zvols in Bhyve. 03:25:16 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. 03:25:46 rmatte: You can build jails from ZFS snapshots and ship those around. 03:25:52 ah ok 03:25:57 Never used this one. I think they talked about it on BSDNow https://github.com/alonsobsd/bhyvemgr 03:27:55 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. 03:28:59 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.) 03:29:36 Then, Bhyve will be my recommendation even in corporate settings. And, they will most certainly require a gui of some type. 03:29:53 Just to make happy the masses! 03:30:30 Nice anything to get more users using it is good. Yes 100% lol 03:32:29 Absolutely. And, the proof of performance will be easy to present. Without any proprietary requirements, thus far, FBSD+Bhyve wins. 04:00:54 ek: wins vs what? 04:02:09 SponiX: Wins vs VMware and Proxmox (which are my ${JOB}'s go-to standards.) 04:02:48 I'm hoping to experience similar also "soon" 04:03:06 Well, I will mention that importing pre-made provided, non-UEFI linux VM's can be troublesome. The grub stuff can be tricky. 04:03:29 SponiX: I think you'll be pleasantly surprised. 04:03:42 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 04:03:51 Oh, and the chip on the Linux rig also has a few more cores 04:04:25 so, at present Linux qemu/kvm wins. But it isn't close to fair 04:04:38 SponiX: Are you using the nvme option on the Bhyve host for the VM? 04:06:39 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. 04:07:54 For example, I had Proxmox on an SSD host previously and disk I/O speeds and usage was pretty decent. No issues. 04:08:10 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 04:08:29 so as I said not really "fair" at all 04:08:53 NVME gets like 2.5GB/s and the sata SSD is like 500MB/s 04:08:55 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. 04:09:54 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. :) 04:10:10 I'm very curious what the difference may be. 04:10:57 well, I also recently did some Desktop oriented performance tweaks to my FreeBSD and it made a HUGE difference 04:11:11 SponiX: Like what? 04:11:28 Haven't re-ran any of the test with these in play yet 04:11:31 SponiX: And, also, is the FBSD you made the changes on a VM or metal? 04:12:00 @mason I can post my loader.conf rc.conf and sysctl.conf if you like 04:12:12 SponiX: sure 04:12:51 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 04:13:49 loader.conf -> https://termbin.com/1zeh 04:14:22 sysctl.conf -> https://termbin.com/04d5 04:14:57 rc.conf -> https://termbin.com/q8t3 04:15:08 ty, looking 04:15:09 SponiX: Gotcha'. This is a desktop that's also running VM's via Bhyve? (I'm just guessing based o the loading of "vmm") 04:15:15 these configuration files also include a bridge0 device for use with my vms 04:15:30 Got it. 04:15:55 SponiX: Hrm, I need to learn about what some of that is. autobridge_interfaces for instance. 04:16:03 ek: Yes, FreeBSD 14.2-RELEASE host doing a bhyve guest vms of 15-CURRENT 04:16:55 @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 04:17:08 SponiX: You have some duplication between loader.conf and rc.conf 04:17:20 @mason Yeah, I'm aware 04:17:42 there are probably some dupes within same config files also lol 04:17:45 I hit a weird issue with bridging over the weekend. 04:20:07 mason: Care to elaborate? 04:20:39 the Desktop and I/O tweaks in place now cut my Video load time for 4K and 1080p Porno in half or better. Seriously 04:21:12 Faster, stronger porno is always a good thing. 04:21:47 prior the load and seek times were so bad I was actually switching over to my Linux rig to watch stuff 04:21:59 Now it is on part or better than the Linux box 04:22:07 On par or better 04:24:52 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. 04:25:38 ek: Tried to use my general https://wiki.freebsd.org/MasonLoringBliss/JailsEpair plan and it fell over hard. 04:27:12 SponiX: Awesome! Glad to hear you got that performing nicely. 04:27:50 mason: Ah, okay. 04:29:23 mason: What was the resolution that you came up with? 04:29:37 Because, I'm not sure why that wouldn't work? 04:31:55 ek: I lifted an IP address in the required range and set it on my host-side epair. 04:32:33 How does one make a wiki.freebsd.org page? 04:32:45 farhan: Sign up for an account and you can start making them. 04:32:58 farhan: Best bet is to join #freebsd-wiki and ask. 04:33:00 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 04:33:28 Words are HARD 04:33:32 stupid English 04:34:06 mason: Ah! Okay. That makes sense. 04:34:42 SponiX: I have quite a few hosts running -CURRENT and have had no issues yet. 04:35:26 However, they are not production or anything and not running anything crazy or really out of the ordinary (mail server, web server, database, etc...) 04:35:40 I very much want to figure this out though. Linux has rp_filter and I have to think there's some equivalent for FreeBSD. 04:35:41 But, -CURRENT sure seems solid so far. 04:36:04 mason: What does rp_filter do? 04:36:45 ek: reverse path filtering - it's what requires an interface and a route to be related. 04:39:05 Only mention I'm finding is https://forums.freebsd.org/threads/disable-rpf-rp_filter-on-interface.72880/ and that's not a hopeful mention. 04:39:06 PF has the option for unicast? 04:39:44 Maybe more. I remember reading something about that a while back for a v6 video stream test things I was working with ${JOB} 04:40:08 Err... Hang on. I'm sure I can find it. 04:41:16 URPF 04:41:36 *uRPF 04:42:02 https://www.openbsd.org/faq/pf/filter.html#urpf 04:42:09 wtap missing a man page... 04:42:16 Maybe sounds like what you're looking for? 04:42:56 ek: Except, that looks like pf just uses it as a way describe a packet, rather than overriding the kernels' unwillingness to pass packets. 04:43:27 ...from the description at https://man.freebsd.org/cgi/man.cgi?pf.conf(5) anyway. 04:43:42 But yeah, that's what I want to turn off and I figured I could, but now I'm not quite sure. 04:43:56 Yeah. It'll perform differently. 04:44:35 farhan: I'm not familiar with wrap. Sorry. But, feel free to report the missing man page (or provide one?) on bugs.freebsd.org 04:45:20 s/wrap/wtap/ 04:45:35 Yeah, I might have to...if I get stuck on my current project, I'll take a first cut at the man page. 04:45:51 The diff to get it to build is in review.. 04:49:23 Well, I wish you the best of luck! 04:49:44 farhan: Languishing in review, or getting attention in review? 04:50:29 I believe it is getting attention, but I'll ping you if it stagnates 04:51:12 Have another diff that I need to ping folks about, updating something in net80211 04:51:17 farhan: Well. I've got no commit bit, but I could suggest places to be active to get attention on it. 04:52:01 Not that I seek it, but how does one get a commit bit? 04:56:09 farhan: Get involved: https://freebsdfoundation.org/contributing-to-freebsd-as-a-programmer/ 04:56:56 I don't think there's an explicit process like what, for instance, FreeBSD has. 04:57:01 s/FreeBSD/Debian/ 05:01:15 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! 06:19:39 https://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." 07:42:30 MRniceMR on #freebsd-irc is sending people bat files 09:04:08 nice 10:37:53 wsky: for free? 10:38:06 :D 10:41:47 I do wonder, am I the only one who's bother by our 9 months life cycle? 10:42:11 antranigv: for having a baby? 10:42:15 I wish it was at least a year, or maybe if there was a way to deploy and update -STABLE better and faster. 10:42:40 SponiX well, that one I would prefer if it was shorter, but no I'm talking about the FreeBSD release cycle. 10:42:59 antranigv: you have looked into pkgbase? 10:44:12 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. 10:45:41 well, it is a solution for that problem. even if it isn't fully implemented yet 10:46:00 I just learned that -STABLE has pkgbase. 10:46:07 I mean, a pkgbase repo that is. 10:46:13 YES 10:46:17 that is what I am saying lol 10:47:08 you just changed my life. lemme check now. I guess I can't run -stable jail on -release kernel. I might need -current host. 10:50:49 pkgbase is the future 10:51:06 +1 10:51:38 I'm hoping by the time 15 hits release it will have bectl integration like freebsd-update has now 10:51:48 ah, I see 10:51:54 I wonder if pkg audit is integrated yet 10:53:47 I'm a bit excited. I got a 20 core Xeon to replace this 16 core for only $55 USD 10:54:03 and a 2TB NVME on the way 10:54:15 nice 10:54:20 only FreeBSD on the host? 10:55:35 On this machine yes. It is 14.2-RELEASE Host, and bhyve 15-CURRENT build vm 10:56:20 debating going 15-CURRENT on the Host when the nvme gets here 10:59:41 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 11:09:07 antranigv: so you are on 14.2-STABLE? 11:09:35 SponiX I am on 14.2-RELEASE, but I want to run 14-STABLE. I will probably use bhyve for testing for now. 11:12:09 why the desire to be on STABLE? 11:55:58 STABLE runs fine, I am using STABLE in production since 2001 11:57:28 mzar: for your needs. what makes stable more desirable vs release ? 11:58:09 why the desire to be on STABreset 11:59:07 SponiX: the ability to add own patches, apply fixes quickly, and, what is most important: simplified and faster update 12:00:33 some people run CURRENT in production, it's even better, but it has one drawback: ABI instability 12:01:06 so to follow, sometimes whole software has to be reinstalled after upgrade 12:03:49 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 12:04:24 the main advantage of stable is you don't need to apply your own patches in the first place since someone else already did :-) 12:05:56 ivy: everything is built from sources, but I like to be in controll of STABLE and sometimes do MFCs on my own schedule 12:13:22 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 12:20:56 Anyone using KDE 6.3.x on Wayland? 12:21:53 I'm constantly have 3-5 second freezes on X11 with KDE, and I'm pretty sure with XFCE also 14:04:43 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 15:05:48 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 15:06:16 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 15:22:47 hodapp: Just create a different dataset on the receiving side and send there instead? 15:23:19 Ex: send zroot to server:zroot/backup or something. 15:24:46 ek: this is already into a different dataset, but this doesn't change the mount points already set - they're still /home and blahblahblah 15:25:21 the issue isn't which dataset they're in, it's the mount points & canmount received 15:33:56 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? 15:35:26 AFAIK all of this is blown away with recv 15:41:08 hodapp: So, just change the mountpoint on the recv side during the recv using "-o". 15:41:19 That would seem to be the easiest solution. 15:44:03 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 15:44:25 may need -x 15:44:33 Sure. Just use "zfs set" to change them back after a restore. 15:44:50 Or, when you zfs send the restore back, just change the mountpoint= back. 15:45:51 though it may end up with: setting all mountpoints to the same thing on multiple descendant filesystems, and still trying to mount them all 15:45:56 not sure how that'll go 15:46:26 and I am not sure if -o will work with canmount as expected since canmount doesn't inherit 15:47:16 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. 15:48:07 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 15:48:54 Because you would change the mountpoint during the recv. You can change it to anything. That should ensure no overlap. 15:49:55 but all datasets would inherit the same mountpoint 15:50:10 regardless of what mountpoint I make it 15:50:16 On the recv side, yes. 15:50:49 do you mean no overlap with the zroot's mount points? I meant overlapping with each other 15:51:37 It should ensure no overlap anywhere on the recv side. Both zroot mountpoints and the datasets themselves. 15:52:57 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/*) 15:56:52 hmm, I am likely missing something with how mount points are inherited 16:00:41 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 16:05:49 hodapp: How are you performing the send/recv's? What's the exact command(s)? 16:08:42 ek: last I tried was: zfs send -R zroot@snapshot_whatever | zfs recv -v -d -F -o canmount=noauto tank/zroot_backup 16:14:40 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. 16:15:20 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" 16:16:31 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. 16:18:19 So, all this discussion of pkgbase since yesterday... Is it becoming the default for 14.3 or something? 16:18:47 It's in current now for 15 I think? 16:19:20 Yeah. Not going to be default in 14,x AFAIK. 16:25:47 Hm, and 15 is currently slated for late this year. That's actually pretty fast, all told. 16:26:18 mason: pkgbase will be the default for 15.0R, nothing is changing for 14.x 16:27:05 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 16:27:53 mason: https://lists.freebsd.org/archives/freebsd-pkgbase/2025-May/000516.html 16:37:34 ek: but I don't see any -o mountpoint=... in your commands 16:38:23 hodapp: Exactly. I don't even use that and I'm getting the expected results. 16:39:48 ek: this is where I started in the first place, and how I was seeing mount points like /home 16:40:24 ek: I suspect that your command only works as planned when *all* mount points are inherited 16:41:50 ivy: i got a prompt to use legacy or tradtional 16:42:02 ivy: i really dont think they will go all the way in 15.0R 16:42:10 er experimental 16:42:23 honestly should I said experiment to test pkgbase 16:51:26 cpet: we are definitely going with pkgbase in 15.0R unless something terrible goes wrong 16:51:55 cpet: the only thing that's really missing is proper bsdinstall support and isaac/ed are working on this atm 16:52:22 running a recent install snapshot it gives you the option to use tradtinal or experimental 16:52:24 just for now the old way won't be removed in case we get to release and discover some last minute thorny problem 16:52:32 would make sense to keep it that way until 15.1 16:52:57 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! 16:52:59 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 16:53:10 It was kind of difficult to find info. I wanted to make sure I was prepared. 16:53:29 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 16:53:48 pkgbase has been going on for years now 16:53:58 It sure has. 16:54:16 right, in 14.x it basically worked fine, we just didn't have the installer support 16:55:28 cpet: fwiw i also did not expect this to happen for 15.0R but a //lot// of progress is being made really quickly 16:55:32 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. :) 16:55:33 so i believe it will actually happen now 16:56:26 mason: even the guy who wrote freebsd-update hates it :-D 16:56:32 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. 16:56:47 ivy: Haha. Yeah. I've seen him mention that many times. 16:59:43 * hodapp reads about pkgbase... 17:01:20 btw, "CFG: pkgbase support in 15.0" - https://lists.freebsd.org/archives/freebsd-pkgbase/2025-May/000516.html 17:01:28 s/CFG/CFT 17:03:43 not a real fan of ML's 17:04:50 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. 17:05:56 I'm too clueless to have real complaints about it 17:06:18 never had any issues with it 17:06:30 cpet: you don't need to use the list, you can report bugs in bugzilla 17:07:35 FWIW, to cope with freebsd-update getting it wrong, I learned about uname -U and the --currently-running flag. \o/ 17:08:02 But pkgbase will obviate this. 17:09:09 would be nice to create jails with the bare minimum to get things running 17:09:16 we dont need bluetooth in a jail now do we ? 17:09:41 cpet: pkg -r /jail/myjail install -r FreeBSD-base FreeBSD-runtime FreeBSD-utilities FreeBSD-syslogd FreeBSD-newsyslog FreeBSD-cron FreeBSD-rc 17:09:53 this is exactly what pkgbase is intended to make possible 17:10:55 Yep. It's going to be super helpful in that regard. 17:11:04 blames ek 17:14:40 i get the feeling using pkgbase will break the system easier than the other 17:15:12 idea - rather than freebsd-update, make the base system a package. 17:15:48 farhan: that idea is called pkgbase 17:15:57 https://wiki.freebsd.org/PkgBase 17:33:17 dstolfa: oh wow...that already exists. 17:35:09 dvl: could i persuade you to update https://github.com/freebsd/freebsd-src/pull/1603 so i can land it, pretty please? :-) 17:35:31 dvl: or i will just do it myself if you're okay with that 17:36:44 ivy: Please proceed, I'm swamped. 17:36:53 dvl: ack 17:37:00 ivy: Thank you. 17:38:21 [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) 17:40:43 ivy: do we use github?? 17:40:49 I would be really happy if we did 17:41:15 farhan: yes you can submit patches to src on github, not docs or ports without prior approval though 17:41:26 oh wow, I use phabricator 17:41:29 what is preferred? 17:41:34 uh, complicated 17:41:57 I would prefer github... 17:41:58 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 17:42:06 but if you're working with a committer who will commit your changes, phab is fine 17:42:17 that's what I'm doing. I have no commit bit. 17:42:52 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 17:43:04 define better? 17:43:06 if you have someone in mind to commit your patches i'd suggest asking them 17:43:13 farhan: better = "exists" :-) 17:43:26 landing github patches is basically entirely manual right now, it's a huge pain 17:43:48 imp is working on improving this but it's still not great 17:44:47 it is convenient in the sense that the --author metadata is already there, but I guess git-arc may paper over that complaint anyways 17:44:51 basically, phab is better if you want people to review your change, github is better if you want your change to actually be committed 17:45:01 ha! 17:45:08 the fact we don't have one solution that achieves both of these goals is an open issue 17:45:09 that seems disjointed. 17:45:49 i think everyone agrees that the current situation is not ideal :-) 17:46:31 anyone know if there is a plan for use of bectl with pkgbase similar to how freebsd-update does now? 17:47:12 what does phab offer that github doesn't have? 17:47:33 besides not being owned by Microsoft? 17:47:34 lol 17:47:50 sure, but you can have a commercial account so its not a negative ownership 17:47:54 ie, you pay them 17:48:30 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 17:49:30 I suppose that's reasonable from an independence perspective. 17:50:46 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? 17:51:17 Its an arbitrary line -- and as long as we're aware of that, then its perfectly reasonable to not use github to be independent. 17:51:34 well, if NYI were to withdraw their support the project could move to another DC with a reasonable amount of effort 17:51:46 if Microsoft start doing something with GitHub we don't like... 17:52:03 Why do I feel like there's a rush to make FreeBSD more like all the shitty Linux distros? 17:52:18 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 17:52:26 CrtxReavr: i don't know, why do you? 17:53:07 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 17:53:21 So far I think MS has done a good job of being platform agnostic. 17:53:26 dstolfa: as we just found out when surveymonkey blocked Russian users... 17:53:47 That said, however, there's plenty of source repo platforms that interact well with git. 17:53:49 ivy: yeah, incredibly annoying 17:55:32 CrtxReavr: Some of Linux's ideas are worth emulating, no? 17:56:30 dstolfa: I totally forgot about that... 17:56:51 this is not the first time recently i've heard "freebsd is turning into linux" and i don't really understand it 17:56:51 And to answer your question, Ivy, pkgBase seems like a step in the linux distro direction. 17:57:30 farhan, don't confuse popularity with worth emulating. 17:57:42 Sure, but popularity is a sign of business demand. 17:57:45 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 ... 17:58:30 farhan, Windows is popular. 17:58:48 right! And windows solved some problems that others could learn from. 17:58:50 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 17:58:59 we're absolutely not doing that and no one wants to do that 17:59:04 agreed... 17:59:19 ivy: also very different ABI stability expectations 17:59:26 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 18:00:10 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. 18:00:19 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. 18:00:29 I would like to see FreeBSD improve on those areas 18:00:32 And I'm glad it was only user apps, and not core OS components. 18:00:35 as far as github and Microsoft. Have a look at their latest moves with vscode if you want more reasoning not to trust Microsoft 18:00:38 well, i'm sorry you had a problem with pkg and you should probably report a bug, but that was probably not intentional 18:00:50 this is why we want people to test pkgbase, fwiw... 18:00:56 And I would not consider that "chasing shiny things", but rather, chasing market demands... 18:01:19 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 18:01:24 I am specifically speaking about containerization... 18:01:28 it's all down to active testing as ivy says 18:01:30 dstolfa: + 18:01:31 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 18:01:32 i guess that's one way to look at it 18:01:37 bah, I was scrolled up 18:01:44 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. https://bin.langille.org/?24fdd3f2d0bc90ea#6CXkA2HYKuq4ununjGGbndVmG8c5nHrCYghJwoGMtHBq 18:02:17 Honstly. . . I feel like the ports sytem has been largely wreck. 18:02:32 largely what? 18:02:34 There's way too much of it that won't build outside of poudriere. 18:02:46 * kevans notes that pkg generally presents its plan for an upgrade that you're supposed to review before committing to it 18:03:06 well, there was a lot of it that wouldn't even build with poudriere recently. that just got ironed out 18:04:03 portmaster should would. 18:04:04 Period. 18:04:55 A manual ``cd /usr/ports/this/that && make install clean`` should work. 18:04:56 Period. 18:05:25 does it...not? 18:05:28 (And it did for many FreeBSD major versions (with little exception). 18:05:30 I never use the ports tree 18:05:50 I use pkg for everything 18:05:58 Not when builds won't build outside of poudriere. 18:06:29 farhan: a fair amount of folks are like that. I do pretty much the same on my 14.2-RELEASE machine 18:11:14 Some of us still like to compile 18:12:22 CrtxReavr: what doesn't build that way if you start with a clean installation on freebsd without installing packages that have mismatched versions? 18:12:28 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 18:13:07 I'm a sysadmin, not much of a software developer. 18:13:12 cpet: I don't think that the build systems are going away anytime soon 18:14:34 cpet: no one is removing support for compiling anything 18:14:45 compiling is required to produce the binary package so obviously we cannot remove that 18:15:04 CrtxReavr: what is not building outside of poudriere? 18:15:35 That seems to change by the day. 18:16:35 (Maybe if the pkg build system didn't use poudriere, things would be better.) 18:16:59 anyone good with the basics of pf? I'm gonna do my setup with it after this next reboot 18:17:00 all it does is create a jail with a fresh install so not a lot of trickery there 18:17:37 I do it manually sometimes when lazy in a vm or so and havent had issues 18:17:40 Your definition of "all it does" is probably not very read world. 18:17:55 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 18:17:59 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 18:18:10 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 18:18:26 pkg are mostly great. . . until you need a non-default build option. 18:19:09 Yeap 18:20:11 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" 18:20:36 i'm not even sure what that change would look like. poudriere just spins up a jail and builds the port 18:20:53 * CrtxReavr sighs. 18:21:13 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 18:21:22 i've not once seen it break for a port that wasn't already broken with poudriere 18:21:51 CrtxReavr: check out a ports tree corresponding to the package versions you have installed and your issues will go away 18:22:07 Sounds like a lot of non-real-world navel gazing. 18:24:16 understand that most "real world" freebsd users are using poudriere, because it's fundamentally a better way of building packages 18:24:30 i agree 'make install' from a port should work, and if it doesn't, please report a bug 18:25:12 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 18:25:24 I liked the port master building 18:25:39 The standard reaction in #freebsd-ports (or #bsdports on EFnet) to such a complaint is "You should build in poudriere." 18:25:46 great discussion, btw really enjoying this. 18:26:17 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. 18:26:53 This is just infuriating and I have work to do. 18:28:09 what doesn't build outside of poudre? 18:30:03 I like the way openbsd does it it's all build into ports buy the backend is perl using fakeroot 18:30:18 Poudriere is too complex for simple port testing 18:30:36 But I normally get kicked for being a troll so bleh 18:31:40 no one is going to kick you from here for saying you prefer some other way of doing something 18:31:57 it's just frustrating when people complain about something and won't provide specifics so it can be fixed 18:32:22 sure cpet, now this channel is liberated 18:34:23 cpet: there is in fact a "testport" option for pourdriere ;) 18:36:52 I'm just learning the basics on poudriere myself though 18:37:03 still can't spell it correctly most of the time 18:37:33 SponiX: alias p = poudriere ... or something? :P 18:37:35 it should probably be called poudriëre 18:38:03 dstolfa: well on system I can type poud->TAB 18:39:13 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 18:41:26 I use poudriere but it shouldn't be this complex to test a port 18:41:29 SponiX: i may be misunderstanding you but poudriëre doesn't use VMs, you can see the command in `ps` on the host 18:41:40 commands 18:42:16 "ps axd" may be informative here 18:44:16 or i gues we're meant to spell this "ps Ad" now 18:44:55 kevans: does ps(1) conform to POSIX? 18:46:35 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 18:47:03 I understand that poudriere itself uses FreeBSD Jails 18:47:55 SponiX: yes, but jails could be nested, so you can have poudriere running in the jail 18:49:57 I use the vms for several reasons. mainly resource segmentation 18:50:14 anyway, I have to run. Be back later 18:50:52 segmentation? jails could be limited too 18:52:03 mzar: well, the build team told me that I can't run a 15-CURRENT jail on 14.2-RELEASE 18:52:14 that is another reason for the vms 18:52:19 but poudriere runs build only on demand, and it's better to give it more resources to complete builds faster 18:52:25 ivy: safe to assume no 18:52:51 Poudriere is too complex for average new user to start contributing just like the doc was hell before 18:53:35 cpet: I mostly agree with that 18:53:40 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 18:54:12 dstolfa: Yes, that is one big reason for the vm use... 18:54:19 SponiX: but when running poudriere on CURRENT you can have 14 and 13 jails 18:54:37 But uh well if I have to run my ports through that I'll do it but still 18:55:14 > Poudriere is too complex for average new user 18:55:34 it's probably not for newbies 18:55:38 Does an average new user even should know of and be bothered with poudriere? 18:56:10 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 18:56:17 I've got libvmmapi.so.6 though 18:57:34 yeha but little timmy who wants to update fceu 18:57:42 should be able too without complexity of poudrere 18:58:10 cpet: this is what binary packages are supposed to be fore 18:58:20 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. 18:58:22 most users should have no reasons to build ports from source, i realise they do, but they shouldn't 18:58:58 if you are updating a port most if not all commiters will ask for a poud build log 18:59:11 so again if little timmy wants to build port he would have to do all that 18:59:29 timmy can fail 18:59:55 so who cares about timmy 19:00:22 yes, nobody cares about timmy 19:00:24 that mentality is what me me go from maintaing 700 ports to moving to OpenBSD 19:00:35 go ahed cpet 19:01:02 I've never looked into these build systems - what exactly is poudriere? 19:01:14 cpet: issue command /j #openbsd && /part #freebsd 19:01:35 openbsd is cool, I'm sure they would be happy to have you. 19:02:02 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 19:02:12 you can then pkg add those or you can serve them to your server fleet or whatever 19:02:31 how is that different from /usr/ports/this/that make clean? 19:02:44 its a clean install 19:02:45 it does so in a clean environment and picks up the right versions of dependencies for a given ports tree 19:02:50 with nothig that can intefere with it 19:02:54 i think its over kill but 19:03:10 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 19:03:17 and you don't end up with broken software 19:03:30 or build failures. 19:03:53 ow security holes you aren't aware of. that kind of thing. 19:03:59 s/ow/or 19:04:04 the whole point of that is to build the port using the current ports 19:04:17 this is why mixing pkgs and ports is bad 19:04:51 it's nothing bad with it, only some people are bad cpet 19:04:58 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? 19:05:02 and same for libXXX.2.so 19:07:31 mzar: Yeah, I might go to CURRENT when my new nvme drive gets in 19:07:36 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 19:07:57 SponiX: give it a try 19:08:06 isn't this called dependency hell? 19:08:30 Is there some command I can run to repair the parts of base that are incorrect? my bhyve is broken after the upgrade :-( 19:08:50 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 19:10:49 deepy: bhyve is broken? perhaps it was incomplete upgrade ? 19:11:07 deepy: you could try fetching base.txz from here: https://download.freebsd.org/releases/amd64/ 19:11:10 for your version 19:11:34 mzar: freebsd-update isn't letting me progress in any way :-( 19:11:51 dstolfa: I'm currently comparing the result of freebsd-update IDS with that, but was hoping there'd be something more automagic :') 19:12:03 deepy: OK, follow dstolfa's guidance then 19:16:35 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 19:18:10 I'll continue the base + IDS dance, thanks for the help both of you :-) 19:18:59 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 19:19:19 s/probably/probably best 19:22:55 and although my machines are setup for building packages. I normally don't tie up resources building them myself lol 19:23:35 OK, you can install packages for CURRENT from official repos 19:23:46 If I go CURRENT again, it will probably be with pkgbase 19:24:07 mzar: I'm aware. I've ran CURRENT on my systems before 19:24:49 to be honest though, I am fairly happy with my setup now. I might switch it up though 19:29:08 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) 19:29:34 anyway.. gotta run again errands are calling me 20:09:29 I tend to update and reboot CURRENT way too much. That is a part of why I'm on RELEASE right now 20:10:40 hmmm... burnt with CURRENT 20:12:53 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) 20:13:02 find a good commit, stay on that for a few months, update later 20:14:31 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". 20:19:50 ivy: I tend to apply any system updates blindly as soon as they become available without researching them 20:20:10 SponiX: yeah, you should not run -CURRENT :-P 20:20:17 case in point, unix(4) is kind of broken right now 20:20:51 oh, I tend to procrastinate doing updates until I realize that my FreeBSD has been out of support since Bush was in office 20:23:22 Which one? 20:23:32 not answering that 20:29:35 I like the appeal of STABLE and CURRENT. But honestly think RELEASE is the best fit for my uses right now 20:30:05 i think with the "new" release cadence it's pretty reasonable to use -RELEASE now 20:30:19 you get a stable release and you get a pretty good window in which you can upgrade to the next release 20:59:52 WTF 21:00:03 https://bpa.st/TLVQ 21:03:54 CrtxReavr: why is this "wtf"? are you perhaps looking for the mtr-nox11 package? 21:17:40 Well. . . maybe. . . but then why does 'mtr' need CUPS? 21:18:22 at a guess, gtk2 probably requires it 22:07:15 Don't you want to print your routes on paper for later reference? 22:08:39 i did once print out a copy of the EDU zone file on a dot matrix printer... 22:10:35 I'm happy I wasn't in the same room at the time 22:10:59 ivy: why not run CURRENT? 22:11:21 regis: context? i run CURRENT everywhere including production systems 22:12:47 ivy: CURRENT dot matrix printer? I dunno. 22:14:12 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" 22:14:36 ivy: Hey, mee to. 22:31:49 is there a branch for 15-current ? 22:31:59 hernan604: "main" 22:32:19 -CURRENT is always the "main" branch 22:32:24 i want to install it in parallel with 14.2-RELEASE 22:33:41 as a 15-current boot environment 22:34:46 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 22:35:03 well i guess i will have to test 22:35:19 and activate a different environment if it breaks 22:35:21 hernan604: the switch from 15.0-CURRENT to 16.0-CURRENT is meaningless, it's just a version number change 22:35:21 so nvm 22:35:33 ok 22:35:58 it's the same branch 22:36:03 -CURRENT is always "main" 22:36:07 got it 22:36:14 thanks ivy