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.
boostedFirst SmartOS pkgsrc build using GCC 15.2.0. As expected, plenty of fallout due to the ongoing strictness changes in upstream GCC.
https://reports.pkgci.org/SmartOS/upstream/trunk/20260518T093149Z/report.html
Hopeful that there are only a few high-profile blockers, and that the gmake failure is not more systemic gnulib-type issues where all individual releases bundle their own broken copies.
@veer66 Why not create your own pkgsrc entry (ie directory, Makefile, distinfo, DESCR, PLIST and any patches) for your own software? Maybe add it to #pkgsrc-wip so everyone can use it?Then you won't be breaking abstractions, and you and others can use it on other autotools-supported platforms you may not have access to (pkgsrc makes sure config.sub and config.guess are consistent everywhere)
In the spirit of there always being 1 more #vi clone than one thinks, notice that @lpar 's list is lacking Ali Gholami Rudi's #neatvi which is packaged in #pkgsrc and about a decade old now.
https://pkgsrc.se/editors/neatvi
And even then the rule still applies. There's 1 more clone: Sterling Huxley's and Brent Roman's #viless, a quarter of a century old and what #BusyBox supplies.
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.