@vi @fluxwatcher @mms While "do not mix" #FreeBSD #ports and #packages remains a sane recommendation, it doesn't mean it's impossible to do. All ports do is build (and install) packages. Because they are built a) with different options and b) from different states of the ports tree, "mixing" comes with lots of pitfalls, you'll easily end up with a broken installation.
There's a perfectly safe way to avoid building *everything*: Use poudriere-devel and configure it to fetch packages. It has several checks (version, dependencies, selected options ...) to make sure to only include fetched packages into your repo that perfectly match what you're building.
Finally starting a new #FreeBSD #ports bulk build again (didn't want to do that on a pool with a damaged drive).
Time to bump #samba version in DEFAULT_VERSIONS from 4.16 to 4.19. I see I'm forced to upgrade bind9 (9.16 -> 9.18) as well.
Oh no, both of this will affect my domain controller, what if it breaks? 😱
Haha, jk, simply roll back to the pre-upgrade #ZFS snapshot for the respective jail and analyze the issue .... 😏
@BoxyBSD With #arm64 being tier-1 in #FreeBSD base, I think #ports contributors (or at least committers) really *should* test their ports on #arm64 as well 😎
I solved this for myself by getting a free machine from Oracle, so I have no immediate need myself ...
https://sekrit.de/webdocs/freebsd/oracle-aarch64-testbuilder.html
But I guess lots of people would really like such an offer 😉👍
I'm one of these mad guys refusing to pull some "modern" buildsystem (like cmake or meson) into my projects, yet also dislike the complexity and overhead of autotools ... so I created my own "buildsystem" many many years ago, which is basically a #gmake (#GNU #make) framework using "eval" to generate rules on the fly.
Over the years, I piled up features in there as I needed them for current projects. The result is (although it still "worked") chaos. 🙈 More and more, I'm having trouble understanding my own code, and changing things is almost guaranteed to also break things. 🙄
I now decided to refactor a lot, giving some structure to that mess, and took inspiration from #FreeBSD's #ports framework by introducing a "USES" concept to load optional parts. So far, this seems to turn out well, it also gives the opportunity to better document that stuff given the clear responsibility of each USES, see e.g. the one handling installation of freedesktop.org stuff:
https://github.com/Zirias/zimk/blob/master/lib/uses/fdofiles.mk
@txt_file You shouldn't install and (try to) use a mix of #packages from different sources (locally built vs official pkgs) ... but doing `pkg install git-tiny` and later update that from #ports won't hurt. Another bootstrap option is to just fetch and extract the `ports.txz` snapshot that's created with every release.
When you're new to #FreeBSD, are you sure you need to build yourself at all? Using official packages is recommended unless you have an actual need to customize build-time options ... or, of course, there are no packages for your target architecture.
Well, I wanted to test #FreeBSD #PowerShell for my usecase (which I *guess* I have, still not entirely sure), but ... I thought now that the port works, let's first rebase #ports (on main).
BAAAD idea. Not only did some change force my #poudriere to rebuild more or less *everything*, I also had fallout to fix from new #LibreSSL incompatibilities and some strange build error with #llvm-17.
Right now STILL waiting for the build of #chromium to finish.
Ok, testing PowerShell: tomorrow. 🙄
In case you want to test #PowerShell on #FreeBSD *NOW* ... here's a patch for #ports:
https://people.freebsd.org/~zirias/patches/0001-shells-powershell-Add-new-port.patch
It currently requires at least these patches applied before:
https://reviews.freebsd.org/D44560
https://reviews.freebsd.org/D44561
Note they will probably change, the maintainer of lang/dotnet is looking for better options to solve these issues.
@marquito Pors sind (über lange Zeit) von DEM Weg, 3rd-party Software auf einem BSD-System zu installieren (weil's gar nicht anders ging), zum flexiblen Paketbausystem geworden. Das muss natürlich aus dem Source bauen, wie bei jeder anderen Softwaredistribution. Der "Ansatz" ist jedenfalls schon lange nicht mehr, alles "frisch" zu kompilieren ... zumindest für Tier-1 Architekturen ist der bevorzugte Weg für User pkg, also Binary-Pakete.
Für User, die trotzdem selbst bauen wollen (weil sie andere Build-Konfigurationen wollen) gibt's mit poudriere ein mächtiges und flexibles Tool, das das eigene Repository für pkg baut, aus dem dann installiert werden kann. Dabei sorgen isolierte builds (ein jail pro build) für zuverlässig reproduzierbare Ergebnisse und für Pakete die von den angepassten Konfigurationen nicht betroffen sind kann direkt ein offizielles Paket runtergeladen und ins eigene Repository gelegt werden statt unnötig zu bauen.
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:riscv64/quarterly, please wait...
pkg: Error fetching http://pkg.FreeBSD.org/FreeBSD:14:riscv64/quarterly/Latest/pkg.txz: Not Found
A pre-built version of pkg could not be found for your system.
@fluxwatcher @dch @antranigv @meka @wezm @hnygd @foufoutos parallel discussion in The FreeBSD Forums:
<https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/>
@fluxwatcher @dch @antranigv @meka @wezm @hnygd @foufoutos parallel discussion in The FreeBSD Forums:
<https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/>
@ramin_hal9001 This commit history doesn't look promising. First the original maintainer abandoned it, later someone else marked it broken.
But talking about reproducible builds, you get that with #poudriere (enabling a few options that avoid surpising sources of inconsistencies) and the #ports tree as well. Poudriere builds every package in a clean #jail that only gets the named dependencies installed. Official #FreeBSD packages are built that way.
