Date: Sat, 14 Dec 2024 07:00:41 -0800 From: Mark Millard <marklmi@yahoo.com> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Switching release media dist sets to .tzst (tar + zstd)? Message-ID: <EDDFEC1D-6972-4FF4-B213-DB4DE0AFFA34@yahoo.com> In-Reply-To: <CAPyFy2AcfakMC-92HuXrD_PCjuttaASDPAYxBm5zxN6h64upHw@mail.gmail.com> References: <E7CF486A-81BE-4B1C-A1E4-6B820F454259.ref@yahoo.com> <E7CF486A-81BE-4B1C-A1E4-6B820F454259@yahoo.com> <CAPyFy2AcfakMC-92HuXrD_PCjuttaASDPAYxBm5zxN6h64upHw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 14, 2024, at 06:21, Ed Maste <emaste@freebsd.org> wrote: > On Fri, 13 Dec 2024 at 19:42, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >> I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz >> for crude bisecting without needing to do builds. >>=20 >> Are you saying that such will no longer be a possibility? (This is >> not a which-compression-style question.) >=20 > With pkgbase these distribution sets are not used by the installer, so > they will no longer be required for their original purpose. >=20 > It may be that there are a sufficient number of other use cases (like > yours) that we still build them anyway, for some time. I would imagine > most use cases can also switch to pkgbase packages, though. If it's > different kernels you're looking to test it will be straightforward to > use the kernel packages instead. At least currently, there is no history of PkgBase builds available, for download, just the most recent of of latest and weekly. Would artifact.ci.freebsd.org <http://artifact.ci.freebsd.org/>; be replaced = with a source of PkgBase build history that would allow the approximate bisecting of pre-built materials? Without the history, activity like bisecting would require doing the builds, making things take much much longer for various platform instances that take notable time to do builds. >> I've also used the likes of the below with kgdb to look at reported >> backtraces from problems that have been reported --for versions of >> FreeBSD that I do not have a boot environment for. (Not wanting to >> do a normal install on other media and to boot/configure it --just >> to look around.) >>=20 >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel.txz= >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/kernel-dbg= .txz >> = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/14.2-RELEASE/src.txz >>=20 >> (But there is no equivalent for patch revisions of *.*-RELEASE 's .) >>=20 >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel.txz= >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/kernel-dbg= .txz >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.4-STABLE/src.txz >>=20 >> Similar question for those: no longer to be possible? >=20 > The same applies to these ones - they won't be needed after moving to > pkgbase, but I imagine we could still build them if they're being used > for other purposes. base_release_* will exist, also spanning patches. I've not yet tested if these are binary matches to the official non-PkgBase builds from http://ftp3.freebsd.org/pub/FreeBSD/releases/ such that, say, kernel backtrace addresses are usable across the types of builds. (Sort of a reproducibility criteria.) base_weekly is like http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ , other than having no history prior to the most recent base_weekly as things are. Lack of history also has issues when it turns out that base_latest is or base_weekly is broken/unusable. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EDDFEC1D-6972-4FF4-B213-DB4DE0AFFA34>