is there no way to clone a zfs filesystem, without duplicating the data and without leaving a snapshot around forever?

ivy, I thought one could destroy a snapshot after creating a clone from it? No?

See Example 3 in man zfs-snapshot

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

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.

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

what's easier; updating my 14 month old 15-CURRENT system to 16-CURRENT or 15-RELEASE?

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

although if you really mean 15.0-RELEASE, things might have changed by the time that comes out

i don't mean 15-release, i mean whatever 15- non-current it is now

you can assume they will be equally difficult, with the caveat of package availability she noted

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

i'm ok building my own, it's mostly bhyve and puppet

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?

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)

ivy, thanks!

So, is pkgbase primetime starting with 15.0?

I mean the default, so we convert on upgrade

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

divlamir: converting on upgrade will be optional since freebsd-update will still be supported

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)

and for the building from source it will not cease to end as an option i hope?

ivy: thanks, time to give it a go and test it then.

it seems there is freebsd-ftpd-20240719 (port) and FreeBSD-ftpd-15.0.a2.20250919040617 (base) ... and that's confusing the output

angry_vincent: there are no plans to remove buildworld/installworld

angry_vincent: building from source will never cease be a thing

good

i have tried make packages but it fails for me. i use custom src.conf and kernel

(for clarity, I don't have the ftpd port installed, just the base pkg)

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

(this is why we have FreeBSD-rip instead of FreeBSD-routed, but i didn't realise ftpd was affected as well)

ivy: sounds good, thanks for clarifying

markmcb: i also filed a pkg bug for this: freebsd/pkg #2526

[root@tyrone /usr/src]# git fetch

ld-elf.so.1: Shared object "libssl.so.35" not found, required by "libcurl.so.4"

off to a great start

rtprio: that looks like you managed to update ports before updating the base system

libssl was bumped from 30 to 35 a few weeks ago

yeah, that must have been it

˜/38

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.

how's 15 looking?

hot!

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?

format-patch works for me

Did you tell it it's a patch?

I mean, it works, but the diff is wrong as shown on the website

divlamir: use git format-patch, it doesn't matter if the display isn't quite right, the downloaded patch will be fine

I mean it works as intended for me, showing it correctly on the website, at least when the patch box is ticked

ok, thanks. noone has complained ut it bugs me a bit every time I do it

s/ut/but/

as I see it, it counts the `--` trailing line as a removed line containing a single `-`

Do you have an example we can look at?

There's a single character change in the file

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.

Makes you feel old, ay :D The elders wanted us to feel its weight

No - it's just me being pedantic.

"epoch time": 1,700,000,000-something seconds.

But in the *nix context, there's only been one epoch.

So calling it "epoch time," just rubs me the wrong way.

Call it "UNIX time" or "seconds past the epoch."

BTW, the billionth second caused *WAY* more issues than Y2k and Y2k+1 combined.

UNIX time is actually accepted term too me thinks

Even for FreeBSD. . . it broke cvsup.

Until the next.. Epochalypse

booooo

hissssss

Didn't know that NTP's epoch begins on 1900-01-01

Nor the term "NTP Era"