03:17:02 <ivy> is there no way to clone a zfs filesystem, without duplicating the data and without leaving a snapshot around forever?
03:34:46 <rwp> ivy, I thought one could destroy a snapshot after creating a clone from it?  No?
03:35:25 <rwp> See Example 3 in man zfs-snapshot
03:36:41 <ivy> rwp: no, you can't.  promoting a clone just inverts the dependency, so you can destroy the original filesystem, but i want to keep both filesystems
03:47:36 <rwp> Hmm...  I can't tinker a way to do it.  So I guess one must keep the snapshot around.  At least I can't figure a way to do it.
04:05:18 <ivy> i suppose i could enable dedup, then do the send|recv, then turn it off again, but i wonder why there's no built-in way to do this, it seems like the on-disk format should support it
15:37:11 <rtprio> what's easier; updating my 14 month old 15-CURRENT system to 16-CURRENT or 15-RELEASE?
16:41:49 <ivy> rtprio: if you use ports packages from pkg.f.o, then 15, because there aren't 16 packages yet.  otherwise the two branches are still pretty close so probably no difference
16:42:23 <ivy> although if you really mean 15.0-RELEASE, things might have changed by the time that comes out
17:10:14 <rtprio> i don't mean 15-release, i mean whatever 15- non-current it is now
17:11:05 <kevans_> you can assume they will be equally difficult, with the caveat of package availability she noted
17:11:38 <kevans_> re@ is giving some leeway to continue landing pkgbase things to better shape how that works in 15.0, so it's hard to say
17:18:47 <rtprio> i'm ok building my own, it's mostly bhyve and puppet
17:20:05 <markmcb> running 15 alpha 3 with pkgbase. if i uninstall a base pkg, is there a command i could run that shows the "diff" between what i have installed and a full base install?
17:20:54 <ivy> markmcb: "pkg install freebsd-set-base" will show you the packages that would be installed if the full base system was installed (excluding lib32, src, tests, dbg and kernel)
17:21:07 <markmcb> ivy, thanks!
17:22:08 <divlamir> So, is pkgbase primetime starting with 15.0?
17:22:32 <divlamir> I mean the default, so we convert on upgrade
17:23:03 <ivy> divlamir: 15.0 will ship with both pkgbase and dist sets in the installer.  the exact status of which is recommended and which secteam will officially support is not 100% finalised yet, but currently leaning towards pkgbase
17:23:14 <ivy> divlamir: converting on upgrade will be optional since freebsd-update will still be supported
17:25:38 <markmcb> anyone else on pkgbase see ftpd as behind, i.e., pkg version -qvRl "<" ... yields: FreeBSD-ftpd-15.0.a2.20250919040617 <   needs updating (remote has 20240719)
17:26:06 <angry_vincent> and for the building from source it will not cease to end as an option i hope?
17:26:29 <divlamir> ivy: thanks, time to give it a go and test it then.
17:27:15 <markmcb> it seems there is freebsd-ftpd-20240719 (port) and FreeBSD-ftpd-15.0.a2.20250919040617 (base) ... and that's confusing the output
17:28:02 <ivy> angry_vincent: there are no plans to remove buildworld/installworld
17:28:03 <divlamir> angry_vincent: building from source will never cease be a thing
17:28:32 <angry_vincent> good
17:29:00 <angry_vincent> i have tried make packages but it fails for me. i use custom src.conf and kernel
17:31:08 <markmcb> (for clarity, I don't have the ftpd port installed, just the base pkg)
17:32:01 <ivy> markmcb: curious.  i think this is probably a pkg(8) bug, but we probably want to avoid having packages with duplicate names like that anyway.  i'll have a think about the right fix
17:33:23 <ivy> (this is why we have FreeBSD-rip instead of FreeBSD-routed, but i didn't realise ftpd was affected as well)
17:34:03 <markmcb> ivy: sounds good, thanks for clarifying
17:41:08 <ivy> markmcb: i also filed a pkg bug for this: https://github.com/freebsd/pkg/issues/2526
18:33:33 <rtprio> [root@tyrone /usr/src]# git fetch
18:33:34 <rtprio> ld-elf.so.1: Shared object "libssl.so.35" not found, required by "libcurl.so.4"
18:34:15 <rtprio> off to a great start
18:34:21 <ivy> rtprio: that looks like you managed to update ports before updating the base system
18:34:31 <ivy> libssl was bumped from 30 to 35 a few weeks ago
18:35:55 <rtprio> yeah, that must have been it
20:22:50 <mns> ˜/38
20:30:58 <iio7> As there a way to run tmux from the install media, without installing anything? I managed to boot from it, enable OpenSSH and log into it by using mount_unionfs with /etc on /tmp/etc, but pkg needs more than that, I'm just not sure what.
20:47:19 <kerneldove_> how's 15 looking?
21:10:24 <divlamir> hot!
21:14:48 <divlamir> mh, the guidelines for submitting bugs on bugs.f.o say to use "git format-patch" as the prefered method. But the web ui doesn't get right the diff, because of those `--` lines that git format-patch uses. I guess I should just use a simple `git diff` next time? What is the "right" way?
21:15:19 <vkarlsen> format-patch works for me
21:15:28 <vkarlsen> Did you tell it it's a patch?
21:15:47 <divlamir> I mean, it works, but the diff is wrong as shown on the website
21:15:52 <ivy> divlamir: use git format-patch, it doesn't matter if the display isn't quite right, the downloaded patch will be fine
21:16:30 <vkarlsen> I mean it works as intended for me, showing it correctly on the website, at least when the patch box is ticked
21:16:44 <divlamir> ok, thanks. noone has complained ut it bugs me a bit every time I do it
21:17:02 <divlamir> s/ut/but/
21:18:00 <divlamir> as I see it, it counts the `--` trailing line as a removed line containing a single `-`
21:18:21 <vkarlsen> Do you have an example we can look at?
21:18:41 <divlamir> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=264007&action=diff
21:19:21 <divlamir> There's a single character change in the file
21:21:10 <vkarlsen> Oh yeah, I see. I think that's just the BZ web interface misinterpreting it. I'm pretty sure it will work correctly when downloading and applying the patch.
23:12:08 * CrtxReavr is really bothered by the term "epoch time."
23:19:34 <divlamir> Makes you feel old, ay :D The elders wanted us to feel its weight
23:19:51 <CrtxReavr> No - it's just me being pedantic.
23:20:21 <CrtxReavr> "epoch time": 1,700,000,000-something seconds.
23:20:54 <CrtxReavr> But in the *nix context, there's only been one epoch.
23:21:08 <CrtxReavr> So calling it "epoch time," just rubs me the wrong way.
23:21:31 <CrtxReavr> Call it "UNIX time" or "seconds past the epoch."
23:22:14 <CrtxReavr> BTW, the billionth second caused *WAY* more issues than Y2k and Y2k+1 combined.
23:22:36 <divlamir> UNIX time is actually accepted term too me thinks
23:22:37 <CrtxReavr> Even for FreeBSD. . . it broke cvsup.
23:24:51 <divlamir> Until the next.. Epochalypse
23:29:38 <CrtxReavr> booooo
23:29:40 <CrtxReavr> hissssss
23:49:20 <divlamir> Didn't know that NTP's epoch begins on 1900-01-01
23:53:12 <divlamir> Nor the term "NTP Era"