schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Cut a new #pkgsrc bulk tracker release, will deploy tomorrow. It needs a database migration, so I will take it offline for a few minutes.
I wrote up a quick howto for getting bob up and running on OmniOS for someone, but figured it might be useful for others who want to play too.
https://gist.github.com/jperkin/72075147e330b35eb4869898207e828e
Quite a minimal, stripped-back config, so doesn't have dynamic jobs configured. Easy to add though if you want to push your system to the max.
I think #NetBSD #pkgsrc foundation can take this initiative : @netbsd
https://www.sovereign.tech/news/join-sovereign-tech-standards-network
boostedFinally found the #Pkgsrc news about Q1 2026:
https://mail-index.netbsd.org/netbsd-announce/2026/03/27/msg000392.html
As the pkgsrc.org site has no announcements since 2025 I guess there's a gap in the doc process, after role shuffling. Continued activity as shown by charts: https://pkgsrc.se/statistics.php
#NetBSD
boosted@lem_urist at least for the #pkgsrc case it's because nobody has volunteered to package them up yet.
I found a show-stopper in implementing parsing of #pkgsrc bulk build reports generated by #bob: the machine-readable report doesn't include the resolved dependencies (DEPENDS).
I rely on those in #BulkTracker to show which dependencies failed, and which other packages were prevented from building.
If you've ever built a non-trivial amount of software on Solaris / illumos you've almost certainly hit math function errors like this:
error: call of overloaded 'log(int)' is ambiguous
I got fed up of adding patches to pkgsrc, and I believe I have a patch that fixes this once and for all.
https://www.illumos.org/issues/15209#note-4
I'd appreciate wider testing. I've already tested it in a full ~28,000 package bulk build, but changes like this terrify me, and you can't be too careful.
boostedI'm considering bumping the macOS requirements for my binary package repository available at https://pkgsrc.smartos.org/install-on-macos/ again.
There's already a bunch of packages missing because they have newer C++ requirements than Xcode 15.4 supports.
What OS are folks running?
| macOS 14 Sonoma: | 3 |
| macOS 15 Sequoia: | 15 |
| macOS 26 Tahoe: | 10 |
Closed
Bob now automatically reports on, and links to, commits made to packages that fail to build since the previous attempt.
https://reports.pkgci.org/Darwin/14.5/arm64/20260413T215911Z/report.html
This is really helpful for showing regressions, and I hope will be useful to developers who want to check whether their updates caused problems on platforms they do not have access to.
@justine
Looks quite simple port without patch.
But reading the description, it seems to be a wrapper for specific syscall with the same name as the port.
So it would depend if the syscall exists on #OpenBSD and compatible with the one on #FreeBSD.
If #OpenBSD matched above prerequisite, and #OpenBSD ports infrastructure is enough alike with #FreeBSD #ports (IIRC, #NetBSD, the direct origin of #OpenBSD, once introduced #FreeBSD #ports framework far before when it was still quite simple and switched to their own #pkgsrc later), the conversion would be trivial.
On #FreeBSD, porters (including myself) first create a port under specific category directory such as graphics, test, hook on category Makefile, generate diff and file a PR on Bugzilla and/or open review on Phabricator.
For any #ports that are not intended to be included in official #ports, no need to hook to category Makefile and no need to file PRs / opening reviews. Ports framework allows it. Hooking on category Makefile is needed to be picked for official #pkg building. Maybe #OpenBSD #ports, too, as without the allowance, how porters attempt to make new ports?
By searching Internet, found this.
https://www.openbsd.org/faq/ports/guide.html
And FreeBSD has a (large) document "Porter's Handbook".
https://docs.freebsd.org/en/books/porters-handbook/
An example how I've added new FreeBSD port.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293719
https://reviews.freebsd.org/D55798
And its relevant commit.
https://cgit.freebsd.org/ports/commit/?id=b23b14c3bfc0d930f7757226b06a88008e95909c
Maybe #OpenBSD would have its own workflow, though.
Currently testing a couple of Claude-inspired improvements to bmake and mksh, providing a decent speedup on macOS.
https://github.com/TritonDataCenter/pkgsrc/commit/2fb7d262707d40aa1db31599eaf9c0b952d15bd4
https://github.com/TritonDataCenter/pkgsrc/commit/3bd175884bb65350b24f442f8e3e9fcd45e695ce
Saw a 30% improvement spawning commands in a tight loop when using posix_spawn(), and avoids creating temporary /tmp/make* files for the vast majority of make commands. Both of which also help to reduce system time.
As a side benefit it greatly improves the readability of pstree output.
bob v0.99.x now available, as well as a wip/bob package for testing.
These are release candidates in preparation for v1.0 which will be considered fully production ready.
If you have any questions, comments, or concerns, then now is the time to raise them as once v1.0 lands I will not be allowing any incompatible changes.
https://mail-index.netbsd.org/pkgsrc-users/2026/04/08/msg042818.html
Happy building!
Now that I've switched the daily SmartOS pkgsrc bulk builds fully over to bob, I figured it might be interesting to also publish the exact config file I'm using to do so.
https://github.com/jperkin/bob/blob/main/examples/smartos-trunk.lua
No more complicated and fragile sandbox scripts, patches to pbulk, convoluted build infrastructure, etc.
Just a single binary installed using cargo, and a single configuration file.
Next release will be 0.99.0, we're almost ready for v1.0.
First full pkgsrc build completed with bob using the new publishing feature. All looking good!
https://mail-index.netbsd.org/pkgsrc-bulk/2026/04/02/msg028397.html
And I am busy with household things too. I should find a time to commit my changes for #pkgsrc. I have too many changes in my local tree...
bob v0.9.0 now available!
https://mail-index.netbsd.org/pkgsrc-users/2026/03/25/msg042765.html
I'm really proud of this one. Dynamic MAKE_JOBS and WRKOBJDIR in particular will save me a significant amount of time, and ensure my builds automatically stay optimal.
As always please let me know if you run into any issues or have suggestions for the next release.
Found a fun way to confuse #pkgsrc: set it up on a 64-bit Pi with a 32-bit OS. The kernel will be 64-bit still, causing search path confusion in check_shlibs.
The workaround, pending a better solution: bootstrap --machine-arch arm
Hey! I will speak at #OpenTofuDay Europe in Amsterdam on March 23!
In my talk, we will see how to package OpenTofu and its providers, and we will exercise that to migrate from Terraform 0.12.x to OpenTofu 1.11.x.
Talk schedule link: https://sched.co/2DY5x
For more info about OpenTofu Day Europe: https://bit.ly/41RUALZ
I realise the "blazing fast" meme is getting very old at this point, but it's genuinely so much fun making Rust code even faster. You often end up with simpler, cleaner, more idiomatic code too.
The original C pbulk presolve code takes:
real 0m35.686s
user 0m35.229s
sys 0m0.163s
Bob was already much faster:
real 0m2.115s
user 0m1.677s
sys 0m0.174s
But the new code is ridiculously (some might say blazing) fast:
real 0m0.506s
user 0m0.396s
sys 0m0.106s
The NetBSD Foundation will participate to Google Summer of Code 2026!
Google Summer of Code is a great opportunity to contribute to NetBSD and/or pkgsrc!
To learn more please give a look to NetBSD Blog post: https://blog.NetBSD.org/tnf/entry/gsoc2026_tnf
boostedMid February #NetBSD #pkgsrc package counts for 2025Q4:
10.0: earmv4 12805 (didn’t have it listed before) 10.0: m68k 9622 (+1394) 10.0: powerpc 20711 (+2833) 10.0: sparc64 16866 (+1635) 10.0: vax 7495 (+748)
11.0: aarch64eb 24042 (+4001) 11.0: earmv4 4362 (+612) 11.0: m68k 8132 (+1271) 11.0: mips64eb 3852 (+363) 11.0: mipsel 440 (+449 - needs a new power supply) 11.0: powerpc 4552 (unchanged - needs space and power) 11.0: riscv64 18616 (+3233) 11.0: sh3el 7809 (+2239) 11.0: vax 5245 (+1879)
@jperkin Any chance of getting it moved from wip into pkgsrc before the 2026Q1 branch, please? 🙏😎#pkgsrc #prettyplease 😁
System Administration: Week 4: Package Management
In this video, we continue our discussion of the difference and relationship between the operating system and so-called "add-on software". We conclude that in order to install and maintain all such software, we want to use a package manager, and illustrate common features by example of the 'dpkg', 'rpm', and #NetBSD's #pkgsrc tools.
Celebrating #WorldRadioDay with the most portable OS on the planet. 🌍
Whether it's the embedded controller inside a vintage radio or the legendary NetBSD Toaster 🍞, the ham/ 📻category in #pkgsrc has you covered.
Why just make toast when you can transmit packets over the airwaves at the same time?
#NetBSD #SDR #PacketRadio #HamRadio #VintageComputing #Linux #unix
OpenWatcom vi is source available.
https://mastodonapp.uk/@JdeBP/116052015020764901
Ritter's Heirloom #vi is in #FreeBSD ports today, coming from the same place that it has for a long time.
https://freshports.org/editors/2bsd-vi/
It was dropped from #ArchLinux because it did not compile and hadn't changed in 20 years. Ironically, this is because the (GNU) C language had changed, and it has to nowadays be compiled forcing an older GNU C language version.
https://bbs.archlinux.org/viewtopic.php?pid=2285124#p2285124
Several people have independently discovered the Makefile patch that gets it to build on #Debian and the like.
https://forums.debian.net/viewtopic.php?p=629775
https://gist.github.com/cwfoo/01abac5c39f398b7e7b16a2b87aa518b
#elvis, the precursor to #nvi, is packaged for both #NetBSD/ #pkgsrc and #OpenBSD.
https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/editors/elvis/index.html
https://github.com/openbsd/ports/tree/master/editors/elvis
#retrocomputing #ComputerHistory #Watcom #OpenWatcom
#netbsd boostedOn #Illumos, Joy vi is in /usr/src/cmd/vi:
https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi
On #OpenBSD, Bostic #nvi is in /usr/src/usr.bin/vi/vi; #NetBSD having it in /usr/src/external/bsd/nvi; and #FreeBSD in /usr/src/contrib/nvi:
https://cgit.freebsd.org/src/tree/contrib/nvi/
FreeBSD has an nvi2 in ports:
https://freshports.org/editors/nvi2/
OpenBSD has elvis in ports:
https://github.com/openbsd/ports/blob/master/editors/elvis/pkg/DESCR
Ritter's Heirloom vi is on SourceForge:
STEVIE was posted to comp.sources.unix in 1988:
https://sources.vsta.org/comp.sources.unix/volume15/stevie/
Unfortunately, Sven Guckes's vi Clones WWW site was never completed with some of this, notably lacking Heirloom vi, for example.
https://guckes.net/vi/clones.html
But it does mention oft-overlooked commercial clones such as Watcom's vi, a from-scratch implementation started in 1983 that is also now source-available:
https://github.com/open-watcom/owp4v1copy/tree/master/bld/vi
#vi #retrocomputing #ComputerHistory #STEVIE #elvis #VIM #NeoVIM #Watcom #OpenWatcom
Habr » 🤖 🌐
@habr@zhub.link
NetBSD: Интервью с разработчиком
На одной истории с OpenBSD и Вячеславом Воронцовым мы конечно же не остановились, на этот раз в гостях у нас ещё один яркий и интересный представитель сообщества BSD.
https://habr.com/ru/articles/995602/
#netbsd #bsd #интервью #cheusov #pkgsrc #коммиттер #сообщество
Ok quick "screenshot" before bed.
[ 0: 3m 3s ] libunistring-1.2 (build -j6)
[ 1: 2m 18s ] libgcrypt-1.11.2 (build -j5)
[ 2: 3m 40s ] python313-3.13.11nb1 (build -j2)
[ 3: 5m 0s ] gettext-lib-0.22.5 (configure -j3)
There is now support in main for dynamic MAKE_JOBS, designed to ensure that build throughput is as optimal as possible. To enable, all you need to do is set:
options = {
dynamic_jobs = { max = 16, min = 2 },
}
and bob will figure out the rest.
This also provides a significant performance boost. In pbulk, every build requires a full setup/teardown of the environment just to check the status of the package.
On most platforms this means unpacking the bootstrap kit and any other setup, before forking the tools to check various things, then wiping everything at the end.
Now that all of this is in native Rust, bob simply checks all at the start, and saves a huge amount of time by skipping all up-to-date packages.
Rust FTW
Playing around with a cool new bob feature. One of the most opaque parts of pbulk is that you never really know WHY a particular package is being rebuilt.
Bob's up-to-date checker is now written in native Rust (no need to fork pkg_info and pkg_admin), records the reasons, and provides a new status command:
$ bob list status rust
PKGNAME STATUS REASON
rust-bin-1.91.1 pending package not found
rust-1.91.1 pending deps changed: +digest-20220214, ...
I just released bob v0.7.0.
https://github.com/jperkin/bob/blob/main/CHANGES.md#version-070-2026-01-30
This version now supports macOS sandboxes. I figured out how to avoid SIGBUS when re-using chroots, but unfortunately it means waiting for 2 minutes for 'diskutil unmount' to unmount /System read-only loopback mounts. No, I don't know why it takes that long for a read-only mount either!
Also a new "bob list" command, so you can do things like:
$ bob list failed | xargs bob rebuild
plus loads of other improvements.