Updated #pkgsrc bootstrap kits now available for macOS, available as usual from https://pkgsrc.smartos.org/install-on-macos/
These include the new and improved #pkgin 23.8.1.
No need to install new bootstrap kits if you already installed an older one, but you may want to run:
$ pkg_add -U pkg_install pkgin
prior to running "pkgin upgrade" so that the upgrade is performed using the latest tools.
It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.
I use it all the time, and struggle when working on other systems that do not have it. Only yesterday I wrote a quick script to verify a code path that lead to this fix: https://github.com/NetBSD/pkgsrc/commit/def71d1c1f988e3a2cf3bb86716a2937ce6f48fc.
It has found significant performance wins in #pkgsrc and #pkgin, fixed numerous bugs, and helped me understand systems.
Thanks @bcantrill and @ahl!
Using the cvsmgdiff(1) script provided by devel/mgdiff [1] you can
recursively diff a CVS/SVN/Git repository using mgdiff (or any other
diff tool you prefer) and display diffs between two revisions in a GUI.
#pkgsrc #development #coding #motif #unix
[1] mgdiff is a X/Motif-based graphical file difference browser:
https://pkgsrc.se/devel/mgdiff
#pkgsrc #development #coding #motif #unix
KeepassXC is:
On #pkgsrc > https://pkgsrc.se/security/keepassxc
On #OpenBSD > https://openports.pl/search?file=&descr=&path=&pkgname=Keepassxc&category=&maintainer=
On #slackbuilds > https://slackbuilds.org/repository/15.0/office/keepassxc/?search=KeepassXC
So you are probably OK on that! π€
Ok, with a boatload of fixes and a performance improvements of up to 2,500x I've released #pkgin 23.8.0!
https://github.com/NetBSDfr/pkgin/blob/master/CHANGES.md#version-2380-2023-08-16
There's still a bunch of things to do, but they can wait for future releases.
I've updated the #pkgsrc package and will be rebuilding binary package sets over the coming days.
I just archived the repo for https://github.com/bsiegert/gourl2pkg, which was a tool useful for GOPATH builds but not for modules. No one uses GOPATH builds these days (certainly not in #pkgsrc) so it makes sense to officially kill it.
Donβt tell the Joyent & MNX nerds Iβm using #pkgsrc to configure the testbed tooling on this macOS terminal system. Itβs completely irrelevant to this project. But Iβm using a family shared machine and donβt want to mess up the rest of the system with my weird tools while my monsters are learning with basic scratch & pi projects. pkgsrc is so much more boringly suited to this task.
As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.
http://mail-index.netbsd.org/tech-pkg/2023/08/07/msg027952.html
This is in addition to the 13x speedup I committed a few years ago:
https://gist.github.com/jperkin/98550d5bd07f4179ebfeea825fc3ec20
#pkgin #dtrace #pkgsrc #netbsd
Not only was #Manta v1 awesome for having jobs, the marlin image provides a superb environment for testing the new #pkgin code, given there are over 12,500 packages installed.
I'd say the results are looking pretty good:
$ time ./pkgin-22.10.0 -n ug
real 54m10.021s
user 53m42.252s
sys 0m21.575s
$ time ./pkgin-current -n ug
real 0m1.241s
user 0m1.086s
sys 0m0.145s
Under 1 second would be cool, and I think there are still some areas where improvements can be made.
```
$ signify -C -e -p opensmtpd-20181026.pub -x opensmtpd-7.3.0p1.sum.sig
Signature Verified
opensmtpd-7.3.0p1.tar.gz: OK
```
On my way to update #OpenSMTPD on #pkgsrc
Updated: The ports / pkgsrc build framework and the related tools for binary packaging have a complicated history that has traveled further and closer over the years.
The FreeBSD ports was added to significantly after NetBSD forked it, then pkg_* tools were replaced on FreeBSD by PkgNG.
https://www.netbsd.org/docs/software/packages.html#platforms
#netbsd #pkgsrc #freebsd #openbsd #linux #solaris #unix #opensource
Used #pkgsrc some times the last times. But if you've got GCC installed and then need to build llvm/clang as part of the dependency chain the whole process of building from source becomes kinda weird. I'd almost consider that broken, I think.
My pkgsrc packages for Slackware 15.0 have been updated to the 2023Q2
quarterly branch. More info at:
https://www.unitedbsd.com/d/708-sharing-my-pkgsrc-packages-for-linux/7
Packages assume an existing pkgsrc bootstrap [1][2] with PREFIX=/usr/pkg.
To install them via pkgin[3], point `/usr/pkg/etc/pkgin/repositories.conf`
the URL: https://retrobsd.ddns.net/pub/packages/All/
#pkgsrc #slackware #linux #netbsd
[1] https://anonhg.netbsd.org/pkgsrc/file/trunk/bootstrap/README
[2] https://wiki.netbsd.org/pkgsrc/how_to_use_pkgsrc_on_linux/
[3] https://pkgin.net/
#pkgsrc #slackware #linux #netbsd
Should I submit an abstract for https://linuxtag.at or not? Thinking of a #pkgsrc lightning talk
Another solution is to install #pkgsrc and either use that to compile what you need, or use #pkgsrc to install #pkgin and download pre-compiled binaries supplied by @jperkin if memory serves well.
I have done that in the past, and I was very happy with the amount of goodness pkgsrc brings to MacOS X.
It does involve installing XCode and its command line tools, but that is a minor problem - read the documentation at https://www.netbsd.org/docs/pkgsrc/ and you will be in business pretty quickly.
You have strange tastes.
Use Slackware + #pkgsrc - no need for AUR.
Also: Slackware + GUIX - this is something I am working on right now.
#pkgsrc is when you install a tiny Python module, think "why is this taking so long" and see your machine compiling gcc 10 from source.
@ParadeGrotesque the idea of running #pkgsrc on Slackware just tickles me pink! I think I have to spin up a VM just to play with that!
Nope, still no dependency management in the base system!
There is some dependency management in stuff like #sbopkg or (if you are a weird person like me) in runing #pkgsrc or #guix on #slackware ...
#sbopkg #pkgsrc #guix #slackware